Network Working Group E. Wu Internet-Draft L. Wang Intended status: Standards Track S. Hares Expires: March 30, 2015 Huawei September 26, 2014 I2RS Information Model for OSPF protocol draft-wang-i2rs-ospf-info-model-00 Abstract As one of well-known link-state protocols, OSPF has been widely used in the routing of intra domain networks. During the past decades, it has been deployed with the help of typical interfaces such as CLI, SNMP and NETCONF. As modern networks grow in scale and complexity, the necessity for rapid and dynamic control has been increased. The I2RS is a standard-based interface which provides a programmatic way to achieve this goal. This document specifies an information model for the OSPF protocol to facilitate the definition of a standardized data model, which can be used to define interfaces to the OSPF from an entity that may even be external to the routing system. Based on standardized data model and interfaces, use cases of IGP protocols defined by I2RS-WG can be supported. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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/. 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." Wu, et al. Expires March 30, 2015 [Page 1] Internet-Draft OSPF information model September 2014 This Internet-Draft will expire on March 30, 2015. Copyright Notice Copyright (c) 2014 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. OSPF data . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. OSPF instance . . . . . . . . . . . . . . . . . . . . . . 4 2.1.1. Instance parameters . . . . . . . . . . . . . . . . . 5 2.1.2. Multi-topology-list . . . . . . . . . . . . . . . . . 5 2.2. OSPF multi-topology . . . . . . . . . . . . . . . . . . . 6 2.2.1. OSPF MT route . . . . . . . . . . . . . . . . . . . . 6 2.3. OSPF area . . . . . . . . . . . . . . . . . . . . . . . . 7 2.3.1. Area parameters . . . . . . . . . . . . . . . . . . . 8 2.3.2. Link state database . . . . . . . . . . . . . . . . . 9 2.3.3. OSPFv2 Link State Advertisement . . . . . . . . . . . 9 2.3.4. OSPFv3 Link State Advertisement . . . . . . . . . . . 12 2.3.5. Interface-list . . . . . . . . . . . . . . . . . . . 14 2.3.6. Network-list . . . . . . . . . . . . . . . . . . . . 14 2.3.7. Router-info database . . . . . . . . . . . . . . . . 14 2.4. OSPF interface . . . . . . . . . . . . . . . . . . . . . 14 2.4.1. Interface parameters . . . . . . . . . . . . . . . . 14 2.4.2. Interface neighbor . . . . . . . . . . . . . . . . . 16 2.4.3. Interface traffic engineering . . . . . . . . . . . . 17 3. OSPF notification . . . . . . . . . . . . . . . . . . . . . . 18 3.1. Adjacency . . . . . . . . . . . . . . . . . . . . . . . . 18 3.2. LSDB . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Route . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.4. TE . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.5. Protocol statistics . . . . . . . . . . . . . . . . . . . 18 4. OSPF operation . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Router number monitoring . . . . . . . . . . . . . . . . 19 4.2. Router-ID conflict recovery . . . . . . . . . . . . . . . 19 5. OSPF grammar . . . . . . . . . . . . . . . . . . . . . . . . 20 Wu, et al. Expires March 30, 2015 [Page 2] Internet-Draft OSPF information model September 2014 5.1. Instance . . . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Multi-topology . . . . . . . . . . . . . . . . . . . . . 20 5.3. Area . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.4. Interface . . . . . . . . . . . . . . . . . . . . . . . . 23 6. I2RS YANG model of OSPF . . . . . . . . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35 1. Introduction As one of well-known link-state protocols, OSPF[RFC2328] has been widely used in the routing of intra domain networks. During the past decades, it has been deployed with the help of typical interfaces such as CLI, SNMP and NETCONF. As modern networks grow in scale and complexity, the necessity for rapid and dynamic control has been increased. The I2RS[I-D.ietf-i2rs-architecture] is a standard-based interface which provides a programmatic way to achieve this goal. This document specifies an information model for the OSPF protocol to facilitate the definition of a standardized data model, which can be used to define interfaces to the OSPF from an entity that may even be external to the routing system. Based on standardized data model and interfaces, use cases of IGP protocols defined by [I-D.wu-i2rs-igp-usecases] can be supported. In order to support large intra-domain, OSPF has been organized hierarchically into areas. The topology of one area is hidden from the rest of networks, which is beneficial from the reduction of routing traffic. Based on flooding mechanism, each routing-system in one OSPF area will maintain the identical database from which a pair- wise shortest tree is calculated in the distributed manner. As one client of RIB, OSPF SHOULD populate its routing information into RIB as stated in [I-D.ietf-i2rs-rib-info-model]. 2. OSPF data This section describes the data involved in the OSPF information model in detail. Please note OSPF in this document means both OSPFv2 and OSPFv3[RFC5340] protocol unless specified. OSPF data includes information related to OSPF instance, OSPF area, OSPF multi-topology, OSPF interfaces, OSPF adjacencies and OSPF routes. A high-level architecture of the OSPF contents is shown as below. Wu, et al. Expires March 30, 2015 [Page 3] Internet-Draft OSPF information model September 2014 OSPF routing-protocol |0..N | OSPF instance |1..N | Multi-topology | | +----------------------------------------+---------------+ |0..N | |0..N | | | Area MT-RIB Policy | |0..N | | +-------+---------------+ Route | |1..1 |0..N | | | | | TE LSDB Interface +-------+------+ |0..N | | |1..N |0..N | | | | | LSA +---+--------+ Prefix Nexthop Backup | | | |0..N nexthop | | | | | TE Link-LSA NBR-list | +-------+-------+-------+------+-----------+-----------+ |0..N |0..N |0..N |0..N |0..N |0..N |0..1 | | | | | | | ADJ-list Intra- Inter- ASBR ASE-prefix NSSA-prefix TE-router-ID area area prefix prefix list Figure 1: Architecture of OSPF information model 2.1. OSPF instance In the context of OSPF information model, instance behaves like an independent virtual OSPF routing system which contains the instance parameters and the multi-topology list. Multiple instances MAY be supported on one network device. Wu, et al. Expires March 30, 2015 [Page 4] Internet-Draft OSPF information model September 2014 module: ospf-protocol +--rw ospf-instance | +--rw ospf-instance-name string | +--rw ospf-vpn-name? string | +--rw router-id inet:ip-address | +--ro protocol-status enumeration | +--ro ospf-type enumeration | +--rw version enumeration | +--ro ospf-process-create-mode enumeration | +--rw preference uint32 | +--rw hostname? string | +--rw mt-list Figure 2 YANG model of OSPF instance 2.1.1. Instance parameters o ospf-instance-name: A name uniquely identifying OSPF instance across all of those supported on one network device. o ospf-vpn-name: The name of the VPN instance which this instance is binded to. o router-id: The identification of this process. Every router-id MUST be unique among the OSPF network. o protocol-status: The status of current process. Valid status could include Active, Suppressed, Shutdown, Stub, Reset or etc. o ospf-type: This indicates whether this OSPF routing system is acting as an ABR or ASBR in this instance. o version: The version number of OSPF protocol. Valid input SHOULD be V2 or V3. o ospf-instance-create-mode: The mode used to create OSPF instance through I2RS Agent. o preference: The OSPF route preference for current process. o hostname: The symbolic name used to represent current process, which would be more preferable for human eyes. 2.1.2. Multi-topology-list This represents the list of topologies associated with this OSPF instance. Each OSPF instance MAY support multiple topologies to represent different involvement within those topologies. The list is Wu, et al. Expires March 30, 2015 [Page 5] Internet-Draft OSPF information model September 2014 mandatory for OSPF instance and MUST support one topology at least. More discussion for this list is in below section. 2.2. OSPF multi-topology A set of independent Multi-Topologies (MTs) can be supported on the same OSPF routing domain. This section describes the information model related to MT. o mt-id: The identifier of this MT. This ID is globally unique across the routing domain. o address-family: The address family supported on this MT. o mt-status: The status of this MT. Valid input MAY be Active or Inactive. o policy-list: This list contains those policies referenced within this OSPF MT. It is optional for the MT to reference policy or not. o mt-rib: The routing information base for this MT. o area-list: This is the list of area involved in this OSPF MT. The information model of area-list will be elaborated in the section below. module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] | +--rw mt-id uint16 | +--rw address-family address-family-def | +--rw mt-status? enumeration | +--rw policy-list* [policy-id] | | +--rw policy-id string | +--rw mt-rib ... | +--rw area-list Figure 3 YANG model of OSPF MT 2.2.1. OSPF MT route o prefix: The destination address of this route. o nexthop-list: The nexthops of this route. Wu, et al. Expires March 30, 2015 [Page 6] Internet-Draft OSPF information model September 2014 o backup nexthop: The backup nexthop for this route. o metric: The metric for this routes. o type: The type for this route. Valid input MAY be OSPF or OSPF_ASE. o route-state-info: The current and previous state of this route, the reason for this change and the related LSA invovled for this route. module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] ... | +--rw mt-rib | | +--rw route* [prefix] | | +--rw prefix inet:ipv4-prefix | | +--rw nexthop-list | | | +--rw nexthop* [ospf-nexthop] | | | +--rw ospf-nexthop inet:ipv4-prefix | | +--rw back-nexthop? inet:ipv4-prefix | | +--rw metric? uint32 | | +--rw type? ospf-route-type-def | | +--rw route-state-info | | +--rw metric? uint32 | | +--rw route-current-state? ospf-route-state-def | | +--rw route-previous-state? ospf-route-state-def | | +--rw route-chg-reason? route-chg-reason-def | | +--rw lsid? inet:ip-address | | +--rw lsa-type? lsa-type-def | | +--rw advertiser? inet:ip-address Figure 4 YANG model of OSPF RIB and route 2.3. OSPF area OSPF area is used to organize routing network in a hierarchical manner. OSPF process has to contain one area at least to work properly. The maximum number of area supported in one OSPF process is implementation dependent. Each area SHOULD contain information related to area parameters, link-state database and so on. Wu, et al. Expires March 30, 2015 [Page 7] Internet-Draft OSPF information model September 2014 module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list | +--rw area* [area-id] | +--rw area-id uint16 | +--rw area-type? area-type-def | +--rw area-status? area-status-def | +--rw lsa-arrival-int? uint32 | +--rw lsa-orig-int? uint32 | +--rw router-number? uint32 | +--rw area-auth ... | +--rw lsdb ... | +--rw interface-list ... | +--rw network-list* [network-prefix mask] ... | +--rw route-info-list* [route-info-index] ... Figure 5 YANG model of OSPF area 2.3.1. Area parameters This section demonstrates those parameters in area scope. o area-id: The identification of this level which SHOULD be level-1 or level-2. o area-type: The type of current area. Valid choice SHOULD be Normal, STUB or NSSA. o area-status: The status of current area. Valid input SHOULD be Active, Shutdown or Reset. o lsa-arrival-int: The interval of arrival between two consecutive LSA. o lsa-orig-int: The interval of origination between two consecutive LSA. o router-number: The total number of routers working in current area. Wu, et al. Expires March 30, 2015 [Page 8] Internet-Draft OSPF information model September 2014 o area-auth: The information related to area authentication, including authentication mode, password and other attributes. 2.3.2. Link state database Link State Database (LSDB) is composed of all link-state information advertised in the corresponding area. These pieces of link-state information are organized in the form of Link State Advertisement (LSA) which can be divided into two groups: self-originated LSA and remote-generated LSA. Some attributes of database can also be included in the information model. o lsdb-status: This represents the current status for database. It MAY be Normal or Overflow or something else. o lsdb-overflow-limit: The limit for overflow threshold of corresponding LSDB. When reaching or recovering from this threshold, one notification SHOULD be sent to I2RS Client. o lsdb-size: The size of database in the form of LSP number or bytes or percentage. o lsa-list: This list indicates those LSAs which are advertised in current area by either remote router or self-origination. module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list ... | +--rw lsdb | | +--rw lsdb-status? enumeration | | +--rw lsdb-overflow-limit? uint32 | | +--rw lsdb-size? uint32 | | +--rw lsa* [lsa-v2-type link-state-id advertiser-id] ... Figure 5 YANG model of OSPF LSDB 2.3.3. OSPFv2 Link State Advertisement Link State Advertisement (LSA) is a data unit used to hold and organize link-state information in the area scope. OSPF routers in the same area depend on the exchange of LSAes to synchronize their database which is the basis for per-hop forwarding paradigm. This section demonstrates some important components of LSA for OSPFv2 protocol. Wu, et al. Expires March 30, 2015 [Page 9] Internet-Draft OSPF information model September 2014 o lsa-age: The time in seconds since the LSA was originated. o lsa-options: The optional capabilities supported by the described portion of the routing domain. o lsa-v2-type: The type of LSA. There are 6 types of LSA for OSPFv2 in total. o link-state-id: The identifier for this LSA which is decided by originating router. o advertiser-id: The Router ID of the router that originated the LSA. o seq-no: The sequence number of a LSA. It is used to differentiate between the old instance and the new one for the LSA from the same place. o chksum: The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the lsa-age field. o lsa-length: The length in bytes of the LSA. o router-lsa: Router-LSAs are the Type 1 LSAs. Each router in an area originates a router-LSA. The LSA describes the state and cost of the router's links to the area. o network-lsa: Network-LSAs are the Type 2 LSAs. A network-LSA is originated for each broadcast and NBMA network in the area which supports two or more routers. The network-LSA is originated by the network's Designated Router. o summary-lsa: Summary-LSAs are the Type 3 and 4 LSAs. These LSAs are originated by area border routers. Summary-LSAs describe inter-area destinations. o as-external-lsa: AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by AS boundary routers, and describe destinations external to the AS. o nssa-lsa: NSSA-LSAs are the Type 7 LSAs. There LSAs are originated by NSSA AS boundary routers for imported external routes. o te-router-lsa: This LSA is used to carry the Router Address TLV, which specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. Wu, et al. Expires March 30, 2015 [Page 10] Internet-Draft OSPF information model September 2014 o te-link-lsa: This LSA is used to carry the Link TLV which describes traffic engineering information related to a single link. module: ospf-protocol +--rw ospf-v4ur-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list ... | +--rw lsdb | | +--rw lsa* [lsa-v2-type link-state-id advertiser-id] | | +--rw lsa-age? uint32 | | +--rw lsa-options? uint8 | | +--rw lsa-v2-type enumeration | | +--rw link-state-id inet:ipv4-address | | +--rw advertiser-id inet:ip-prefix | | +--rw seq-no? uint32 | | +--rw chksum? uint32 | | +--rw lsa-length? uint32 | | +--rw (ls-type)? | | +--:(router-lsa) | | | +--rw ospf-v2-router-lsa ... | | +--:(network-lsa) | | | +--rw ospf-v2-network-lsa ... | | +--:(summary-lsa) | | | +--rw ospf-v2-summary-lsa ... | | +--:(as-external-lsa) | | | +--rw ospf-v2-as-external-lsa ... | | +--:(nssa-external-lsa) | | | +--rw ospf-v2-nssa-external-lsa ... | | +--:(te-router-lsa) | | | +--rw ospf-v2-te-router-lsa ... | | +--:(te-link-lsa) | | +--rw ospf-v2-te-link-lsa ... Figure 6 YANG model of OSPFv2 LSA Wu, et al. Expires March 30, 2015 [Page 11] Internet-Draft OSPF information model September 2014 2.3.4. OSPFv3 Link State Advertisement This section demonstrates some important components of LSA for OSPFv3 protocol. o lsa-age: The time in seconds since the LSA was originated. o lsa-v3-type: The type of LSA. There are 8 types of LSA for OSPFv3 in total. o lsa-state-id: The identifier for this LSA which is decided by originating router. o advertiser-id: The Router ID of the router that originated the LSA. o seq-no: The sequence number of a LSA. It is used to differentiate between the old instance and the new one for the LSA from the same place. o chksum: The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the lsa-age field. o lsa-length: The length in bytes of the LSA. o router-lsa: Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. o network-lsa: Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area that includes two or more adjacent routers. The network-LSA is originated by the link's Designated Router. o inter-area-prefix-lsa: Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs. o inter-area-router-lsa: Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs. o as-external-lsa: AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers and describe destinations external to the AS. o nssa-lsa: NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe Wu, et al. Expires March 30, 2015 [Page 12] Internet-Draft OSPF information model September 2014 destinations external to the AS that may or may not be propagated outside the NSSA. o link-lsa: Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. o intra-area-prefix-lsa: Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes that are associated with a local router address, an attached stub network segment, or an attached transit network segment. o te-link-lsa: This LSA is used to carry the Link TLV which describes traffic engineering information related to a single link. module: ospf-protocol +--rw ospf-v6ur-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list ... +--rw lsdb | +--rw lsa* | [lsa-v3-type link-state-id advertiser-id] | +--rw lsa-age? uint32 | +--rw lsa-v3-type enumeration | +--rw link-state-id uint32 | +--rw advertiser-id inet:ip-prefix | +--rw seq-no? uint32 | +--rw chksum? uint32 | +--rw lsa-length? uint32 | +--rw (ls-type)? | +--:(router-lsa) | | +--rw ospf-v3-router-lsa ... | +--:(network-lsa) | | +--rw ospf-v3-network-lsa ... | +--:(inter-area-prefix-lsa) | | +--rw ospf-v3-inter-area-prefix-lsa ... | +--:(inter-area-router-lsa) | | +--rw ospf-v3-inter-area-router-lsa ... | +--:(as-external-lsa) | | +--rw ospf-v3-as-external-lsa Wu, et al. Expires March 30, 2015 [Page 13] Internet-Draft OSPF information model September 2014 ... | +--:(nssa-lsa) | | +--rw ospf-v3-nssa-lsa ... | +--:(link-lsa) | | +--rw ospf-v3-link-lsa ... | +--:(intra-area-prefix-lsa) | | +--rw ospf-v3-intra-area-prefix-lsa ... | +--:(te-router-ipv6-address-lsa) | | +--rw ospf-v2-te-router-ipv6-address ... | +--:(te-link-lsa) | +--rw ospf-v3-te-link-lsa ... Figure 7 YANG model of OSPFv3 LSA 2.3.5. Interface-list This list contains interfaces enabled in this area. The information model of interface-list will be elaborated in the section below. 2.3.6. Network-list This list contains different pairs of IP address and mask which are used to enable interfaces into this area. The enabled interfaces' IP address are covered by the scope define by address & mask pair. The most exact pair is used when different pairs overlay on their scopes. 2.3.7. Router-info database This list contains the router information of every routers from this area. Router information includes the identification of the router, the Area-ID, the hostname if possible and some attributes such as ID of neighbors. Such a population database MAY be useful for future scenarioes. 2.4. OSPF interface This section demonstrates the information model of OSPF interfaces. 2.4.1. Interface parameters o interface-index: The index for this interface. It MUST be unique globally in the same routing system. Wu, et al. Expires March 30, 2015 [Page 14] Internet-Draft OSPF information model September 2014 o interface-name: The name used to refer to this interface. o interface-status: The state of this interface in current area. Valid state SHOULD be DOWN, P2P, WAITING, DR, BDR or DROther. o interface-down-reason: The reason the state of this interface changed to down. Valid reason SHOULD be Physical-down, Admin- shutdown or IP-down. o interface-net-type: The network type simulated on this interface. Valid choice SHOULD be P2P, Broadcast, NBMA, P2MP or even virtual- link. o interface-role: The identification of DR, BDR or DROther role for this interface. o interface-te-info: The traffic-engineer information related to this interface. o interface-auth: The information related to interface authentication, including authentication mode, password and other attributes. o ip-address: The IPv4 or IPv6 address of this interface. o nbr-list: The neighbor list on this interface. Wu, et al. Expires March 30, 2015 [Page 15] Internet-Draft OSPF information model September 2014 module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list ... | +--rw interface-list | | +--rw interface* [interface-index] | | +--rw interface-index uint64 | | +--rw interface-name? string | | +--rw interface-status? interface-status-def | | +--rw interface-down-reason? interface-down-reason-def | | +--rw interface-net-type? interface-net-type-def | | +--rw interface-role? interface-role-def | | +--rw interface-te-info ... | | +--rw interface-auth ... | | +--rw ip-address? inet:ipv4-address | | +--rw nbr-list ... Figure 7 YANG model of OSPF interface 2.4.2. Interface neighbor This section describes the neighbor information related to one interface. o router-id: The Router-ID of one neighbor supported on this interface. o interface-index: The index for the interface which this neighbor belongs to. o interface-name: The name used to refer to this interface. o nbr-status: The status for the adjacency with this neighbor. Valid input SHOULD be Down, Attempt, 2-way, ExStart, Exchange, Loading and Full. o nbr-previous-status: The status for the adjacency with this neighbor before the latest change. o nbr-down-reason: The reason this adjacency was brought. Valid choice SHOULD be Interface-down, BFD-down, Expired and CFG-change. Wu, et al. Expires March 30, 2015 [Page 16] Internet-Draft OSPF information model September 2014 o nbr-address: The IPv4 or IPv6 address for this neighbor. module: ospf-protocol +--rw ospf-instance ... | +--rw multi-topo* [mt-id] ... | +--rw area-list ... | +--rw interface-list ... | | +--rw nbr-list | | +--rw nbr* [router-id] | | +--rw router-id inet:ip-address | | +--rw interface-index? uint64 | | +--rw interface-name? string | | +--rw nbr-status? nbr-status-def | | +--rw nbr-previous-status? nbr-status-def | | +--rw nbr-down-reason? nbr-down-reason-def | | +--rw nbr-address? inet:ipv4-address ... Figure 8 YANG model of OSPF neighbor 2.4.3. Interface traffic engineering This section describes the TE related data on this interface. o interface-index: The index for this interface. It MUST be unique globally in the same routing system. o admin-Group: The bit mask assigned by operators used for identifying administrative group. o ipv4-address: A 4-octet IPv4 address for the interface described by interface-index. o nbr-ipv4-address: A single IPv4 address for a neighboring router on this link. o max-link-bandwidth: The maximum bandwidth that can be used on this link in this direction. o max-rsv-bandwidth: The maximum amount of bandwidth that can be reserved in this direction on this link. o unrsv-bandwidth: The amount of bandwidth reservable in this direction on this link. Wu, et al. Expires March 30, 2015 [Page 17] Internet-Draft OSPF information model September 2014 3. OSPF notification With the help of OSPF information model, the I2RS Client can collect OSPF state data through publish/subscription mechanism. This section describes several data which is important for operating and maintaining of OSPF routing-protocol. 3.1. Adjacency Information related to adjacencies SHOULD be readable through I2RS Agent. This includes total number of adjacencies in the network and their current status and even their history of transition. For certain specific adjacencies, the I2RS Client MAY subscribe for their data when events happened. 3.2. LSDB Link state database is the most important part in OSPF information model. It contains the whole topology information from the network. The I2RS Agent SHOULD support reading LSDB information related to size, status and contents. It MAY be useful to subscribe some critical reachability information from LSA when specific events happened. 3.3. Route Since the OSPF routing-table is one client for the RIB, it MAY be beneficial to read data from OSPF routes. This data may contain the size and status of the routing-table and even the detailed contents of routes. It MAY be necessary to subscribe the data and status of certain specific routes especially when the reachability was lost. Through the OSPF information model, it will be more convenient for operators to get corresponding LSA and even the adjacency when one route disappeared. 3.4. TE It MAY be helpful to read the traffic engineering information for one area or for one specific interface. This can help to find out mistakes or data loss during the procedure of advertising and flooding. 3.5. Protocol statistics It SHOULD be necessary to subscribe protocol statistics for health diagnostics. This statistics may contain packet discard for different reasons, adjacency transition frequency, the size of LSDB and routing-table, SPF-trigger frequency and etc. Wu, et al. Expires March 30, 2015 [Page 18] Internet-Draft OSPF information model September 2014 4. OSPF operation Based on the standardized information model of OSPF protocol as described above, use cases defined in [I-D.wu-i2rs-igp-usecases] can be supported. This section demonstrates several specific examples of these use cases. 4.1. Router number monitoring Complaint can be heard frequently from clients about how many routers should be deployed in one area. The answer for this question is not very clear in vendor's guide since the product specification is only for reference and what's worse, those words like "usually", "roughly" or "most of the time" are often used from field engineers. As the consequence, it is always convenient for clients to deploy all the routers in one area, which may introduce scaling issue in future. With the help of OSPF information model and I2RS interfaces, it is possible to give out deployment suggestion or warning dynamically in the real-time manner. Based on the statistics of router number and system resource consuming, plus the ratio relationship between them, one notification or warning can be sent to I2RS Client. From there decision can be made to expand safely or have to shrink for precaution. 4.2. Router-ID conflict recovery It is not rare to observe router-ID conflict in networks both intra and inter area, especially when different area merged. It is time- consuming and troublesome to detect and locate the place where this trouble happened. The frequently used solution is to rename one of the conflicted router-ID to a new one then reboot the involved OSPF instance to force all adjacencies to rebuild and re-synchronize the LSDB. It MAY be possible to alleviate this issue with the help of OSPF information model and programmatic I2RS interfaces. With the help of router-info-list, this conflict can be detected automatically. When one substantial conflict is on the horizon, no need to wait for mutual re-origination happened, ID conflict can be found in router- info-list with help of their coordinate information, no matter the conflict routers come from the same area or not. What is more, through I2RS interfaces and Agent, it is possible to rewrite one of the conflicted router-ID into a new one then reboot the routing- protocol. Wu, et al. Expires March 30, 2015 [Page 19] Internet-Draft OSPF information model September 2014 5. OSPF grammar This section demonstrates the information model of OSPF routing- protocol using the syntax stated in [RFC5511] 5.1. Instance ::= [ ... ] ::= ::= [ ] [ ] [ ] ::= | | ::= | | | ::= | 5.2. Multi-topology ::= [ ... ] ::= [ ] ::= | | | ::= | ::= ::= [ ... ] ::= [ ... ] SHOULD follow the definition in the information model for policy as stated in [I-D.hares-i2rs-info-model-policy]. ::= [ ... ] ::= [ ] ::= Wu, et al. Expires March 30, 2015 [Page 20] Internet-Draft OSPF information model September 2014 and SHOULD follow the definition in the RIB iformation model as stated in [I-D.ietf-i2rs-rib-info-model]. ::= [ ] [ ] [ ] ::= ( | ) ( | ) ::= ( | ) ( | ) ::= | | | 5.3. Area ::= [ ... ] ::= [ ] [ ] ::= [ ] [ ] [ ] [ ] ::= | | ::= | | ::= ::= | | | ::= ::= ::= ::= [ ] [ ] ::= | ::= | | | Wu, et al. Expires March 30, 2015 [Page 21] Internet-Draft OSPF information model September 2014 ::= [ ] ::= | ::= [ ... ] ::= [ ( ) ... ] ::= [ ... ] ::= [ ...] ::= | ::= [ ... ] ::= ::= ::= | | | | ::= ::= | | | | | | ::= [ ... ] ::= ::= ::= ::= | | ::= | | | | ::= | | | | | | | Wu, et al. Expires March 30, 2015 [Page 22] Internet-Draft OSPF information model September 2014 | | 5.4. Interface ::= [ ... ] ::= [ ] [ ] [ ] [ ] [ ] [ ] ::= | | | ::= | ::= | | ::= | | ::= ::= ::= [ ... ] ::= [ ] [ ] ::= | | <2-WAY> | | | | ::= | | <2-WAY> | | | | ::= | | | | ::= 6. I2RS YANG model of OSPF Wu, et al. Expires March 30, 2015 [Page 23] Internet-Draft OSPF information model September 2014 module: ospf-protocol +--rw ospf-v4ur-instance | +--rw ospf-instance-name string | +--rw ospf-vpn-name? string | +--rw router-id inet:ip-address | +--ro protocol-status protocol-status-def | +--ro ospf-type ospf-type-def | +--ro version ospf-version-def | +--ro ospf-process-create-mode ospf-process-create-mode-def | +--rw preference uint32 | +--rw hostname? string | +--rw mt-list | +--rw multi-topo* [mt-id] | +--rw mt-id uint16 | +--rw address-family address-family-def | +--rw mt-status? enumeration | +--rw policy-list* [policy-id] | | +--rw policy-id string | +--rw mt-rib | | +--rw route* [prefix] | | +--rw prefix inet:ipv4-prefix | | +--rw nexthop-list | | | +--rw nexthop* [ospf-nexthop] | | | +--rw ospf-nexthop inet:ipv4-prefix | | +--rw back-nexthop? inet:ipv4-prefix | | +--rw metric? uint32 | | +--rw type? ospf-route-type-def | | +--rw route-state-info | | +--rw metric? uint32 | | +--rw route-current-state? ospf-route-state-def | | +--rw route-previous-state? ospf-route-state-def | | +--rw route-chg-reason? route-chg-reason-def | | +--rw lsid? inet:ip-address | | +--rw lsa-type? lsa-type-def | | +--rw advertiser? inet:ip-address Wu, et al. Expires March 30, 2015 [Page 24] Internet-Draft OSPF information model September 2014 | +--rw area-list | +--rw area-id uint16 | +--rw area-type? area-type-def | +--rw area-status? area-status-def | +--rw lsa-arrival-int? uint32 | +--rw lsa-orig-int? uint32 | +--rw router-number? uint32 | +--rw area-auth | | +--rw (auth-mode-type)? | | +--:(mode-simple) | | | +--rw simple-password? string | | +--:(mode-md5) | | | +--rw md5-password? string | | +--:(mode-hmac-sha256) | | | +--rw hmac-key-id? uint32 | | | +--rw hmac-password? string | | +--:(mode-keychain) | | +--rw keychain-key-id? uint32 | | +--rw keychain-password? string | | +--rw keychain-mode? enumeration | | +--rw keychain-periodic? enumeration | | +--rw send_time? uint32 | | +--rw receive_tim? uint32 Wu, et al. Expires March 30, 2015 [Page 25] Internet-Draft OSPF information model September 2014 | +--rw lsdb | | +--rw lsa*[lsa-v2-type link-state-id advertiser-id] | | +--rw lsa-age? uint32 | | +--rw lsa-options? uint8 | | +--rw lsa-v2-type enumeration | | +--rw link-state-id inet:ipv4-address | | +--rw advertiser-id inet:ip-prefix | | +--rw seq-no? uint32 | | +--rw chksum? uint32 | | +--rw lsa-length? uint32 | | +--rw (ls-type)? | | +--:(ospf-v2-router-lsa) | | | +--rw ospf-v2-router-lsa | | | +--rw bit-flag uint16 | | | +--rw link-num uint16 | | | +--rw link-list* [link-id link-data] | | | +--rw link-id inet:ipv4-address | | | +--rw link-data inet:ipv4-address | | | +--rw link-type enumeration | | | +--rw mt-num uint16 | | | +--rw metric uint16 | | | +--rw mt-metric* [mt-id] | | | +--rw mt-id uint16 | | | +--rw metric? uint16 | | +--:(ospf-v2-network-lsa) | | | +--rw ospf-v2-network-lsa | | | +--rw network-mask inet:ipv4-prefix | | | +--rw attached-router* [router-id] | | | +--rw router-id inet:ipv4-address | | +--:(ospf-v2-summary-lsa) | | | +--rw ospf-v2-summary-lsa | | | +--rw network-mask inet:ipv4-prefix | | | +--rw mt-metric* [mt-id] | | | +--rw mt-id uint16 | | | +--rw metric? uint16 | | +--:(ospf-v2-as-external-lsa) | | | +--rw ospf-v2-as-external-lsa | | | +--rw network-mask inet:ipv4-prefix | | | +--rw mt-metric* [mt-id] | | | +--rw e-bit? uint8 | | | +--rw mt-id uint8 | | | +--rw metric? uint16 | | | +--rw forwarding-address? | | | inet:ipv4-address | | | +--rw external-route-tag? uint32 | | +--:(ospf-v2-nssa-external-lsa) | | | +--rw ospf-v2-nssa-external-lsa Wu, et al. Expires March 30, 2015 [Page 26] Internet-Draft OSPF information model September 2014 | | | +--rw network-mask inet:ipv4-prefix | | | +--rw mt-metric* [mt-id] | | | +--rw e-bit? uint8 | | | +--rw mt-id uint8 | | | +--rw metric? uint32 | | | +--rw forwarding-address? | | | inet:ipv4-address | | | +--rw external-route-tag? uint32 | | +--:(ospf-v2-te-router-lsa) | | | +--rw ospf-v2-te-router-lsa | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw router-id? inet:ipv4-address | | +--:(ospf-te-link-lsa) | | +--rw ospf-te-link-lsa | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw link-type-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw link-type? enumeration | | +--rw link-id-tlv-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw link-id? inet:ipv4-address | | +--rw local-address-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw local-address-list* | | [remote-address] | | | +--rw remote-address | | inet:ipv4-address | | +--rw remote-address-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw remote-address-list* | | [remote-address] | | | +--rw remote-address | | inet:ipv4-address | | +--rw te-metric-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw value? uint32 | | +--rw maximum-bandwidth-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw value? uint32 | | +--rw maximum-reservable-bandwidth-stlv Wu, et al. Expires March 30, 2015 [Page 27] Internet-Draft OSPF information model September 2014 | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw value? uint32 | | +--rw unreserved-bandwidth-stlv | | | +--rw type? uint8 | | | +--rw length? uint32 | | | +--rw value? uint32 | | +--rw administrative-group-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw value? uint32 | +--rw interface-list | | +--rw interface* [interface-index] | | +--rw interface-index uint64 | | +--rw interface-name? string | | +--rw interface-status? interface-status-def | | +--rw interface-down-reason? | | interface-down-reason-def | | +--rw interface-net-type? interface-net-type-def | | +--rw interface-role? interface-role-def | | +--rw interface-te-info | | | +--rw admin_group? uint32 | | | +--rw max_bandwidth? uint32 | | | +--rw max_rsv_bandwidth? uint32 | | | +--rw unrsv_bandwidth? uint32 | | +--rw interface-auth | | | +--rw (auth-mode-type)? | | | +--:(mode-simple) | | | | +--rw simple-password? string | | | +--:(mode-md5) | | | | +--rw md5-password? string | | | +--:(mode-hmac-sha256) | | | | +--rw hmac-key-id? uint32 | | | | +--rw hmac-password? string | | | +--:(mode-keychain) | | | +--rw keychain-key-id? uint32 | | | +--rw keychain-password? string | | | +--rw keychain-mode? enumeration | | | +--rw keychain-periodic? enumeration | | | +--rw send_time? uint32 | | | +--rw receive_tim? uint32 | | +--rw ip-address? inet:ipv4-address | | +--rw nbr-list | | +--rw nbr* [router-id] | | +--rw router-id inet:ip-address | | +--rw interface-index? uint64 | | +--rw interface-name? string Wu, et al. Expires March 30, 2015 [Page 28] Internet-Draft OSPF information model September 2014 | | +--rw nbr-status? nbr-status-def | | +--rw nbr-previous-status? nbr-status-def | | +--rw nbr-down-reason? nbr-down-reason-def | | +--rw nbr-address? inet:ipv4-address | | +--rw ip-address? inet:ipv4-address | +--rw network-list* [network-prefix mask] | | +--rw network-prefix inet:ipv4-prefix | | +--rw mask inet:ipv4-prefix | +--rw route-info-list* [route-info-index] | +--rw route-info-index uint32 | +--rw router-id inet:ipv4-address | +--rw ip-address-list* [ip-address] | +--rw ip-address inet:ipv4-address +--rw ospf-v6ur-instance +--rw ospf-instance-name string +--rw ospf-vpn-name? string +--rw router-id inet:ip-address +--ro protocol-status protocol-status-def +--ro ospf-type ospf-type-def +--ro version ospf-version-def +--ro ospf-process-create-mode ospf-process-create-mode-def +--rw preference uint32 +--rw hostname? string +--rw mt-list +--rw multi-topo* [mt-id] +--rw mt-id uint16 +--rw address-family address-family-def +--rw mt-status? enumeration +--rw policy-list* [policy-id] | +--rw policy-id string +--rw mt-rib | +--rw route* [prefix] | +--rw prefix inet:ipv6-prefix | +--rw nexthop-list | | +--rw nexthop* [ospf-nexthop] | | +--rw ospf-nexthop inet:ipv6-prefix | +--rw back-nexthop? inet:ipv6-prefix | +--rw metric? uint32 | +--rw type? ospf-route-type-def | +--rw route-state-info | +--rw metric? uint32 | +--rw route-current-state? ospf-route-state-def | +--rw route-previous-state? ospf-route-state-def | +--rw route-chg-reason? route-chg-reason-def | +--rw lsid? inet:ip-address | +--rw lsa-type? lsa-type-def | +--rw advertiser? inet:ip-address Wu, et al. Expires March 30, 2015 [Page 29] Internet-Draft OSPF information model September 2014 +--rw area-list +--rw area* [area-id] +--rw area-id uint16 +--rw area-type? area-type-def +--rw area-status? area-status-def +--rw lsa-arrival-int? uint32 +--rw lsa-orig-int? uint32 +--rw router-number? uint32 +--rw area-auth | +--rw (auth-mode-type)? | +--:(mode-simple) | | +--rw simple-password? string | +--:(mode-md5) | | +--rw md5-password? string | +--:(mode-hmac-sha256) | | +--rw hmac-key-id? uint32 | | +--rw hmac-password? string | +--:(mode-keychain) | +--rw keychain-key-id? uint32 | +--rw keychain-password? string | +--rw keychain-mode? enumeration | +--rw keychain-periodic? enumeration | +--rw send_time? uint32 | +--rw receive_tim? uint32 +--rw lsdb | +--rw lsa* [lsa-v3-type link-state-id advertiser-id] | +--rw lsa-age? uint32 | +--rw lsa-v3-type enumeration | +--rw link-state-id uint32 | +--rw advertiser-id inet:ip-prefix | +--rw seq-no? uint32 | +--rw chksum? uint32 | +--rw lsa-length? uint32 | +--rw (ls-type)? | +--:(ospf-v3-router-lsa) | | +--rw ospf-v3-router-lsa | | +--rw option uint16 | | +--rw link-list* | | [link-type interface-id neighbor-interface-id] | | +--rw link-type enumeration | | +--rw metric? uint32 | | +--rw interface-id uint32 | | +--rw neighbor-interface-id uint32 | | +--rw neighbor-router-id? | | inet:ipv4-address | +--:(ospf-v3-network-lsa) | | +--rw ospf-v3-network-lsa | | +--rw option uint32 Wu, et al. Expires March 30, 2015 [Page 30] Internet-Draft OSPF information model September 2014 | | +--rw link-list* [attached-router-id] | | +--rw attached-router-id | | inet:ipv4-address | +--:(ospf-v3-inter-area-prefix-lsa) | | +--rw ospf-v3-inter-area-prefix-lsa | | +--rw metric? uint32 | | +--rw prefix-length uint8 | | +--rw prefix-options uint8 | | +--rw address-prefix-list* [address-prefix] | | +--rw address-prefix inet:ipv6-prefix | +--:(ospf-v3-inter-area-router-lsa) | | +--rw ospf-v3-inter-area-router-lsa | | +--rw options uint8 | | +--rw metric? uint32 | | +--rw destination-router-id? inet:ipv4-address | +--:(ospf-v3-as-external-lsa) | | +--rw ospf-v3-as-external-lsa | | +--rw options uint16 | | +--rw metric uint16 | | +--rw prefix-length uint8 | | +--rw prefix-options uint8 | | +--rw referenced-ls-type uint8 | | +--rw address-prefix-list* [address-prefix] | | | +--rw address-prefix inet:ipv6-prefix | | +--rw forwarding-address? inet:ipv6-prefix | | +--rw external-route-tag? uint32 | | +--rw referenced-link-state-id? uint32 | +--:(ospf-v3-nssa-lsa) | | +--rw ospf-v3-nssa-lsa | | +--rw options uint16 | | +--rw metric uint16 | | +--rw prefixlength uint8 | | +--rw prefixoptions uint8 | | +--rw referenced-ls-type uint8 | | +--rw address-prefix-list* [address-prefix] | | | +--rw address-prefix inet:ipv6-prefix | | +--rw forwarding-address? inet:ipv6-prefix | | +--rw external-route-tag? uint32 | | +--rw referenced-link-state-id? uint32 | +--:(ospf-v3-link-lsa) | | +--rw ospf-v3-link-lsa | | +--rw priority uint8 | | +--rw options uint32 | | +--rw link-local-interface-address? | | inet:ipv6-address | | +--rw prefixes uint32 | | +--rw address-prefix-list* | | [address-prefix-index] Wu, et al. Expires March 30, 2015 [Page 31] Internet-Draft OSPF information model September 2014 | | +--rw address-prefix-index uint32 | | +--rw prefix-length uint8 | | +--rw prefix-options? uint8 | | +--rw address-prefix* [address] | | +--rw address inet:ipv6-prefix | +--:(ospf-v3-intra-area-prefix-lsa) | | +--rw ospf-v3-intra-area-prefix-lsa | | +--rw prefixes uint32 | | +--rw referenced-ls-type uint16 | | +--rw referenced-link-state-id uint32 | | +--rw referenced-advertising-router | | inet:ipv4-address | | +--rw address-prefix-list* | | [address-prefix-index] | | +--rw address-prefix-index uint32 | | +--rw prefix-length uint8 | | +--rw prefix-options uint8 | | +--rw address-prefix* [address] | | +--rw address inet:ipv6-prefix | +--:(ospf-v3-te-router-ipv6-address-lsa) | | +--rw ospf-v3-te-router-ipv6-address | | +--rw type uint8 | | +--rw length uint16 | | +--rw router-id inet:ipv6-address | +--:(te-link-lsa) | +--rw ospf-te-link-lsa | +--rw type? uint8 | +--rw length? uint32 | +--rw link-type-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw link-type? enumeration | +--rw link-id-tlv-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw link-id? inet:ipv4-address | +--rw local-address-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw local-address-list* | | [remote-address] | | +--rw remote-address | | inet:ipv4-address | +--rw remote-address-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw remote-address-list* | | [remote-address] Wu, et al. Expires March 30, 2015 [Page 32] Internet-Draft OSPF information model September 2014 | | +--rw remote-address | | inet:ipv4-address | +--rw te-metric-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw value? uint32 | +--rw maximum-bandwidth-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw value? uint32 | +--rw maximum-reservable-bandwidth-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw value? uint32 | +--rw unreserved-bandwidth-stlv | | +--rw type? uint8 | | +--rw length? uint32 | | +--rw value? uint32 | +--rw administrative-group-stlv | +--rw type? uint8 | +--rw length? uint32 | +--rw value? uint32 +--rw interface-list | +--rw interface* [interface-index] | +--rw interface-index uint64 | +--rw interface-name? string | +--rw interface-status? interface-status-def | +--rw interface-down-reason? | interface-down-reason-def | +--rw interface-net-type? interface-net-type-def | +--rw interface-role? interface-role-def | +--rw interface-te-info | | +--rw admin_group? uint32 | | +--rw max_bandwidth? uint32 | | +--rw max_rsv_bandwidth? uint32 | | +--rw unrsv_bandwidth? uint32 | +--rw interface-auth | | +--rw (auth-mode-type)? | | +--:(mode-simple) | | | +--rw simple-password? string | | +--:(mode-md5) | | | +--rw md5-password? string | | +--:(mode-hmac-sha256) | | | +--rw hmac-key-id? uint32 | | | +--rw hmac-password? string | | +--:(mode-keychain) | | +--rw keychain-key-id? uint32 | | +--rw keychain-password? string Wu, et al. Expires March 30, 2015 [Page 33] Internet-Draft OSPF information model September 2014 | | +--rw keychain-mode? enumeration | | +--rw keychain-periodic? enumeration | | +--rw send_time? uint32 | | +--rw receive_tim? uint32 | +--rw ip-address inet:ipv6-address | +--rw nbr-list | +--rw nbr* [router-id] | +--rw router-id inet:ip-address | +--rw interface-index? uint64 | +--rw interface-name? string | +--rw nbr-status? nbr-status-def | +--rw nbr-previous-status? nbr-status-def | +--rw nbr-down-reason? nbr-down-reason-def | +--rw nbr-address? inet:ipv6-address | +--rw ip-address inet:ipv6-address +--rw network-list* [network-index] | +--rw network-index uint32 | +--rw network-prefix inet:ipv4-prefix | +--rw mask inet:ipv4-prefix +--rw route-info-list* [route-info-index] +--rw route-info-index uint32 +--rw router-id inet:ipv4-address +--rw ip-address-list* [ip-address] +--rw ip-address inet:ipv4-address Figure 1 The I2RS YANG model of OSPF 7. IANA Considerations This draft includes no request to IANA. 8. Security Considerations This document introduces no new security threat and SHOULD follow the security requirements as stated in [I-D.ietf-i2rs-architecture]. 9. Acknowledgements TBD 10. References 10.1. Normative References [I-D.hares-i2rs-info-model-policy] Hares, S. and W. Wu, "An Information Model for Basic Network Policy", draft-hares-i2rs-info-model-policy-03 (work in progress), July 2014. Wu, et al. Expires March 30, 2015 [Page 34] Internet-Draft OSPF information model September 2014 [I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. Nadeau, "An Architecture for the Interface to the Routing System", draft-ietf-i2rs-architecture-05 (work in progress), July 2014. [I-D.ietf-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing Information Base Info Model", draft-ietf-i2rs-rib-info- model-03 (work in progress), May 2014. [I-D.wu-i2rs-igp-usecases] Wu, N., Li, Z., and S. Hares, "Use Cases for an Interface to IGP Protocol", draft-wu-i2rs-igp-usecases-00 (work in progress), July 2014. 10.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008. [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax Used to Form Encoding Rules in Various Routing Protocol Specifications", RFC 5511, April 2009. Authors' Addresses Eric Wu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: eric.wu@huawei.com Lixing Wang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing 10095 China Email: wanglixing@huawei.com Wu, et al. Expires March 30, 2015 [Page 35] Internet-Draft OSPF information model September 2014 Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA Email: shares@ndzh.com Wu, et al. Expires March 30, 2015 [Page 36]