--- 1/draft-ietf-ospf-yang-20.txt 2019-01-24 06:13:11.995122135 -0800 +++ 2/draft-ietf-ospf-yang-21.txt 2019-01-24 06:13:12.203127111 -0800 @@ -1,25 +1,25 @@ Internet D. Yeung Internet-Draft Arrcus Intended status: Standards Track Y. Qu -Expires: June 22, 2019 Huawei +Expires: July 28, 2019 Huawei J. Zhang Juniper Networks I. Chen The MITRE Corporation A. Lindem Cisco Systems - December 19, 2018 + January 24, 2019 YANG Data Model for OSPF Protocol - draft-ietf-ospf-yang-20 + draft-ietf-ospf-yang-21 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,25 +29,25 @@ 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 June 22, 2019. + This Internet-Draft will expire on July 28, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 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 @@ -63,26 +63,26 @@ 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 . . . . . . . . . . . . . . . . . . . . . 116 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 117 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 117 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.1. Normative References . . . . . . . . . . . . . . . . . . 117 - 7.2. Informative References . . . . . . . . . . . . . . . . . 122 - Appendix A. Contributors' Addreses . . . . . . . . . . . . . . . 124 + 7.2. Informative References . . . . . . . . . . . . . . . . . 123 + 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 @@ -207,22 +207,21 @@ accommodate the differences between OSPFv2 and OSPFv3. 2.4. Optional Features Optional features are beyond the basic OSPF configuration and it is the responsibility of each vendor to decide whether to support a given feature on a particular device. This model defines the following optional features: - 1. multi-topology: Support Multiple-Topolgy Routing (MTR) - [RFC4915]. + 1. multi-topology: Support Multi-Topology Routing (MTR) [RFC4915]. 2. multi-area-adj: Support OSPF multi-area adjacency [RFC5185]. 3. explicit-router-id: Support explicit per-instance Router-ID specification. 4. demand-circuit: Support OSPF demand circuits [RFC1793]. 5. mtu-ignore: Support disabling OSPF Database Description packet MTU mismatch checking. @@ -283,31 +282,31 @@ [RFC6987]. 26. pe-ce-protocol: Support OSPF as a PE-CE protocol [RFC4577], [RFC6565]. 27. ietf-spf-delay: Support IETF SPF delay algorithm [RFC8405]. 28. bfd: Support BFD detection of OSPF neighbor reachability [RFC5880], [RFC5881], and [I-D.ietf-bfd-yang]. - 29. hygrid-interface: Support OSPF Hybrid Broadcast and Point-to- + 29. hybrid-interface: Support OSPF Hybrid Broadcast and Point-to- Point Interfaces [RFC6845]. 30. 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 + 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. module: ietf-ospf augment /rt:routing/rt:control-plane-protocols/ rt:control-plane-protocol: +--rw ospf . @@ -1074,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@2018-12-16.yang" + file "ietf-ospf@2019-01-24.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"; } @@ -1155,39 +1154,39 @@ Author: Kiran Agrahara Sreenivasa ../hello-interval" { error-message "The dead interval must be " + "larger than the hello interval"; description - "The value MUST be greater than 'hello-internval'."; + "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 value for LAN networks is 40 seconds."; + } + leaf retransmit-interval { type uint16 { range "1..3600"; } 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 @@ -3656,22 +3657,26 @@ } case auth-key-explicit { leaf ospfv2-key-id { type uint32; description "Key Identifier"; } leaf ospfv2-key { type string; description - "Key string in ASCII format."; - + "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."; } leaf ospfv2-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } @@ -3707,21 +3712,26 @@ } case auth-key-explicit { leaf ospfv3-sa-id { type uint16; description "Security Association (SA) Identifier"; } leaf ospfv3-key { type string; description - "Key string in ASCII format."; + "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."; } leaf ospfv3-crypto-algorithm { type identityref { base key-chain:crypto-algorithm; } description "Cryptographic algorithm associated with key."; } } } @@ -3819,22 +3831,22 @@ "Neighbor Router ID, IPv4 address, or IPv6 address."; } leaf cost { type uint16 { range "1..65535"; } description "Neighbor cost. Different implementations have different default costs with some defaulting to a cost inversely - proportioal to the interface speed. Others will default - to 1 equating the cost to a hop count." ; + 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; description "Neighbor poll interval (seconds) for sending OSPF hello packets to discover the neighbor on NBMA networks. This interval dictates the granularity for @@ -4301,21 +4311,21 @@ } enum "short-wait" { description "SHORT_WAIT state"; } enum "long-wait" { description "LONG_WAIT state"; } } config false; description - "Current SPF backoff algorithm state."; + "Current SPF back-off algorithm state."; } leaf remaining-time-to-learn { type rt-types:timer-value-seconds16; config false; description "Remaining time until time-to-learn timer fires."; } leaf remaining-hold-down { type rt-types:timer-value-seconds16; config false; @@ -4790,21 +4804,21 @@ description "This container lists the SPF log."; list event { key id; description "List of SPF log entries represented as a wrapping buffer."; leaf id { type uint32; description - "Event identifier - Ppurely internal value."; + "Event identifier - Purely internal value."; } leaf spf-type { type enumeration { enum full { description "SPF computation was a Full SPF."; } enum intra { description "SPF computation was only for intra-area routes."; @@ -4949,25 +4962,25 @@ path "../../../../area/area-id"; } must "derived-from-or-self(" + "../../../../area[area-id=current()]/area-type, " + "'normal-area') and " + "../../../../area[area-id=current()]/area-id != " + "'0.0.0.0'" { error-message "Virtual link transit area must " + "be non-zero."; description - "Virtual-link trasit area must be + "Virtual-link transit area must be non-zero area."; } description - "Virtual link tranist area ID."; + "Virtual link transit area ID."; } leaf router-id { type rt-types:router-id; description "Virtual Link remote endpoint Router ID."; } uses virtual-link-config; uses virtual-link-state; } @@ -5121,21 +5137,21 @@ } leaf route-type { type route-type; description "OSPF route type"; } } augment "/rt:routing/rt:ribs/rt:rib/rt:routes/rt:route" { when "derived-from(rt:source-protocol, 'ospf:ospf-protocol')" { description - "This augmentation is only valid for a routes whose + "This augmentation is only valid for routes whose source protocol is OSPF."; } description "OSPF-specific route attributes."; uses route-content; } /* * RPCs */ @@ -5322,24 +5338,25 @@ type packet-type; description "OSPF packet type."; } leaf error { type enumeration { enum "bad-version" { description "Bad version."; } enum "area-mismatch" { - description "Area mistmatch."; + description "Area mismatch."; } enum "unknown-nbma-nbr" { description "Unknown NBMA neighbor."; + } enum "unknown-virtual-nbr" { description "Unknown virtual link neighbor."; } enum "auth-type-mismatch" { description "Auth type mismatch."; } enum "auth-failure" { description "Auth failure."; } @@ -5551,31 +5565,31 @@ 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, authentification + 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. 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 too either of these is compromised, they can result in + 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]. Following the format in [RFC3688], the following registration is requested to be made: URI: urn:ietf:params:xml:ns:yang:ietf-ospf Registrant Contact: The IESG. @@ -5688,25 +5702,20 @@ [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, . - [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. @@ -5876,34 +5885,39 @@ [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, . + [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, . [RFC6987] Retana, A., Nguyen, L., Zinin, A., White, R., and D. McPherson, "OSPF Stub Router Advertisement", RFC 6987, DOI 10.17487/RFC6987, September 2013, . -Appendix A. Contributors' Addreses +Appendix A. Contributors' Addresses Dean Bogdanovic Volta Networks, Inc. EMail: dean@voltanet.io Kiran Koushik Agrahara Sreenivasa Verizon 500 W Dove Rd Southlake, TX 76092