draft-ietf-ospf-yang-01.txt   draft-ietf-ospf-yang-02.txt 
Internet D. Yeung Internet D. Yeung
Internet-Draft Y. Qu Internet-Draft Y. Qu
Intended status: Informational Cisco Systems Intended status: Informational Cisco Systems
Expires: September 2, 2015 J. Zhang Expires: March 5, 2016 J. Zhang
D. Bogdanovic
Juniper Networks Juniper Networks
D. Bogdanovic
K. Sreenivasa K. Sreenivasa
Brocade Communications System Cisco Systems
March 2015 September 2, 2015
Yang Data Model for OSPF Protocol Yang Data Model for OSPF Protocol
draft-ietf-ospf-yang-01 draft-ietf-ospf-yang-02
Abstract Abstract
This document defines a YANG data model that can be used to configure This document defines a YANG data model that can be used to configure
and manage OSPF. and manage OSPF.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2015. This Internet-Draft will expire on March 5, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 23 skipping to change at page 2, line 24
2.2. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.2. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5
2.3. Optional Features . . . . . . . . . . . . . . . . . . . . 5 2.3. Optional Features . . . . . . . . . . . . . . . . . . . . 5
2.4. Inheritance . . . . . . . . . . . . . . . . . . . . . . . 5 2.4. Inheritance . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. OSPF Router Configuration . . . . . . . . . . . . . . . . 5 2.5. OSPF Router Configuration . . . . . . . . . . . . . . . . 5
2.6. OSPF Instance Configuration . . . . . . . . . . . . . . . 6 2.6. OSPF Instance Configuration . . . . . . . . . . . . . . . 6
2.7. OSPF Area Configuration . . . . . . . . . . . . . . . . . 7 2.7. OSPF Area Configuration . . . . . . . . . . . . . . . . . 7
2.8. OSPF Interface Configuration . . . . . . . . . . . . . . 9 2.8. OSPF Interface Configuration . . . . . . . . . . . . . . 9
2.9. OSPF notification . . . . . . . . . . . . . . . . . . . . 11 2.9. OSPF notification . . . . . . . . . . . . . . . . . . . . 11
3. OSPF Segment Routing . . . . . . . . . . . . . . . . . . . . 14 3. OSPF Segment Routing . . . . . . . . . . . . . . . . . . . . 14
4. OSPF Yang Module . . . . . . . . . . . . . . . . . . . . . . 20 4. OSPF Yang Module . . . . . . . . . . . . . . . . . . . . . . 20
5. OSPF Segment Routing Yang Module . . . . . . . . . . . . . . 90 5. Security Considerations . . . . . . . . . . . . . . . . . . . 104
6. Security Considerations . . . . . . . . . . . . . . . . . . . 104 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 104 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 105
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 104 7.1. Normative References . . . . . . . . . . . . . . . . . . 105
8.1. Normative References . . . . . . . . . . . . . . . . . . 104 7.2. Informative References . . . . . . . . . . . . . . . . . 106
8.2. Informative References . . . . . . . . . . . . . . . . . 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 106
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 105
1. Overview 1. Overview
YANG [RFC6020] is a data definition language that was introduced to YANG [RFC6020] is a data definition language that was introduced to
define the contents of a conceptual data store that allows networked define the contents of a conceptual data store that allows networked
devices to be managed using NETCONF [RFC6241]. YANG is proving devices to be managed using NETCONF [RFC6241]. YANG is proving
relevant beyond its initial confines, as bindings to other interfaces relevant beyond its initial confines, as bindings to other interfaces
(e.g. ReST) and encodings other than XML (e.g. JSON) are being (e.g. ReST) and encodings other than XML (e.g. JSON) are being
defined. Furthermore, YANG data models can be used as the basis of defined. Furthermore, YANG data models can be used as the basis of
implementation for other interfaces, such as CLI and programmatic implementation for other interfaces, such as CLI and programmatic
skipping to change at page 3, line 5 skipping to change at page 3, line 5
[I-D.ietf-netmod-routing-cfg], and it proposes a basis for the [I-D.ietf-netmod-routing-cfg], and it proposes a basis for the
development of data models for routing protocols. The interface data development of data models for routing protocols. The interface data
model is defined in [RFC7223] and is used for referencing interface model is defined in [RFC7223] and is used for referencing interface
from the routing protocol. The key-chain data model is defined in from the routing protocol. The key-chain data model is defined in
[I-D.acee-rtg-yang-key-chain] and is used for referencing key-chains [I-D.acee-rtg-yang-key-chain] and is used for referencing key-chains
configured for authentication and for the enumeration of configured for authentication and for the enumeration of
cryptographic algorithms, also used for authentication. This cryptographic algorithms, also used for authentication. This
document defines a YANG data model that can be used to configure and document defines a YANG data model that can be used to configure and
manage OSPF and it is an augment to the core routing data model. manage OSPF and it is an augment to the core routing data model.
This document defines a YANG data model that can be used to configure Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are supported. In
and manage OSPF. Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are additional to the core OSPF protocol, features described in different
supported. In additional to the core OSPF protocol, features separate OSPF RFCs are also supported. They includes demand circuit
described in different separate OSPF RFCs are also supported. They [RFC1793], traffic engineering [RFC3630], multiple address family
includes demand circuit [RFC1793], traffic engineering [RFC3630], [RFC5838], graceful restart [RFC3623] [RFC5187], NSSA [RFC3101] and
multiple address family [RFC5838], graceful restart [RFC3623] sham link [RFC4577]. Those non-core features are made optional in
[RFC5187], NSSA [RFC3101] and sham link [RFC4577]. Those non-core the data model provided.
features are made optional in the data model provided.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Design of Data Model 2. Design of Data Model
Although the basis of OSPF configuration elements like routers, areas Although the basis of OSPF configuration elements like routers, areas
and interfaces remains the same, the detailed configuration model and interfaces remains the same, the detailed configuration model
varies among different vendors. Differences are observed in term of varies among different vendors. Differences are observed in term of
how protocol engine is tied to routing domain, how multiple protocol how protocol engine is tied to routing domain, how multiple protocol
engines could be instantiated and configuration inheritance, just to engines could be instantiated and configuration inheritance, just to
name a few. name a few.
The goal of this document is to define a data model that is capable The goal of this document is to define a data model which provides a
of representing these differences. There is very little information common user interface to the OSPFv2 and OSPFv3 protocol. There is
that is designated as "mandatory", providing freedom to vendors to very little information that is designated as "mandatory", providing
adapt this data model to their product implementation. freedom to vendors to adapt this data model to their product
implementation.
2.1. Overview 2.1. Overview
The OSPF YANG module defined in this document has all the common The OSPF YANG module defined in this document has all the common
building blocks for OSPF protocol. building blocks for OSPF protocol.
The OSPF YANG module augments the routing/routing-instance/routing- The OSPF YANG module augments the routing/routing-instance/routing-
protocols/routing-protocol path of the ietf-routing module. protocols/routing-protocol path of the ietf-routing module.
module: ospf module: ospf
skipping to change at page 5, line 19 skipping to change at page 5, line 19
OSPF configuration for the area and interface level respectively OSPF configuration for the area and interface level respectively
The instance/topology container contain the OSPF configuration for The instance/topology container contain the OSPF configuration for
topology when multi-topology feature is enabled topology when multi-topology feature is enabled
2.2. OSPFv2 and OSPFv3 2.2. OSPFv2 and OSPFv3
The defined data model supports both OSPFv2 and OSPFv3. The defined data model supports both OSPFv2 and OSPFv3.
The field 'version' is used to indicate the OSPF version and is a The field 'version' is used to indicate the OSPF version and is a
mandatory. Based on the version set, the data model change mandatory. Based on the version set, the data model changes
accordingly to accommodate the difference between the two versions. accordingly to accommodate the difference between OSPFv2 and OSPFv3.
2.3. Optional Features 2.3. Optional Features
Optional features are features beyond the basic of OSPF Optional features are features beyond the basic of OSPF
configurations and it is up to a vendor to decide the support of a configurations and it is up to a vendor to decide the support of a
particular feature on a particular device. particular feature on a particular device.
This module has declared a number of features, such as NSR, max-LSA This model has declared a number of features, such as NSR, max-LSA
etc.. It is intended that vendors will extend the features list. etc.. It is expected that vendors will extend the feature list.
2.4. Inheritance 2.4. Inheritance
This defined data model supports configuration inheritance for This data model supports configuration inheritance at different
intances, areas and interfaces. levels, e.g. instance-level, area-level and interface-level
inheritance.
The all-instances-inherit, all-areas-inherit and all-interfaces- The all-instances-inherit, all-areas-inherit and all-interfaces-
inherit containers provides a consistent way to configure inheritable inherit containers are defined to provide a consistent way to
command. Inheritance is treated as a feature. Vendors are expected configure inheritable commands. For example, parameters defined in
to augment the above container to provide the list of inheritance all-instances-inherit apply to all OSPF instances, and a particular
command for their implementation. instance can override this inheritance with its own configuration.
Inheritance is defined as an optional feature, and vendors are
expected to augment the above containers with their own
implementations.
2.5. OSPF Router Configuration 2.5. OSPF Router Configuration
The container ospf is the top level container in this data model. It The container ospf is the top level container in this data model. It
contains shared information among different OSPF instances under the contains shared information among different OSPF instances under the
container. container.
module: ospf module: ospf
+--rw ospf +--rw ospf
+--rw all-instances-inherit {instance-inheritance}? +--rw all-instances-inherit {instance-inheritance}?
skipping to change at page 6, line 22 skipping to change at page 6, line 22
. .
. .
2.6. OSPF Instance Configuration 2.6. OSPF Instance Configuration
The container instance represents an OSPF protocol engine. Each The container instance represents an OSPF protocol engine. Each
instance indicates the routing domain it is associated with based on instance indicates the routing domain it is associated with based on
[routing-instance af] and contains the router level configurations. [routing-instance af] and contains the router level configurations.
The all-areas-inherit container contains area configuration that The all-areas-inherit container contains area configuration that
could be inherited to all OSPF areas defined. Similarly, the all- could be inherited to all OSPF areas defined.
areas-inherit also contains interface configuration that could be
inherited to all the OSPF interfaces defined.
module: ospf module: ospf
+--rw ospf +--rw ospf
. .
. .
+--rw instance* [af] +--rw instance* [af]
+--rw af identityref +--rw af identityref
+--rw router-id? yang:dotted-quad {router-id}? +--rw router-id? yang:dotted-quad {router-id}?
+--rw admin-distance +--rw admin-distance
skipping to change at page 7, line 35 skipping to change at page 7, line 33
| +--rw autoconfig? boolean {ldp-igp-autoconfig}? | +--rw autoconfig? boolean {ldp-igp-autoconfig}?
+--rw fast-reroute {fast-reroute}? +--rw fast-reroute {fast-reroute}?
| +--rw lfa {lfa}? | +--rw lfa {lfa}?
+--rw all-areas-inherit {area-inheritance}? +--rw all-areas-inherit {area-inheritance}?
| +--rw area | +--rw area
| +--rw interface | +--rw interface
2.7. OSPF Area Configuration 2.7. OSPF Area Configuration
The container area contains configurations of that area and the list The container area contains configurations of that area and the list
of interface container represents all the OSPF interfaces active in of interface containers represent all the OSPF interfaces active in
the enclosing area. the enclosing area.
The all-interfaces-inherit contains interface configuration that
could be inherited to all the OSPF interfaces defined in the area.
module: ospf module: ospf
+--rw ospf +--rw ospf
. .
. .
+--rw instance* [routing-instance af] +--rw instance* [routing-instance af]
. .
. .
+--rw areas +--rw areas
| +--rw area* [area-id] | +--rw area* [area-id]
| +--rw area-id area-id-type | +--rw area-id area-id-type
skipping to change at page 9, line 48 skipping to change at page 9, line 49
| | | +--rw hmac-sha-256? empty | | | +--rw hmac-sha-256? empty
| | +--:(hmac-sha-384) | | +--:(hmac-sha-384)
| | | +--rw hmac-sha-384? empty | | | +--rw hmac-sha-384? empty
| | +--:(hmac-sha-512) | | +--:(hmac-sha-512)
| | +--rw hmac-sha-512? empty | | +--rw hmac-sha-512? empty
2.8. OSPF Interface Configuration 2.8. OSPF Interface Configuration
The container interface contains configurations of that interface. The container interface contains configurations of that interface.
The ospf-interfaces also contain interface configuration that could
be inherited to all ospf-interface's defined.
module: ospf module: ospf
+--rw ospf +--rw ospf
. .
. .
+--rw instance* [routing-instance af] +--rw instance* [routing-instance af]
. .
. .
+--rw areas +--rw areas
| +--rw area* [area-id] | +--rw area* [area-id]
. .
. .
| +--rw interfaces | +--rw interfaces
| +--rw interface* [interface] | +--rw interface* [interface]
skipping to change at page 14, line 12 skipping to change at page 14, line 10
+--ro routing-instance? rt:routing-instance-ref +--ro routing-instance? rt:routing-instance-ref
+--ro routing-protocol-type? leafref +--ro routing-protocol-type? leafref
+--ro routing-protocol-name? leafref +--ro routing-protocol-name? leafref
+--ro af? leafref +--ro af? leafref
+--ro status? restart-status-type +--ro status? restart-status-type
+--ro restart-interval? uint16 +--ro restart-interval? uint16
+--ro exit-reason? restart-exit-reason-type +--ro exit-reason? restart-exit-reason-type
3. OSPF Segment Routing 3. OSPF Segment Routing
In additional to the OSPF base YANG model, this document also defines In addition to the OSPF base YANG model, this document also defines a
a model for OSPF segment routing. model for the OSPF segment routing feature.
The OSPF SR YANG module requires the base segment routing module The OSPF SR YANG module requires the base segment routing module
[I-D.litkowski-spring-sr-yang] to be supported as there is a strong [I-D.ietf-spring-sr-yang] to be supported, which defines the basic
relationship between those modules. segment routing configurations outside of any specific routing
protocol.
module: ietf-ospf-sr module: ietf-ospf-sr
augment /rt:routing/rt:routing-instance/rt:routing-protocols/ augment /rt:routing/rt:routing-instance/rt:routing-protocols/
rt:routing-protocol/ospf:ospf/ospf:instance: rt:routing-protocol/ospf:ospf/ospf:instance:
+--rw segment-routing +--rw segment-routing
+--rw enabled? boolean +--rw enabled? boolean
+--rw bindings +--rw bindings
+--rw advertise +--rw advertise
| +--rw policies* string | +--rw policies* string
+--rw receive? boolean +--rw receive? boolean
skipping to change at page 20, line 49 skipping to change at page 20, line 48
+--ro sr-algorithm-tlv +--ro sr-algorithm-tlv
| +--ro sr-algorithm* uint8 | +--ro sr-algorithm* uint8
+--ro sid-range-tlvs +--ro sid-range-tlvs
+--ro sid-range-tlv* +--ro sid-range-tlv*
+--ro range-size? ospf:uint24 +--ro range-size? ospf:uint24
+--ro sid-sub-tlv +--ro sid-sub-tlv
+--ro sid? uint32 +--ro sid? uint32
4. OSPF Yang Module 4. OSPF Yang Module
<CODE BEGINS> file "ietf-ospf@2015-07-06.yang" <CODE BEGINS> file "ietf-ospf@2015-09-02.yang"
module ietf-ospf { module ietf-ospf {
namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf";
prefix ospf; prefix ospf;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
import ietf-yang-types { import ietf-yang-types {
prefix "yang"; prefix "yang";
} }
skipping to change at page 21, line 50 skipping to change at page 22, line 4
<mailto:akr@cisco.com> <mailto:akr@cisco.com>
Editor: Derek Yeung Editor: Derek Yeung
<mailto:myeung@cisco.com> <mailto:myeung@cisco.com>
Author: Derek Yeung Author: Derek Yeung
<mailto:myeung@cisco.com> <mailto:myeung@cisco.com>
Author: Yingzhen Qu Author: Yingzhen Qu
<mailto:yiqu@cisco.com> <mailto:yiqu@cisco.com>
Author: Jeffrey Zhang Author: Jeffrey Zhang
<mailto:zzhang@juniper.net> <mailto:zzhang@juniper.net>
Author: Dean Bogdanovic
<mailto:deanb@juniper.net>
Author: Dean Bogdanovic
<mailto:ivandean@gmail.com>
Author: Kiran Agrahara Sreenivasa Author: Kiran Agrahara Sreenivasa
<mailto:kkoushik@Brocade.com>"; <mailto:kkoushik@cisco.com>";
description description
"This YANG module defines the generic configuration "This YANG module defines the generic configuration
data for OSPF, which is common across all of the vendor data for OSPF, which is common across all of the vendor
implementations of the protocol. It is intended that the module implementations of the protocol. It is intended that the module
will be extended by vendors to define vendor-specific will be extended by vendors to define vendor-specific
OSPF configuration parameters and policies, OSPF configuration parameters and policies,
for example route maps or route policies. for example route maps or route policies.
Terms and Acronyms Terms and Acronyms
skipping to change at page 22, line 29 skipping to change at page 22, line 31
IP (ip): Internet Protocol IP (ip): Internet Protocol
IPv4 (ipv4):Internet Protocol Version 4 IPv4 (ipv4):Internet Protocol Version 4
IPv6 (ipv6): Internet Protocol Version 6 IPv6 (ipv6): Internet Protocol Version 6
MTU (mtu) Maximum Transmission Unit MTU (mtu) Maximum Transmission Unit
"; ";
revision 2015-09-02 {
description
"* Author information update.
* Editorial changes";
reference
"RFC XXXX: A YANG Data Model for OSPF";
}
revision 2015-07-06 { revision 2015-07-06 {
description description
"* Remove support for protocol-centric config. "* Remove support for protocol-centric config.
* Enclose list in container, except for instance. * Enclose list in container, except for instance.
* Replace protocol-shutdown with admin-control. * Replace protocol-shutdown with admin-control.
* Add IPFRR per-interface config. * Add IPFRR per-interface config.
* Reorganize max-path etc node. * Reorganize max-path etc node.
* Add node-flag. * Add node-flag.
* Align config/operation hierarchy. * Align config/operation hierarchy.
* Use relative path for reference to rib. * Use relative path for reference to rib.
skipping to change at page 33, line 23 skipping to change at page 33, line 33
} }
grouping area-stat { grouping area-stat {
description "Per-area statistics."; description "Per-area statistics.";
leaf spf-runs-count { leaf spf-runs-count {
type yang:counter32; type yang:counter32;
description "The number of times that intra-area spf runs."; description "The number of times that intra-area spf runs.";
} }
leaf abr-count { leaf abr-count {
type yang:gauge32; type yang:gauge32;
description "The total number of area border routers reachable description
within this area."; "The total number of area border routers reachable
within this area.";
} }
leaf asbr-count { leaf asbr-count {
type yang:gauge32; type yang:gauge32;
description "The total number of AS border routers."; description "The total number of AS border routers.";
} }
leaf ar-nssa-translator-event-count { leaf ar-nssa-translator-event-count {
type yang:counter32; type yang:counter32;
description "The number of translator state changes."; description "The number of translator state changes.";
} }
leaf area-scope-lsa-count { leaf area-scope-lsa-count {
type yang:gauge32; type yang:gauge32;
description "The number of LSAs in this area, excluding description
as-external LSAs."; "The number of LSAs in this area, excluding
as-external LSAs.";
} }
leaf area-scope-lsa-cksum-sum { leaf area-scope-lsa-cksum-sum {
type int32; type int32;
description "The sum of the LSAs checksums."; description "The sum of the LSAs checksums.";
} }
container database { container database {
description "Container for area scope LSA type statistics."; description "Container for area scope LSA type statistics.";
list area-scope-lsa-type { list area-scope-lsa-type {
description "List of area scope LSA statistics"; description "List of area scope LSA statistics";
leaf lsa-type { leaf lsa-type {
skipping to change at page 34, line 22 skipping to change at page 34, line 34
} }
} }
} }
grouping interface-stat { grouping interface-stat {
description "Per-interface statistics"; description "Per-interface statistics";
leaf if-event-count { leaf if-event-count {
type yang:counter32; type yang:counter32;
description description
"The number of times this interface has changed its "The number of times this interface has changed its
state or an error has occurred."; state or an error has occurred.";
} }
leaf link-scope-lsa-count { leaf link-scope-lsa-count {
type yang:gauge32; type yang:gauge32;
description "The number of LSAs."; description "The number of LSAs.";
} }
leaf link-scope-lsa-cksum-sum { leaf link-scope-lsa-cksum-sum {
type uint32; type uint32;
description "The sum of LSAs LS checksums."; description "The sum of LSAs LS checksums.";
} }
container database { container database {
skipping to change at page 62, line 30 skipping to change at page 62, line 42
that uniquely identifies the router."; that uniquely identifies the router.";
} }
container admin-distance { container admin-distance {
description "Admin distance config state."; description "Admin distance config state.";
choice scope { choice scope {
description description
"Options for expressing admin distance "Options for expressing admin distance
as single or multiple values."; as single or multiple values.";
case single-value { case single-value {
leaf all { leaf all {
type uint8; type uint8;
description description
"Admin distance for intra-area, inter-area and "Admin distance for intra-area, inter-area and
external route."; external route.";
} }
} }
case multi-values { case multi-values {
choice granularity { choice granularity {
description description
"Options for expressing admin distance "Options for expressing admin distance
for intra-area and inter-area route."; for intra-area and inter-area route.";
skipping to change at page 90, line 30 skipping to change at page 90, line 38
type restart-exit-reason-type; type restart-exit-reason-type;
description description
"Restart exit reason."; "Restart exit reason.";
} }
description description
"This notification is sent when the graceful restart "This notification is sent when the graceful restart
state for the router has changed."; state for the router has changed.";
} }
} }
<CODE ENDS> <CODE ENDS>
]]</artwork>
</figure>
</t>
</section>
5. OSPF Segment Routing Yang Module <section title="OSPF Segment Routing Yang Module">
<t>
<figure>
<artwork><![CDATA[
<CODE BEGINS> file "ietf-ospf-sr@2015-09-02.yang"
<CODE BEGINS> file "ietf-ospf-sr@2015-07-06.yang"
module ietf-ospf-sr { module ietf-ospf-sr {
namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-sr"; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-sr";
prefix ospf-sr; prefix ospf-sr;
import ietf-inet-types { import ietf-inet-types {
prefix "inet"; prefix "inet";
} }
import ietf-yang-types { import ietf-yang-types {
skipping to change at page 91, line 32 skipping to change at page 91, line 48
WG Chair: Abhay Roy WG Chair: Abhay Roy
<mailto:akr@cisco.com> <mailto:akr@cisco.com>
Editor: Derek Yeung Editor: Derek Yeung
<mailto:myeung@cisco.com> <mailto:myeung@cisco.com>
Author: Derek Yeung Author: Derek Yeung
<mailto:myeung@cisco.com> <mailto:myeung@cisco.com>
Author: Yingzhen Qu Author: Yingzhen Qu
<mailto:yiqu@cisco.com> <mailto:yiqu@cisco.com>
Author: Acee Lindem
<mailto:acee@cisco.com>
Author: Jeffrey Zhang Author: Jeffrey Zhang
<mailto:zzhang@juniper.net> <mailto:zzhang@juniper.net>
Author: Ing-Wher Chen Author: Ing-Wher Chen
<mailto:ing-wher.chen@ericsson.com> <mailto:ing-wher.chen@ericsson.com>
Author: Greg Hankins Author: Greg Hankins
<mailto:greg.hankins@alcatel-lucent.com>"; <mailto:greg.hankins@alcatel-lucent.com>";
description description
"This YANG module defines the generic configuration "This YANG module defines the generic configuration
data for OSPF, which is common across all of the vendor data for OSPF, which is common across all of the vendor
implementations of the protocol. It is intended that the module implementations of the protocol. It is intended that the module
will be extended by vendors to define vendor-specific will be extended by vendors to define vendor-specific
skipping to change at page 92, line 4 skipping to change at page 92, line 23
implementations of the protocol. It is intended that the module implementations of the protocol. It is intended that the module
will be extended by vendors to define vendor-specific will be extended by vendors to define vendor-specific
OSPF configuration parameters and policies, OSPF configuration parameters and policies,
for example route maps or route policies. for example route maps or route policies.
Terms and Acronyms Terms and Acronyms
OSPF (ospf): Open Shortest Path First OSPF (ospf): Open Shortest Path First
IP (ip): Internet Protocol IP (ip): Internet Protocol
IPv4 (ipv4):Internet Protocol Version 4 IPv4 (ipv4):Internet Protocol Version 4
IPv6 (ipv6): Internet Protocol Version 6 IPv6 (ipv6): Internet Protocol Version 6
MTU (mtu) Maximum Transmission Unit MTU (mtu) Maximum Transmission Unit
"; ";
revision 2015-09-02 {
description
"* Author list update.
* Editorial changes.";
reference
"RFC XXXX: A YANG Data Model for OSPF Segment Routing";
}
revision 2015-07-06 { revision 2015-07-06 {
description description
"Initial revision."; "Initial revision.";
reference reference
"RFC XXXX: A YANG Data Model for OSPF Segment Routing"; "RFC XXXX: A YANG Data Model for OSPF Segment Routing";
} }
feature ti-lfa { feature ti-lfa {
description description
"Enhance IPFRR with ti-lfa support"; "Enhance IPFRR with ti-lfa support";
skipping to change at page 96, line 17 skipping to change at page 96, line 46
description "The cost of an ERO path."; description "The cost of an ERO path.";
leaf metric { leaf metric {
type uint32; type uint32;
description "The aggregate IGP or TE path cost."; description "The aggregate IGP or TE path cost.";
} }
} }
container ipv4-ero-sub-tlv { container ipv4-ero-sub-tlv {
description description
"The ipv4 ERO sub-tlv describes a path segment "The ipv4 ERO sub-tlv describes a path segment
using ipv4 address."; using ipv4 address.";
leaf flags { leaf flags {
type bits { type bits {
bit L { bit L {
description description
"If set, then the segment path is designated as "If set, then the segment path is designated as
'loose'. Otherwise as 'strict'."; 'loose'. Otherwise as 'strict'.";
} }
} }
description "Flags."; description "Flags.";
} }
leaf ipv4-address { leaf ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description "The address of the explicit route hop."; description "The address of the explicit route hop.";
} }
} }
container unnumbered-ero-sub-tlv { container unnumbered-ero-sub-tlv {
skipping to change at page 97, line 7 skipping to change at page 97, line 36
description "Flags."; description "Flags.";
} }
leaf router-id { leaf router-id {
type yang:dotted-quad; type yang:dotted-quad;
description "Router-id of the next-hop."; description "Router-id of the next-hop.";
} }
leaf interface-id { leaf interface-id {
type uint32; type uint32;
description description
"The identifier assigned to the link by the "The identifier assigned to the link by the
router specified by the router-id."; router specified by the router-id.";
} }
} }
container ipv4-backup-ero-sub-tlv { container ipv4-backup-ero-sub-tlv {
description description
"The ipv4 backup ERO sub-tlv describes a path "The ipv4 backup ERO sub-tlv describes a path
segment using ipv4 address."; segment using ipv4 address.";
leaf flags { leaf flags {
type bits { type bits {
bit L { bit L {
description description
"If set, then the segment path is designated as "If set, then the segment path is designated as
'loose'. Otherwise as 'strict'."; 'loose'. Otherwise as 'strict'.";
} }
} }
description "Flags."; description "Flags.";
} }
leaf ipv4-address { leaf ipv4-address {
type inet:ipv4-address; type inet:ipv4-address;
description "The address of the explicit route hop."; description "The address of the explicit route hop.";
} }
} }
container unnumbered-backup-ero-sub-tlv { container unnumbered-backup-ero-sub-tlv {
skipping to change at page 97, line 51 skipping to change at page 98, line 31
description "Flags."; description "Flags.";
} }
leaf router-id { leaf router-id {
type yang:dotted-quad; type yang:dotted-quad;
description "Router-id of the next-hop."; description "Router-id of the next-hop.";
} }
leaf interface-id { leaf interface-id {
type uint32; type uint32;
description description
"The identifier assigned to the link by the "The identifier assigned to the link by the
router specified by the router-id."; router specified by the router-id.";
} }
} }
} }
} }
} }
grouping extended-prefix-range-tlvs { grouping extended-prefix-range-tlvs {
description "Extended prefix range TLV grouping."; description "Extended prefix range TLV grouping.";
container extended-prefix-range-tlvs { container extended-prefix-range-tlvs {
skipping to change at page 103, line 51 skipping to change at page 104, line 31
"This augment is only valid for OSPFv2."; "This augment is only valid for OSPFv2.";
} }
description description
"SR specific TLVs for OSPFv2 type 11 opaque LSA."; "SR specific TLVs for OSPFv2 type 11 opaque LSA.";
uses extended-prefix-range-tlvs; uses extended-prefix-range-tlvs;
uses sr-algorithm-tlv; uses sr-algorithm-tlv;
uses sid-range-tlvs; uses sid-range-tlvs;
} }
} }
<CODE ENDS> <CODE ENDS>
6. Security Considerations 5. Security Considerations
The data model defined does not create any security implications. The data model defined does not create any security implications.
This draft does not change any underlying security issues inherent in This draft does not change any underlying security issues inherent in
[I-D.ietf-netmod-routing-cfg]. [I-D.ietf-netmod-routing-cfg].
7. Acknowledgements 6. Acknowledgements
The authors wish to thank Acee Lindem, Yi Yang, Alexander Clemm, The authors wish to thank Acee Lindem, Yi Yang, Alexander Clemm,
Gaurav Gupta, Ing-Wher Chen, Ladislav Lhotka, Stephane Litkowski, Gaurav Gupta, Ing-Wher Chen, Ladislav Lhotka, Stephane Litkowski,
Greg Hankins and Manish Gupta for their thorough reviews and helpful Greg Hankins and Manish Gupta for their thorough reviews and helpful
comments. comments.
This document was produced using Marshall Rose's xml2rfc tool. This document was produced using Marshall Rose's xml2rfc tool.
8. References 7. References
8.1. Normative References 7.1. Normative References
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits",
1793, April 1995. RFC 1793, DOI 10.17487/RFC1793, April 1995,
<http://www.rfc-editor.org/info/rfc1793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<http://www.rfc-editor.org/info/rfc2328>.
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, DOI 10.17487/RFC3101, January 2003,
<http://www.rfc-editor.org/info/rfc3101>.
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF
Restart", RFC 3623, November 2003. Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003,
<http://www.rfc-editor.org/info/rfc3623>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, September (TE) Extensions to OSPF Version 2", RFC 3630,
2003. DOI 10.17487/RFC3630, September 2003,
<http://www.rfc-editor.org/info/rfc3630>.
[RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the
Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Provider/Customer Edge Protocol for BGP/MPLS IP Virtual
Private Networks (VPNs)", RFC 4577, June 2006. Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577,
June 2006, <http://www.rfc-editor.org/info/rfc4577>.
[RFC4750] Joyal, D., Galecki, P., Giacalone, S., Coltun, R., and F. [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed.,
Baker, "OSPF Version 2 Management Information Base", RFC Coltun, R., and F. Baker, "OSPF Version 2 Management
4750, December 2006. Information Base", RFC 4750, DOI 10.17487/RFC4750,
December 2006, <http://www.rfc-editor.org/info/rfc4750>.
[RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful
Restart", RFC 5187, June 2008. Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008,
<http://www.rfc-editor.org/info/rfc5187>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5643] Joyal, D. and V. Manral, "Management Information Base for [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information
OSPFv3", RFC 5643, August 2009. Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August
2009, <http://www.rfc-editor.org/info/rfc5643>.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and
Aggarwal, "Support of Address Families in OSPFv3", RFC R. Aggarwal, "Support of Address Families in OSPFv3",
5838, April 2010. RFC 5838, DOI 10.17487/RFC5838, April 2010,
<http://www.rfc-editor.org/info/rfc5838>.
[RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
Network Configuration Protocol (NETCONF)", RFC 6020, the Network Configuration Protocol (NETCONF)", RFC 6020,
October 2010. DOI 10.17487/RFC6020, October 2010,
<http://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
Bierman, "Network Configuration Protocol (NETCONF)", RFC and A. Bierman, Ed., "Network Configuration Protocol
6241, June 2011. (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<http://www.rfc-editor.org/info/rfc6241>.
[RFC7223] Bjorklund, M., "A YANG Data Model for Interface [RFC7223] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 7223, May 2014. Management", RFC 7223, DOI 10.17487/RFC7223, May 2014,
<http://www.rfc-editor.org/info/rfc7223>.
8.2. Informative References 7.2. Informative References
[I-D.acee-rtg-yang-key-chain] [I-D.acee-rtg-yang-key-chain]
Lindem, A., Qu, Y., Yeung, D., Chen, H., Zhang, J., and Y. Lindem, A., Qu, Y., Yeung, D., Chen, H., Zhang, J., and Y.
Yang, "Key Chain YANG Data Model", draft-acee-rtg-yang- Yang, "Key Chain YANG Data Model", draft-acee-rtg-yang-
key-chain-07 (work in progress), July 2015. key-chain-07 (work in progress), July 2015.
[I-D.ietf-netmod-routing-cfg] [I-D.ietf-netmod-routing-cfg]
Lhotka, L. and A. Lindem, "A YANG Data Model for Routing Lhotka, L. and A. Lindem, "A YANG Data Model for Routing
Management", draft-ietf-netmod-routing-cfg-19 (work in Management", draft-ietf-netmod-routing-cfg-19 (work in
progress), May 2015. progress), May 2015.
[I-D.litkowski-spring-sr-yang] [I-D.ietf-spring-sr-yang]
Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG Litkowski, S., Qu, Y., Sarkar, P., and J. Tantsura, "YANG
Data Model for Segment Routing", draft-litkowski-spring- Data Model for Segment Routing", draft-ietf-spring-sr-
sr-yang-01 (work in progress), June 2015. yang-00 (work in progress), July 2015.
Authors' Addresses Authors' Addresses
Derek Yeung Derek Yeung
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: myeung@cisco.com EMail: myeung@cisco.com
Yingzhen Qu Yingzhen Qu
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
EMail: yiqu@cisco.com EMail: yiqu@cisco.com
Jeffrey Zhang Jeffrey Zhang
Juniper Networks Juniper Networks
skipping to change at page 106, line 21 skipping to change at page 107, line 29
Jeffrey Zhang Jeffrey Zhang
Juniper Networks Juniper Networks
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA USA
EMail: zzhang@juniper.net EMail: zzhang@juniper.net
Dean Bogdanovic Dean Bogdanovic
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
USA
EMail: deanb@juniper.net EMail: ivandean@gmail.com
Kiran Agrahara Sreenivasa Kiran Koushik Agrahara Sreenivasa
Brocade Communications System Cisco Systems
9442 Capital of Texas Hwy North 12515 Research Blvd, Bldg 4
Arboretum Plaza One, Suite 500 Austin, TX 78681
Austin, TX 78759
USA USA
EMail: kkoushik@brocade.com EMail: kkoushik@cisco.com
 End of changes. 72 change blocks. 
110 lines changed or deleted 160 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/