--- 1/draft-ietf-ospf-yang-21.txt 2019-06-22 16:13:35.892941527 -0700 +++ 2/draft-ietf-ospf-yang-22.txt 2019-06-22 16:13:36.144947957 -0700 @@ -1,25 +1,25 @@ Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu -Expires: July 28, 2019 Huawei +Expires: December 24, 2019 Huawei J. Zhang Juniper Networks I. Chen The MITRE Corporation A. Lindem Cisco Systems - January 24, 2019 + June 22, 2019 YANG Data Model for OSPF Protocol - draft-ietf-ospf-yang-21 + draft-ietf-ospf-yang-22 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 @@ -29,21 +29,21 @@ 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/. 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 July 28, 2019. + This Internet-Draft will expire on December 24, 2019. 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 publication of this document. Please review these documents @@ -63,100 +63,103 @@ 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 3. OSPF YANG Module . . . . . . . . . . . . . . . . . . . . . . 23 4. Security Considerations . . . . . . . . . . . . . . . . . . . 115 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 116 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.1. Normative References . . . . . . . . . . . . . . . . . . 117 - 7.2. Informative References . . . . . . . . . . . . . . . . . 123 + 7.2. Informative References . . . . . . . . . . . . . . . . . 122 Appendix A. Contributors' Addresses . . . . . . . . . . . . . . 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 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 APIs. This document defines a YANG data model that can be used to configure and manage OSPF and it is an augmentation to the core routing data - model. If fully conforms to the Network Management Datastore + model. It fully conforms to the Network Management Datastore Architecture (NDMA) [RFC8342]. A core routing data model is defined in [RFC8349], and it provides the basis for the development of data models for routing protocols. The interface data model is defined in [RFC8343] and is used for referencing interfaces from the routing protocol. The key-chain data model used for OSPF authentication is defined in [RFC8177] and provides both a reference to configured key- chains and an enumeration of cryptographic algorithms. Both OSPFv2 [RFC2328] and OSPFv3 [RFC5340] are supported. In addition to the core OSPF protocol, features described in other OSPF RFCs are also supported. These includes demand circuit [RFC1793], traffic engineering [RFC3630], multiple address family [RFC5838], - graceful restart [RFC3623] [RFC5187], NSSA [RFC3101], and OSPF(v3) as - a PE-CE Protocol [RFC4577], [RFC6565]. These non-core features are - optional in the OSPF data model. + graceful restart [RFC3623] [RFC5187], NSSA [RFC3101], and OSPFv2 or + OSPFv3 as a PE-CE Protocol [RFC4577], [RFC6565]. These non-core + features are optional in the OSPF data model. 1.1. Requirements Language 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.2. Tree Diagrams This document uses the graphical representation of data models defined in [RFC8340]. 2. Design of Data Model Although the basis of OSPF configuration elements like routers, areas, and interfaces remains the same, the detailed configuration model varies among router vendors. Differences are observed in terms - of how the protocol engine is tied to the routing domain, how - multiple protocol engines are be instantiated among others. + of how the protocol instance is tied to the routing domain, how + multiple protocol instances are be instantiated among others. The goal of this document is to define a data model that provides a common user interface to the OSPFv2 and OSPFv3 protocols. There is very little information that is designated as "mandatory", providing freedom for vendors to adapt this data model to their respective product implementations. 2.1. OSPF Operational State The OSPF operational state is included in the same tree as OSPF - configuration consistent with Network Management Datastore + configuration consistent with the Network Management Datastore Architecture [RFC8342]. Consequently, only the routing container in the ietf-routing model [RFC8349] is augmented. The routing-state container is not augmented. 2.2. Overview The OSPF YANG module defined in this document has all the common building blocks for the OSPF protocol. The OSPF YANG module augments the /routing/control-plane-protocols/ - control-plane-protocol path defined in the ietf-routing module. + control-plane-protocol path defined in the ietf-routing module. The + ietf-ospf model defines a single instance of OSPF which may be + instantiated as an OSPFv2 or OSPFv3 instance. Multiple instances are + instantiated as multiple control-plane protocols instances. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . . +--rw operation-mode? identityref +--rw af? identityref . @@ -178,25 +181,24 @@ | +--rw interface* [name] | . | . +--rw topologies {multi-topology}? +--rw topology* [name] . . The ospf module is intended to match to the vendor specific OSPF configuration construct that is identified by the local identifier - 'name'. The field 'version' allows support for OSPFv2 and OSPFv3. + 'name'. - The ospf container includes one OSPF protocol engine instance. The - instance includes OSPF router level configuration and operational - state. + The ospf container includes one OSPF protocol instance. The instance + includes OSPF router level configuration and operational state. The area and area/interface containers respectively define the OSPF configuration and operational state for OSPF areas and interfaces. The topologies container defines the OSPF configuration and operational state for OSPF topologies when the multi-topology feature is supported. 2.3. OSPFv2 and OSPFv3 @@ -225,100 +227,98 @@ 5. mtu-ignore: Support disabling OSPF Database Description packet 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 - suppression [RFC5082]. + support [RFC5082]. 9. nsr: Support OSPF Non-Stop Routing (NSR). 10. graceful-restart: Support Graceful OSPF Restart [RFC3623], [RFC5187]. - 11. admin-control: Support Administrative control of the protocol - state. - - 12. auto-cost: Support OSPF interface cost calculation according to + 11. auto-cost: Support OSPF interface cost calculation according to reference bandwidth [RFC2328]. - 13. max-ecmp: Support configuration of the maximum number of Equal- + 12. max-ecmp: Support configuration of the maximum number of Equal- Cost Multi-Path (ECMP) paths. - 14. max-lsa: Support configuration of the maximum number of LSAs the + 13. max-lsa: Support configuration of the maximum number of LSAs the OSPF instance will accept [RFC1765]. - 15. te-rid: Support configuration of the Traffic Engineering (TE) + 14. te-rid: Support configuration of the Traffic Engineering (TE) Router-ID, i.e., the Router Address described in Section 2.4.1 of [RFC3630] or the Router IPv6 Address TLV described in Section 3 of [RFC5329]. - 16. ldp-igp-sync: Support LDP IGP synchronization [RFC5443]. + 15. ldp-igp-sync: Support LDP IGP synchronization [RFC5443]. - 17. ospfv2-authentication-trailer: Support OSPFv2 Authentication - trailer as specified in [RFC5709] or [RFC7166]. + 16. ospfv2-authentication-trailer: Support OSPFv2 Authentication + trailer as specified in [RFC5709] or [RFC7474]. - 18. ospfv3-authentication-ipsec: Support IPsec for OSPFv3 + 17. ospfv3-authentication-ipsec: Support IPsec for OSPFv3 authentication [RFC4552]. - 19. ospfv3-authentication-trailer: Support OSPFv3 Authentication - trailer as specified in [RFC7474]. + 18. ospfv3-authentication-trailer: Support OSPFv3 Authentication + trailer as specified in [RFC7166]. - 20. fast-reroute: Support IP Fast Reroute (IP-FRR) [RFC5714]. + 19. fast-reroute: Support IP Fast Reroute (IP-FRR) [RFC5714]. - 21. node-flag: Support node-flag for OSPF prefixes. [RFC7684]. + 20. node-flag: Support node-flag for OSPF prefixes. [RFC7684]. - 22. node-tag: Support node admin tag for OSPF instances [RFC7777]. + 21. node-tag: Support node admin tag for OSPF instances [RFC7777]. - 23. lfa: Support Loop-Free Alternates (LFAs) [RFC5286]. + 22. lfa: Support Loop-Free Alternates (LFAs) [RFC5286]. - 24. remote-lfa: Support Remote Loop-Free Alternates (R-LFA) + 23. remote-lfa: Support Remote Loop-Free Alternates (R-LFA) [RFC7490]. - 25. stub-router: Support RFC 6987 OSPF Stub Router advertisement + 24. stub-router: Support RFC 6987 OSPF Stub Router advertisement [RFC6987]. - 26. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], + 25. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], [RFC6565]. - 27. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. + 26. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. - 28. bfd: Support BFD detection of OSPF neighbor reachability + 27. bfd: Support BFD detection of OSPF neighbor reachability [RFC5880], [RFC5881], and [I-D.ietf-bfd-yang]. - 29. hybrid-interface: Support OSPF Hybrid Broadcast and Point-to- + 28. hybrid-interface: Support OSPF Hybrid Broadcast and Point-to- Point Interfaces [RFC6845]. - 30. two-part-metric: Support OSPF Two-Part Metric [RFC8042]. + 29. two-part-metric: Support OSPF Two-Part Metric [RFC8042]. It is expected that vendors will support additional features through vendor-specific augmentations. 2.5. OSPF Router Configuration/Operational State The ospf container is the top-level container in this data model. It - represents an OSPF protocol engine instance and contains the router - level configuration and operational state. The operational state - includes the instance statistics, IETF SPF delay statistics, AS- - Scoped Link State Database, local RIB, SPF Log, and the LSA log. + represents an OSPF protocol instance and contains the router level + configuration and operational state. The operational state includes + 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 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 @@ -326,21 +326,20 @@ | | +--:(coarse) | | +--rw internal? uint8 | +--rw external? uint8 +--rw nsr {nsr}? | +--rw enable? boolean +--rw graceful-restart {graceful-restart}? | +--rw enable? boolean | +--rw helper-enable? boolean | +--rw restart-interval? uint16 | +--rw helper-strict-lsa-checking? boolean - +--rw enable? boolean {admin-control}? +--rw auto-cost {auto-cost}? | +--rw enable? boolean | +--rw reference-bandwidth? uint32 +--rw spf-control | +--rw paths? uint16 {max-ecmp}? | +--rw ietf-spf-delay {ietf-spf-delay}? | +--rw initial-delay? uint16 | +--rw short-delay? uint16 | +--rw long-delay? uint16 | +--rw hold-down? uint16 @@ -1051,21 +1050,22 @@ +--ro restart-interval? uint16 +--ro exit-reason? restart-exit-reason-type 2.9. OSPF RPC Operations The "ietf-ospf" module defines two RPC operations: o clear-database: reset the content of a particular OSPF Link State Database. - o clear-neighbor: restart a particular set of OSPF neighbor. + o clear-neighbor: Reset a particular OSPF neighbor or group of + neighbors associated with an OSPF interface. rpcs: +---x clear-neighbor | +---w input | +---w routing-protocol-name | + -> /rt:routing/control-plane-protocols/ | + control-plane-protocol/name | +---w interface? if:interface-ref +---x clear-database +---w input @@ -1073,21 +1073,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-01-24.yang" + file "ietf-ospf@2019-06-22.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"; } @@ -1142,25 +1142,21 @@ Editor: Derek Yeung Author: Acee Lindem Author: Yingzhen Qu Author: Jeffrey Zhang Author: Ing-Wher Chen - - Author: Dean Bogdanovic - - Author: Kiran Agrahara Sreenivasa - "; description "This YANG module defines the generic configuration and operational state for the OSPF protocol common to all vendor implementations. It is intended that the module will be extended by vendors to define vendor-specific OSPF configuration parameters and policies, for example, route maps or route policies. This YANG model conforms to the Network Management @@ -1172,21 +1168,21 @@ 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 Relating to IETF Documents (http://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; - revision 2019-01-24 { + revision 2019-06-22 { 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"; @@ -1244,24 +1241,20 @@ "Non-Stop-Routing (NSR) support."; } 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"; } - feature admin-control { - description - "Administrative control of the protocol state."; - } feature auto-cost { description "Calculate OSPF interface cost according to reference bandwidth."; reference "RFC 2328 - OSPF Version 2"; } feature max-ecmp { description @@ -3532,36 +3523,31 @@ metric."; } } grouping interface-common-config { description "Common configuration for all types of interfaces, including virtual links and sham links."; leaf hello-interval { - type uint16 { - range "1..65535"; - } + type rt-types:timer-value-seconds16; 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 uint32 { - range "1..2147483647"; - } - units seconds; + type rt-types:timer-value-seconds32; 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 @@ -3576,24 +3561,21 @@ 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 uint16 { - range "1..3600"; - } - units seconds; + type rt-types:timer-value-seconds16; 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; @@ -3612,21 +3594,20 @@ leaf hops { type uint8 { range "1..254"; } description "Maximum number of hops that an OSPF packet may have traversed before reception."; } } leaf enable { - if-feature admin-control; type boolean; default true; description "Enable/disable OSPF protocol on the interface."; } container authentication { description "Authentication configuration."; choice auth-type-selection { description @@ -3835,24 +3817,21 @@ 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 uint16 { - range "1..65535"; - } - units seconds; + type rt-types:timer-value-seconds16; 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"; @@ -3927,22 +3906,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 uint32; - units "seconds"; + type rt-types:timer-value-seconds32; 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; } } @@ -3944,38 +3922,37 @@ config false; description "Per-neighbor statistics"; uses neighbor-stat; } } grouping interface-common-state { description "OSPF interface common operational state."; reference "RFC2328 Section 9"; + leaf state { type if-state-type; config false; description "Interface state."; } leaf hello-timer { - type uint32; - units "seconds"; + type rt-types:timer-value-seconds16; config false; description "This timer tracks the remaining time before the next hello packet is sent on the interface."; } leaf wait-timer { - type uint32; - units "seconds"; + type rt-types:timer-value-seconds32; config false; description "This timer tracks the remaining time before the interface exits the Waiting state."; } leaf dr-router-id { type rt-types:router-id; config false; description "Designated Router (DR) Router ID."; } @@ -4371,27 +4347,33 @@ } description "Container for node admin tags."; } } grouping instance-config { description "OSPF instance config state."; + leaf enable { + type boolean; + default true; + description + "Enable/Disable the protocol."; + } + 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."; choice scope { description "Options for expressing preference as single or multiple values."; case single-value { leaf all { @@ -4475,29 +4455,20 @@ description "Interval to attempt graceful restart prior to failing (RFC 3623 Section B.1) (seconds)"; } leaf helper-strict-lsa-checking { type boolean; description "Terminate graceful restart when an LSA topology change is detected (RFC 3623 Section B.2)."; } - - } - - leaf enable { - if-feature admin-control; - type boolean; - default true; - description - "Enable/Disable the protocol."; } container auto-cost { if-feature auto-cost; description "Interface Auto-cost configuration state."; leaf enable { type boolean; description "Enable/Disable interface auto-cost."; @@ -5407,26 +5381,26 @@ uses notification-instance-hdr; uses notification-interface; uses notification-neighbor; leaf status { type restart-helper-status-type; description "Restart helper status."; } leaf age { - type uint32; - units seconds; + type rt-types:timer-value-seconds32; 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."; @@ -5506,21 +5481,21 @@ uses notification-instance-hdr; leaf status { type restart-status-type; description "Restart status."; } leaf restart-interval { type uint16 { - range "1..1800"; + range 1..1800; } units seconds; default "120"; description "Restart interval."; } leaf exit-reason { type restart-exit-reason-type; description @@ -5605,20 +5580,22 @@ 6. Acknowledgements The authors wish to thank Yi Yang, Alexander Clemm, Gaurav Gupta, Ladislav Lhotka, Stephane Litkowski, Greg Hankins, Manish Gupta and Alan Davey for their thorough reviews and helpful comments. Thanks to Tom Petch for last call review and improvement of the document organization. + Thanks to Alvaro Retana for AD comments. + This document was produced using Marshall Rose's xml2rfc tool. Author affiliation with The MITRE Corporation is provided for identification purposes only, and is not intended to convey or imply MITRE's concurrence with, or support for, the positions, opinions or viewpoints expressed. MITRE has approved this document for Public Release, Distribution Unlimited, with Public Release Case Number 18-3194. 7. References