Internet DRAFT - draft-wang-i2rs-ospf-info-model
draft-wang-i2rs-ospf-info-model
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
<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>
5.2. Multi-topology
<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>
Wu, et al. Expires March 30, 2015 [Page 20]
Internet-Draft OSPF information model September 2014
<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>
5.3. Area
<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>
Wu, et al. Expires March 30, 2015 [Page 21]
Internet-Draft OSPF information model September 2014
<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> |
Wu, et al. Expires March 30, 2015 [Page 22]
Internet-Draft OSPF information model September 2014
<ospf-v3-intra-area-prefix-lsa> | <ospf-v3-te-router-ipv6-address-
lsa> | <ospf-v3-te-link-lsa>
5.4. Interface
<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>
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]
