| 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
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.
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].
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."
This Internet-Draft will expire on March 30, 2015.
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.
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].
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.
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
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.
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
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 mandatory for OSPF instance and MUST support one topology at least. More discussion for this list is in below section.
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
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.
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
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.
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
This section demonstrates those parameters in area scope.
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
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.
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
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.
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
...
| +--:(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
This section demonstrates some important components of LSA for OSPFv3 protocol.
This list contains interfaces enabled in this area. The information model of interface-list will be elaborated in the section below.
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.
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.
This section demonstrates the information model of OSPF interfaces.
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
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
This section describes the neighbor information related to one interface.
This section describes the TE related data on this interface.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This section demonstrates the information model of OSPF routing-protocol using the syntax stated in [RFC5511]
<OSPF routing-protocol> ::= [ <OSPF instance> ... ]
<OSPF instance> ::= <instance-parameters> <multi-topo-list>
<instance-parameters> ::= <OSPF_INSTANCE_NAME> [ <OSPF_VPN_NAME> ] <ROUTER_ID> <protocol-status> <ospf-type> <version> <ospf-instance-create-mode> [ <PREFERENCE> ] [ <HOSTNAME> ]
<ospf-type> ::= <ABR> | <ASBR> | <NONE>
<protocol-status> ::= <ACTIVE> | <RESET> | <SHUTDOWN> | <OVERLOAD>
<version> ::= <V2> | <V3>
<multi-topo-list> ::= [ <mt> ... ]
<mt> ::= <MT_ID> <address-family> <mt-status> [ <policy-list> ] <mt-rib> <area-list>
<address-family> ::= <V4UR> | <V6UR> | <V4MR> | <V6MR>
<mt-status> ::= <ACTIVE> | <INACTIVE>
<mt-rib> ::= <route-list>
<area-list> ::= [ <area> ... ]
<policy-list> ::= [ <Policy-Rule> ... ]
<Policy-Rule> SHOULD follow the definition in the information model for policy as stated in [I-D.hares-i2rs-info-model-policy].
<route-list> ::= <route> [ <route> ... ]
<route> ::= <PREFIX> <nexthop-list> [ <back-nexthop> ] <METRIC> <TYPE> <route-state-info>
<backup-nexthop> ::= <nexthop>
<nexthop-list> and <nexthop> SHOULD follow the definition in the RIB iformation model as stated in [I-D.ietf-i2rs-rib-info-model].
<route-state-info> ::= <route-current-state> [ <route-previous-state> ] [ <route-chg-reason> ] [ <LSID> <lsa-type> <advertiser> ]
<route-current-state> ::= ( <ACTIVE> | <INACTIVE> ) ( <PRIMARY> | <BACKUP> )
<route-previous-state> ::= ( <ACTIVE> | <INACTIVE> ) ( <PRIMARY> | <BACKUP> )
<route-chg-reason> ::= <ORIG_ADV> | <ORIG_WITHDRAW> | <ADJ_DOWN> | <POLICY_DENY>
<area-list> ::= [ <area> ... ]
<area> ::= <area-parameters> <lsdb> <interface-list> [ <network-list> ] [ <router-info-list> ]
<area-parameters> ::= <AREA_ID> <area-type> <area-status> [ <LSA_ARRIVAL_INT> ] [ <LSA_ORIG_INT> ] [ <ROUTER_NUMBER> ] [ <area-auth> ]
<area-type> ::= <NORMAL> | <STUB> | <NSSA>
<area-status> ::= <ACTIVE> | <RESET> | <SHUTDOWN>
<area-auth> ::= <auth-mode-type>
<auth-mode-type> ::= <mode-simple> | <mode-md5> | <mode-hmac-sha256> | <mode-keychain>
<mode-simple> ::= <PASSWORD>
<mode-md5> ::= <PASSWORD>
<mode-hmac-sha256> ::= <KEY_ID> <PASSWORD>
<mode-keychain> ::= <KEY_ID> <PASSWORD> <keychain-mode> [ <SEND_TIME> ] [ <RECEIVE_TIME> ]
<keychain-mode> ::= <ABSOLUTE> | <periodic>
<periodic> ::= <DAILY> | <WEEKLY> | <MONTHLY> | <YEARLY>
<lsdb> ::= <lsdb-status> <LSDB_SIZE> [ <LSDB_OVERFLOW_LIMIT> ] <lsa-list>
<lsdb-status> ::= <NORMAL> | <OVERFLOW>
<network-list> ::= [ <network> ... ]
<network> ::= [ (<IPV4_ADDRESS> <MASK>) ... ]
<router-info-list> ::= [ <router-info> ... ]
<router-info> ::= <ROUTER_ID> [ <IP_ADDRESS> ...]
<lsa-list> ::= <lsa2-list> | <lsa3-list>
<lsa2-list> ::= [ <lsa2> ... ]
<lsa2> ::= <lsa2-header> <ospf-v2-lsa>
<lsa2-header> ::= <LSA_AGE> <LSA_OPTIONS> <lsa-v2-type> <LINK_STATE_ID> <advertiser-id> <SEQ_NO> <CHKSUM> <LSA_LENGTH>
<lsa-v2-type> ::= <ROUTER_LSA> | <NETWORK_LSA> | <SUMMARY_LSA> | <AS_EXTERNAL_LSA> | <NSSA_LSA>
<advertiser-id> ::= <ROUTER_ID>
<ospf-v2-lsa> ::= <ospf-v2-router-lsa> | <ospf-v2-network-lsa> | <ospf-v2-summary-lsa> | <ospf-v2-as-external-lsa> | <ospf-v2-nssa-external-lsa> | <ospf-v2-te-router-lsa> | <ospf-v2-te-link-lsa>
<lsa3-list> ::= [ <lsa3> ... ]
<lsa3> ::= <lsa3-header> <ospf-v3-lsa>
<lsa3-header> ::= <LSA_AGE> <lsa-v3-type> <link-state-id> <advertiser-id> <SEQ_NO> <CHKSUM> <LSA_LENGTH>
<lsa-v3-type> ::= <U_BIT> <flood-scope> <function-code>
<flood-scope> ::= <LINK_LOCAL> | <AREA> | <AS>
<function-code> ::= <ROUTER_LSA> | <NETWORK_LSA> | <SUMMARY_LSA> | <AS_EXTERNAL_LSA> | <NSSA_LSA>
<ospf-v3-lsa> ::= <ospf-v3-router-lsa> | <ospf-v3-network-lsa> | <ospf-v3-inter-area-prefix-lsa> | <ospf-v3-inter-area-router-lsa> | <ospf-v3-as-external-lsa> | <ospf-v3-nssa-lsa> | <ospf-v3-link-lsa> | <ospf-v3-intra-area-prefix-lsa> | <ospf-v3-te-router-ipv6-address-lsa> | <ospf-v3-te-link-lsa>
<interface-list> ::= [ <interface> ... ]
<interface> ::= <INTERFACE_INDEX> <INTERFACE_NAME> <interface-status> <IP_ADDRESS> [ <interface-down-reason> ] [ <interface-net-type> ] [ <interface-role> ] [ <interface-te-info> ] [ <interface-auth> ] [ <nbr-list> ]
<interface-net-type> ::= <P2P> | <BRODCAST> | <NBMA> | <P2MP>
<interface-status> ::= <IF_UP> | <IF_DOWN>
<interface-down-reason> ::= <PHY_DOWN> | <ADMIN_DOWN> | <IP_DOWN>
<interface-role> ::= <DR> | <BDR> | <DROther>
<interface-auth> ::= <auth-mode-type>
<interface-te> ::= <ADMIN_GROUP> <IP_ADDR> <NBR_IP_ADDR> <MAX_BANDWIDTH> <MAX_RSV_BANDWIDTH> <UNRSV_BANDWIDTH>
<nbr-list> ::= <nbr> [ <nbr> ... ]
<nbr> ::= <ROUTER_ID> <INTERFACE_INDEX> <INTERFACE_NAME> <nbr-status> [ <nbr-previous-status> ] [ <nbr-down-reason> ] <nbr-address>
<nbr-status> ::= <DOWN> | <ATTEMPT> | <2-WAY> | <EXSTAT> | <EXCHANGE> | <LOADING> | <FULL>
<nbr-previous-status> ::= <DOWN> | <ATTEMPT> | <2-WAY> | <EXSTAT> | <EXCHANGE> | <LOADING> | <FULL>
<nbr-down-reason> ::= <IF_DOWN> | <BFD_DOWN> | <EXPIRATION> | <CFD_CHG> | <I2RS_DOWN>
<nbr-address> ::= <IP_ADDRESS>
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
| +--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
| +--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 | | | +--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 | | | +--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 | | +--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
+--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
| | +--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]
| | +--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]
| | +--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
| | +--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
This draft includes no request to IANA.
This document introduces no new security threat and SHOULD follow the security requirements as stated in [I-D.ietf-i2rs-architecture].
TBD
| [I-D.hares-i2rs-info-model-policy] | Hares, S. and W. Wu, "An Information Model for Basic Network Policy", Internet-Draft draft-hares-i2rs-info-model-policy-03, July 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", Internet-Draft draft-ietf-i2rs-architecture-05, July 2014. |
| [I-D.ietf-i2rs-rib-info-model] | Bahadur, N., Folkes, R., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-03, May 2014. |
| [I-D.wu-i2rs-igp-usecases] | Wu, N., Li, Z. and S. Hares, "Use Cases for an Interface to IGP Protocol", Internet-Draft draft-wu-i2rs-igp-usecases-00, July 2014. |
| [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. |