--- 1/draft-ietf-ospf-yang-22.txt 2019-07-01 09:15:42.519433299 -0700 +++ 2/draft-ietf-ospf-yang-23.txt 2019-07-01 09:15:42.731438675 -0700 @@ -1,58 +1,58 @@ Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu -Expires: December 24, 2019 Huawei +Expires: January 2, 2020 Huawei J. Zhang Juniper Networks I. Chen The MITRE Corporation A. Lindem Cisco Systems - June 22, 2019 + July 1, 2019 YANG Data Model for OSPF Protocol - draft-ietf-ospf-yang-22 + draft-ietf-ospf-yang-23 Abstract This document defines a YANG data model that can be used to configure and manage OSPF. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- - Drafts is at http://datatracker.ietf.org/drafts/current/. + Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 24, 2019. + This Internet-Draft will expire on January 2, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info) in effect on the date of + (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 @@ -60,30 +60,30 @@ 1.2. Tree Diagrams . . . . . . . . . . . . . . . . . . . . . . 3 2. Design of Data Model . . . . . . . . . . . . . . . . . . . . 3 2.1. OSPF Operational State . . . . . . . . . . . . . . . . . 3 2.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. OSPFv2 and OSPFv3 . . . . . . . . . . . . . . . . . . . . 5 2.4. Optional Features . . . . . . . . . . . . . . . . . . . . 5 2.5. OSPF Router Configuration/Operational State . . . . . . . 7 2.6. OSPF Area Configuration/Operational State . . . . . . . . 10 2.7. OSPF Interface Configuration/Operational State . . . . . 16 2.8. OSPF notification . . . . . . . . . . . . . . . . . . . . 19 - 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 22 + 2.9. OSPF RPC Operations . . . . . . . . . . . . . . . . . . . 23 3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 115 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 - 7.1. Normative References . . . . . . . . . . . . . . . . . . 117 - 7.2. Informative References . . . . . . . . . . . . . . . . . 122 - Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 124 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 116 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 118 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 118 + 7.2. Informative References . . . . . . . . . . . . . . . . . 123 + Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 125 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 125 1. Overview YANG [RFC6020][RFC7950] is a data definition language used to define the contents of a conceptual data store that allows networked devices to be managed using NETCONF [RFC6241]. YANG is proving relevant beyond its initial confines, as bindings to other interfaces (e.g., ReST) and encodings other than XML (e.g., JSON) are being defined. Furthermore, YANG data models can be used as the basis for implementation of other interfaces, such as CLI and programmatic @@ -229,21 +229,28 @@ MTU mismatch checking. 6. lls: Support OSPF link-local signaling (LLS) [RFC5613]. 7. prefix-suppression: Support OSPF prefix advertisement suppression [RFC6860]. 8. ttl-security: Support OSPF Time to Live (TTL) security check support [RFC5082]. - 9. nsr: Support OSPF Non-Stop Routing (NSR). + 9. nsr: Support OSPF Non-Stop Routing (NSR). The OSPF NSR feature + allows a router with redundant control-plane capability (e.g., + dual Route-Processor (RP) cards) to maintain its state and + adjacencies during planned and unplanned control-plane + processing restarts. It differs from graceful-restart or Non- + Stop Forwarding (NSF) in that no protocol signaling or + assistance from adjacent OSPF neighbors is required to recover + control-plane state. 10. graceful-restart: Support Graceful OSPF Restart [RFC3623], [RFC5187]. 11. auto-cost: Support OSPF interface cost calculation according to reference bandwidth [RFC2328]. 12. max-ecmp: Support configuration of the maximum number of Equal- Cost Multi-Path (ECMP) paths. @@ -304,21 +311,21 @@ the instance statistics, IETF SPF delay statistics, AS-Scoped Link State Database, local RIB, SPF Log, and the LSA log. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw af iana-rt-types:address-family - +--rw enable? boolean {admin-control}? + +--rw enable? boolean +--rw explicit-router-id? rt-types:router-id | {explicit-router-id}? +--rw preference | +--rw (scope)? | +--:(single-value) | | +--rw all? uint8 | +--:(multi-values) | +--rw (granularity)? | | +--:(detail) | | | +--rw intra-area? uint8 @@ -568,21 +575,20 @@ | | +--rw router-id rt-types:router-id | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean - | | | {admin-control}? | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref @@ -651,21 +657,20 @@ | | +--rw remote-id inet:ip-address | | +--rw hello-interval? uint16 | | +--rw dead-interval? uint32 | | +--rw retransmit-interval? uint16 | | +--rw transmit-delay? uint16 | | +--rw lls? boolean {lls}? | | +--rw ttl-security {ttl-security}? | | | +--rw enable? boolean | | | +--rw hops? uint8 | | +--rw enable? boolean - | | | {admin-control}? | | +--rw authentication | | | +--rw (auth-type-selection)? | | | +--:(ospfv2-auth) | | | | +--rw ospfv2-auth-trailer-rfc? | | | | | ospfv2-auth-trailer-rfc-version | | | | | {ospfv2-authentication-trailer}? | | | | +--rw (ospfv2-auth-specification)? | | | | +--:(auth-key-chain) {key-chain}? | | | | | +--rw ospfv2-key-chain? | | | | | key-chain:key-chain-ref @@ -783,21 +788,20 @@ | | +--rw enable? boolean | +--rw hello-interval? uint16 | +--rw dead-interval? uint32 | +--rw retransmit-interval? uint16 | +--rw transmit-delay? uint16 | +--rw lls? boolean {lls}? | +--rw ttl-security {ttl-security}? | | +--rw enable? boolean | | +--rw hops? uint8 | +--rw enable? boolean - | {admin-control}? | +--rw authentication | | +--rw (auth-type-selection)? | | +--:(ospfv2-auth) | | | +--rw ospfv2-auth-trailer-rfc? | | | | ospfv2-auth-trailer-rfc-version | | | | {ospfv2-authentication-trailer}? | | | +--rw (ospfv2-auth-specification)? | | | +--:(auth-key-chain) {key-chain}? | | | | +--rw ospfv2-key-chain? | | | | key-chain:key-chain-ref @@ -1073,21 +1076,21 @@ -> /rt:routing/control-plane-protocols/ control-plane-protocol/name 3. OSPF YANG Module The following RFCs and drafts are not referenced in the document text but are referenced in the ietf-ospf.yang module: [RFC0905], [RFC4576], [RFC4973], [RFC5250], [RFC5309], [RFC5642], [RFC5881], [RFC6991], [RFC7770], [RFC8294], and [RFC8476]. - file "ietf-ospf@2019-06-22.yang" + file "ietf-ospf@2019-07-01.yang" module ietf-ospf { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf"; prefix ospf; import ietf-inet-types { prefix "inet"; reference "RFC 6991 - Common YANG Data Types"; } @@ -1159,30 +1163,40 @@ OSPF configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8242. Copyright (c) 2018 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or - without modification, is permitted pursuant to, and subject - to the license terms contained in, the Simplified BSD License - set forth in Section 4.c of the IETF Trust's Legal Provisions + without modification, is permitted pursuant to, and subject to + the license terms contained in, the Simplified BSD License set + forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents - (http://trustee.ietf.org/license-info). + (https://trustee.ietf.org/license-info). + + This version of this YANG module is part of RFC XXXX + (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself + for full legal notices. + + The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL + NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', + 'MAY', and 'OPTIONAL' in this document are to be interpreted as + described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, + they appear in all capitals, as shown here. This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2019-06-22 { + revision 2019-07-01 { description "Initial revision."; reference "RFC XXXX: A YANG Data Model for OSPF."; } feature multi-topology { description "Support Multiple-Topology Routing (MTR)."; reference "RFC 4915 - Multi-Topology Routing"; @@ -1231,21 +1244,28 @@ feature ttl-security { description "OSPF Time to Live (TTL) security check support."; reference "RFC 5082 - The Generalized TTL Security Mechanism (GTSM)"; } feature nsr { description - "Non-Stop-Routing (NSR) support."; + "Non-Stop-Routing (NSR) support. The OSPF NSR feature + allows a router with redundant control-plane capability + (e.g., dual Route-Processor (RP) cards) to maintain its + state and adjacencies during planned and unplanned + OSPF instance restarts. It differs from graceful-restart + or Non-Stop Forwarding (NSF) in that no protocol signaling + or assistance from adjacent OSPF neighbors is required to + recover control-plane state."; } feature graceful-restart { description "Graceful OSPF Restart as defined in RFC 3623 and RFC 5187."; reference "RFC 3623 - Graceful OSPF Restart RFC 5187 - OSPFv3 Graceful Restart"; } @@ -1698,24 +1718,25 @@ enum point-to-point { value "4"; description "Interface point-to-point state."; } enum dr { value "5"; description "Interface Designated Router (DR) state."; } - enum backup { + enum bdr { value "6"; description "Interface Backup Designated Router (BDR) state."; + } enum dr-other { value "7"; description "Interface Other Designated Router state."; } } description "OSPF interface state type."; } @@ -3040,24 +3060,28 @@ } container body { description "Decoded OSPF LSA body data."; uses ospfv3-lsa-body; } } grouping lsa-common { description "Common fields for OSPF LSA representation."; - leaf decoded-completed { + leaf decode-completed { type boolean; description - "The OSPF LSA body is fully decoded."; + "The OSPF LSA body was successfully decoded other than + unknown TLVs. Unknown LSAs types and OSPFv2 unknown + opaque LSA types are not decoded. Additionally, + malformed LSAs are generally not accepted and are + not be in the Link State Database."; } leaf raw-data { type yang:hex-string; description "The complete LSA in network byte order hexadecimal as received or originated."; } } grouping lsa { @@ -3254,21 +3279,21 @@ if-feature lfa; description "This container may be augmented with global parameters for Loop-Free Alternatives (LFA). Container creation has no effect on LFA activation."; } } } grouping instance-fast-reroute-state { - description "IPFRR state data grouping"; + description "IP-FRR state data grouping"; container protected-routes { if-feature fast-reroute; config false; description "Instance protection statistics"; list address-family-stats { key "address-family prefix alternate"; description "Per Address Family protected prefix information"; @@ -3523,31 +3548,33 @@ metric."; } } grouping interface-common-config { description "Common configuration for all types of interfaces, including virtual links and sham links."; leaf hello-interval { - type rt-types:timer-value-seconds16; + type uint16; + units seconds; description "Interval between hello packets (seconds). It must be the same for all routers on the same network. Different networks, implementations, and deployments will use different hello-intervals. A sample value for a LAN network would be 10 seconds."; } leaf dead-interval { - type rt-types:timer-value-seconds32; + type uint16; + units seconds; must "../dead-interval > ../hello-interval" { error-message "The dead interval must be " + "larger than the hello interval"; description "The value MUST be greater than 'hello-interval'."; } description "Interval after which a neighbor is declared down (seconds) if hello packets are not received. It is typically 3 or 4 times the hello-interval. A typical @@ -3561,21 +3588,22 @@ units seconds; description "Interval between retransmitting unacknowledged Link State Advertisements (LSAs) (seconds). This should be well over the round-trip transmit delay for any two routers on the network. A sample value would be 5 seconds."; } leaf transmit-delay { - type rt-types:timer-value-seconds16; + type uint16; + units seconds; description "Estimated time needed to transmit Link State Update (LSU) packets on the interface (seconds). LSAs have their age incremented by this amount on advertised on the interface. A sample value would be 1 second."; } leaf lls { if-feature lls; type boolean; @@ -3640,33 +3668,29 @@ leaf ospfv2-key-id { type uint32; description "Key Identifier"; } leaf ospfv2-key { type string; description "OSPFv2 authentication key. The length of the key may be dependent on the - cryptographic algorithm. In cases where it is - not, a key length of at least 32 octets should - be supported to allow for interoperability - with strong keys."; + cryptographic algorithm."; } leaf ospfv2-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } - } } } case ospfv3-auth-ipsec { when "derived-from-or-self(../../../../../../rt:type, " + "'ospf:ospfv3')" { description "Applied to OSPFv3 only."; } if-feature ospfv3-authentication-ipsec; leaf sa { @@ -3694,26 +3719,23 @@ } case auth-key-explicit { leaf ospfv3-sa-id { type uint16; description "Security Association (SA) Identifier"; } leaf ospfv3-key { type string; description - "OSPFv2 authentication key. The + "OSPFv3 authentication key. The length of the key may be dependent on the - cryptographic algorithm. In cases where it is - not, a key length of at least 32 octets should - be supported to allow for interoperability - with strong keys."; + cryptographic algorithm."; } leaf ospfv3-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } @@ -3817,32 +3839,31 @@ type uint16 { range "1..65535"; } description "Neighbor cost. Different implementations have different default costs with some defaulting to a cost inversely proportional to the interface speed. Others will default to 1 equating the cost to a hop count." ; } leaf poll-interval { - type rt-types:timer-value-seconds16; + type uint16; + units seconds; description "Neighbor poll interval (seconds) for sending OSPF hello packets to discover the neighbor on NBMA networks. This interval dictates the granularity for discovery of new neighbors. A sample would be 2 minutes for a legacy Packet Data Network (PDN) X.25 network."; } leaf priority { - type uint8 { - range "1..255"; - } + type uint8; description "Neighbor priority for DR election."; } } } leaf node-flag { if-feature node-flag; type boolean; default false; description @@ -3906,21 +3927,21 @@ description "OSPF neighbor state."; } leaf cost { type uint32; config false; description "Cost to reach neighbor for Point-to-Multipoint and Hybrid networks"; } leaf dead-timer { - type rt-types:timer-value-seconds32; + type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the neighbor is declared dead."; } container statistics { config false; description "Per-neighbor statistics"; uses neighbor-stat; } } @@ -4246,51 +4268,55 @@ leaf route-tag { type uint32; description "Route tag for this route."; } } } } grouping ietf-spf-delay { leaf initial-delay { - type rt-types:timer-value-milliseconds; + type uint32; + units milliseconds; description "Delay used while in QUIET state (milliseconds)."; } leaf short-delay { - type rt-types:timer-value-milliseconds; + type uint32; + units milliseconds; description "Delay used while in SHORT_WAIT state (milliseconds)."; } leaf long-delay { - type rt-types:timer-value-milliseconds; + type uint32; + units milliseconds; description "Delay used while in LONG_WAIT state (milliseconds)."; } leaf hold-down { - type rt-types:timer-value-milliseconds; + type uint32; + units milliseconds; description "Timer used to consider an IGP stability period (milliseconds)."; } leaf time-to-learn { - type rt-types:timer-value-milliseconds; + type uint32; + units milliseconds; description "Duration used to learn all the IGP events related to a single component failure (milliseconds)."; } leaf current-state { type enumeration { enum "quiet" { description "QUIET state"; - } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description @@ -4290,27 +4316,27 @@ } enum "long-wait" { description "LONG_WAIT state"; } } config false; description "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { - type rt-types:timer-value-seconds16; + type rt-types:timer-value-milliseconds; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { - type rt-types:timer-value-seconds16; + type rt-types:timer-value-milliseconds; config false; description "Remaining time until hold-down timer fires."; } leaf last-event-received { type yang:timestamp; config false; description "Time of last SPF triggering event."; } @@ -4363,21 +4389,27 @@ leaf explicit-router-id { if-feature explicit-router-id; type rt-types:router-id; description "Defined in RFC 2328. A 32-bit number that uniquely identifies the router."; } container preference { - description "Route preference config state."; + description + "Route preference configuration In many + implementations, preference is referred to as + administrative distance."; + reference + "RFC 8349 - A YANG Data Model for Routing Management + (NMDA Version)"; choice scope { description "Options for expressing preference as single or multiple values."; case single-value { leaf all { type uint8; description "Preference for intra-area, inter-area, and external routes."; @@ -4526,25 +4558,26 @@ choice trigger { description "Specific triggers which will enable stub router state."; container always { presence "Enables unconditional stub router support"; description "Unconditional stub router state (advertise - transit links with max metric"; + transit links with MaxLinkMetric"; + reference "RFC 6987 - OSPF Stub Router + Advertisement"; } } } - container mpls { description "OSPF MPLS config state."; container te-rid { if-feature te-rid; description "Stable OSPF Router IP Address used for Traffic Engineering (TE)"; leaf ipv4-router-id { type inet:ipv4-address; @@ -5381,26 +5411,25 @@ uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf status { type restart-helper-status-type; description "Restart helper status."; } leaf age { - type rt-types:timer-value-seconds32; + type rt-types:timer-value-seconds16; description "Remaining time in current OSPF graceful restart interval when the router is acting as a restart helper for the neighbor."; - } leaf exit-reason { type restart-exit-reason-type; description "Restart helper exit reason."; } description "This notification is sent when a neighbor restart helper status change is detected."; @@ -5525,41 +5554,48 @@ operations and content. There are a number of data nodes defined in ietf-ospf.yang module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. For OSPF, the ability to modify OSPF configuration will allow the entire OSPF domain to be compromised including peering with unauthorized routers to misroute - traffic or mount a massive Denial-of-Service (DoS) attack. The - security considerations of OSPFv2 [RFC2328] and [RFC5340] apply to - the ietf-ospf.yang module as well. + traffic or mount a massive Denial-of-Service (DoS) attack. Some of the readable data nodes in the ietf-ospf.yang module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. The exposure of the Link State Database (LSDB) will expose the detailed topology of the network. This may be undesirable since both due to the fact that exposure may facilitate other attacks. Additionally, network operators may consider their topologies to be sensitive confidential data. For OSPF authentication, configuration is supported via the specification of key-chains [RFC8177] or the direct specification of key and authentication algorithm. Hence, authentication configuration using the "auth-table-trailer" case in the "authentication" container inherits the security considerations of [RFC8177]. This includes the considerations with respect to the local storage and handling of authentication keys. + Additionally, local specificationn of OSPF authentication keys and + the associated authentication algorithm is supported for legacy + implementations that do not support key-chains [RFC8177] for legacy + implementations that do not support key-chains. It is RECOMMENDED + that implementations migrate to key-chains due the seamless support + of key and algorithm rollover, as well as, the encryption of key + using the Advanced Encryption Standard (AES) Key Wrap Padding + Algorithm [RFC5649]. + Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. The OSPF YANG module support the "clear-neighbor" and "clear-database" RPCs. If access to either of these is compromised, they can result in temporary network outages be employed to mount DoS attacks. 5. IANA Considerations This document registers a URI in the IETF XML registry [RFC3688]. @@ -5601,176 +5637,181 @@ 7. References 7.1. Normative References [I-D.ietf-bfd-yang] Rahman, R., Zheng, L., Jethanandani, M., Networks, J., and G. Mirsky, "YANG Data Model for Bidirectional Forwarding Detection (BFD)", draft-ietf-bfd-yang-17 (work in progress), August 2018. + [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, + DOI 10.17487/RFC1765, March 1995, + . + [RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, DOI 10.17487/RFC1793, April 1995, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, - DOI 10.17487/RFC2119, March 1997, . + DOI 10.17487/RFC2119, March 1997, + . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, - DOI 10.17487/RFC2328, April 1998, . + DOI 10.17487/RFC2328, April 1998, + . [RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, DOI 10.17487/RFC3101, January 2003, . [RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, DOI 10.17487/RFC3623, November 2003, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, - DOI 10.17487/RFC3630, September 2003, . + DOI 10.17487/RFC3630, September 2003, + . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, - DOI 10.17487/RFC3688, January 2004, . + DOI 10.17487/RFC3688, January 2004, + . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, DOI 10.17487/RFC4576, June 2006, . [RFC4577] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, DOI 10.17487/RFC4577, June 2006, . - [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., - Coltun, R., and F. Baker, "OSPF Version 2 Management - Information Base", RFC 4750, DOI 10.17487/RFC4750, - December 2006, . - [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, . + [RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental + Extension to OSPF for Traffic Engineering", RFC 4973, + DOI 10.17487/RFC4973, July 2007, + . + [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, . [RFC5185] Mirtorabi, S., Psenak, P., Lindem, A., Ed., and A. Oswal, "OSPF Multi-Area Adjacency", RFC 5185, - DOI 10.17487/RFC5185, May 2008, . + DOI 10.17487/RFC5185, May 2008, + . [RFC5187] Pillay-Esnault, P. and A. Lindem, "OSPFv3 Graceful Restart", RFC 5187, DOI 10.17487/RFC5187, June 2008, . [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC5286] Atlas, A., Ed. and A. Zinin, Ed., "Basic Specification for IP Fast Reroute: Loop-Free Alternates", RFC 5286, - DOI 10.17487/RFC5286, September 2008, . + DOI 10.17487/RFC5286, September 2008, + . + + [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation + over LAN in Link State Routing Protocols", RFC 5309, + DOI 10.17487/RFC5309, October 2008, + . [RFC5329] Ishiguro, K., Manral, V., Davey, A., and A. Lindem, Ed., "Traffic Engineering Extensions to OSPF Version 3", RFC 5329, DOI 10.17487/RFC5329, September 2008, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, - DOI 10.17487/RFC5613, August 2009, . + DOI 10.17487/RFC5613, August 2009, + . [RFC5642] Venkata, S., Harwani, S., Pignataro, C., and D. McPherson, "Dynamic Hostname Exchange Mechanism for OSPF", RFC 5642, - DOI 10.17487/RFC5642, August 2009, . - - [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information - Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August - 2009, . + DOI 10.17487/RFC5642, August 2009, + . [RFC5709] Bhatia, M., Manral, V., Fanto, M., White, R., Barnes, M., Li, T., and R. Atkinson, "OSPFv2 HMAC-SHA Cryptographic Authentication", RFC 5709, DOI 10.17487/RFC5709, October 2009, . + [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", + RFC 5714, DOI 10.17487/RFC5714, January 2010, + . + [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, . - [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection - (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, - . - - [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection - (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, - DOI 10.17487/RFC5881, June 2010, . - [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, - DOI 10.17487/RFC6020, October 2010, . + DOI 10.17487/RFC6020, October 2010, + . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, . [RFC6565] Pillay-Esnault, P., Moyer, P., Doyle, J., Ertekin, E., and M. Lundberg, "OSPFv3 as a Provider Edge to Customer Edge (PE-CE) Routing Protocol", RFC 6565, DOI 10.17487/RFC6565, June 2012, . [RFC6845] Sheth, N., Wang, L., and J. Zhang, "OSPF Hybrid Broadcast and Point-to-Multipoint Interface Type", RFC 6845, - DOI 10.17487/RFC6845, January 2013, . + DOI 10.17487/RFC6845, January 2013, + . [RFC6860] Yang, Y., Retana, A., and A. Roy, "Hiding Transit-Only Networks in OSPF", RFC 6860, DOI 10.17487/RFC6860, January 2013, . + [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. + McPherson, "OSPF Stub Router Advertisement", RFC 6987, + DOI 10.17487/RFC6987, September 2013, + . + [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, - DOI 10.17487/RFC7166, March 2014, . + DOI 10.17487/RFC7166, March 2014, + . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . [RFC7490] Bryant, S., Filsfils, C., Previdi, S., Shand, M., and N. So, "Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)", RFC 7490, DOI 10.17487/RFC7490, April 2015, . @@ -5801,98 +5842,98 @@ [RFC8042] Zhang, Z., Wang, L., and A. Lindem, "OSPF Two-Part Metric", RFC 8042, DOI 10.17487/RFC8042, December 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8177] Lindem, A., Ed., Qu, Y., Yeung, D., Chen, I., and J. Zhang, "YANG Data Model for Key Chains", RFC 8177, - DOI 10.17487/RFC8177, June 2017, . + DOI 10.17487/RFC8177, June 2017, + . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, - DOI 10.17487/RFC8294, December 2017, . + DOI 10.17487/RFC8294, December 2017, + . [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, - DOI 10.17487/RFC8341, March 2018, . + DOI 10.17487/RFC8341, March 2018, + . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8343] Bjorklund, M., "A YANG Data Model for Interface Management", RFC 8343, DOI 10.17487/RFC8343, March 2018, . [RFC8349] Lhotka, L., Lindem, A., and Y. Qu, "A YANG Data Model for Routing Management (NMDA Version)", RFC 8349, - DOI 10.17487/RFC8349, March 2018, . + DOI 10.17487/RFC8349, March 2018, + . [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A., Francois, P., and C. Bowers, "Shortest Path First (SPF) Back-Off Delay Algorithm for Link-State IGPs", RFC 8405, - DOI 10.17487/RFC8405, June 2018, . + DOI 10.17487/RFC8405, June 2018, + . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, - DOI 10.17487/RFC8476, December 2018, . + DOI 10.17487/RFC8476, December 2018, + . 7.2. Informative References [RFC0905] "ISO Transport Protocol specification ISO DP 8073", RFC 905, DOI 10.17487/RFC0905, April 1984, . - [RFC1765] Moy, J., "OSPF Database Overflow", RFC 1765, - DOI 10.17487/RFC1765, March 1995, . - - [RFC4973] Srisuresh, P. and P. Joseph, "OSPF-xTE: Experimental - Extension to OSPF for Traffic Engineering", RFC 4973, - DOI 10.17487/RFC4973, July 2007, . - - [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation - over LAN in Link State Routing Protocols", RFC 5309, - DOI 10.17487/RFC5309, October 2008, . + [RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., + Coltun, R., and F. Baker, "OSPF Version 2 Management + Information Base", RFC 4750, DOI 10.17487/RFC4750, + December 2006, . [RFC5443] Jork, M., Atlas, A., and L. Fang, "LDP IGP Synchronization", RFC 5443, DOI 10.17487/RFC5443, March 2009, . - [RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", - RFC 5714, DOI 10.17487/RFC5714, January 2010, - . + [RFC5643] Joyal, D., Ed. and V. Manral, Ed., "Management Information + Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August + 2009, . - [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. - McPherson, "OSPF Stub Router Advertisement", RFC 6987, - DOI 10.17487/RFC6987, September 2013, . + [RFC5649] Housley, R. and M. Dworkin, "Advanced Encryption Standard + (AES) Key Wrap with Padding Algorithm", RFC 5649, + DOI 10.17487/RFC5649, September 2009, + . + + [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, + . + + [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection + (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, + DOI 10.17487/RFC5881, June 2010, + . Appendix A. Contributors' Addresses Dean Bogdanovic Volta Networks, Inc. EMail: dean@voltanet.io Kiran Koushik Agrahara Sreenivasa Verizon