One document matched: draft-wang-i2rs-ospf-info-model-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-wang-i2rs-ospf-info-model-00"
ipr="trust200902">
<front>
<title abbrev="OSPF information model">I2RS Information Model for OSPF
protocol</title>
<author fullname="Eric Wu" initials="E." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>eric.wu@huawei.com</email>
</address>
</author>
<author fullname="Lixing Wang" initials="L." surname="Wang">
<organization>Huawei</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<region/>
<code>10095</code>
<country>China</country>
</postal>
<phone/>
<facsimile/>
<email>wanglixing@huawei.com</email>
<uri/>
</address>
</author>
<author fullname="Susan Hares" initials="S." surname="Hares">
<organization>Huawei</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<phone/>
<facsimile/>
<email>shares@ndzh.com</email>
<uri/>
</address>
</author>
<date month="September" year="2014"/>
<abstract>
<t>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.</t>
<t>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.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>As one of well-known link-state protocols, OSPF<xref
target="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<xref
target="I-D.ietf-i2rs-architecture"/> is a standard-based interface
which provides a programmatic way to achieve this goal.</t>
<t>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 <xref
target="I-D.wu-i2rs-igp-usecases"/> can be supported.</t>
<t>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
<xref target="I-D.ietf-i2rs-rib-info-model"/>.</t>
</section>
<section title="OSPF data">
<t>This section describes the data involved in the OSPF information
model in detail. Please note OSPF in this document means both OSPFv2 and
OSPFv3<xref target="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.</t>
<t><figure align="center">
<artwork><![CDATA[ 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
]]></artwork>
</figure></t>
<section title="OSPF instance">
<t>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.</t>
<figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure>
<section title="Instance parameters">
<t><list style="symbols">
<t>ospf-instance-name: A name uniquely identifying OSPF instance
across all of those supported on one network device.</t>
<t>ospf-vpn-name: The name of the VPN instance which this
instance is binded to.</t>
<t>router-id: The identification of this process. Every
router-id MUST be unique among the OSPF network.</t>
<t>protocol-status: The status of current process. Valid status
could include Active, Suppressed, Shutdown, Stub, Reset or
etc.</t>
<t>ospf-type: This indicates whether this OSPF routing system is
acting as an ABR or ASBR in this instance.</t>
<t>version: The version number of OSPF protocol. Valid input
SHOULD be V2 or V3.</t>
<t>ospf-instance-create-mode: The mode used to create OSPF
instance through I2RS Agent.</t>
<t>preference: The OSPF route preference for current
process.</t>
<t>hostname: The symbolic name used to represent current
process, which would be more preferable for human eyes.</t>
</list></t>
</section>
<section title="Multi-topology-list">
<t>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.</t>
</section>
</section>
<section title="OSPF multi-topology">
<t>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.<list style="symbols">
<t>mt-id: The identifier of this MT. This ID is globally unique
across the routing domain.</t>
<t>address-family: The address family supported on this MT.</t>
<t>mt-status: The status of this MT. Valid input MAY be Active or
Inactive.</t>
<t>policy-list: This list contains those policies referenced
within this OSPF MT. It is optional for the MT to reference policy
or not.</t>
<t>mt-rib: The routing information base for this MT.</t>
<t>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.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
<section title="OSPF MT route">
<t><list style="symbols">
<t>prefix: The destination address of this route.</t>
<t>nexthop-list: The nexthops of this route.</t>
<t>backup nexthop: The backup nexthop for this route.</t>
<t>metric: The metric for this routes.</t>
<t>type: The type for this route. Valid input MAY be OSPF or
OSPF_ASE.</t>
<t>route-state-info: The current and previous state of this
route, the reason for this change and the related LSA invovled
for this route.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
</section>
<section title="OSPF area">
<t>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.</t>
<figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure>
<section title="Area parameters">
<t>This section demonstrates those parameters in area scope.<list
style="symbols">
<t>area-id: The identification of this level which SHOULD be
level-1 or level-2.</t>
<t>area-type: The type of current area. Valid choice SHOULD be
Normal, STUB or NSSA.</t>
<t>area-status: The status of current area. Valid input SHOULD
be Active, Shutdown or Reset.</t>
<t>lsa-arrival-int: The interval of arrival between two
consecutive LSA.</t>
<t>lsa-orig-int: The interval of origination between two
consecutive LSA.</t>
<t>router-number: The total number of routers working in current
area.</t>
<t>area-auth: The information related to area authentication,
including authentication mode, password and other
attributes.</t>
</list></t>
</section>
<section title="Link state database">
<t>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.<list
style="symbols">
<t>lsdb-status: This represents the current status for database.
It MAY be Normal or Overflow or something else.</t>
<t>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.</t>
<t>lsdb-size: The size of database in the form of LSP number or
bytes or percentage.</t>
<t>lsa-list: This list indicates those LSAs which are advertised
in current area by either remote router or self-origination.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="OSPFv2 Link State Advertisement">
<t>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.<list style="symbols">
<t>lsa-age: The time in seconds since the LSA was
originated.</t>
<t>lsa-options: The optional capabilities supported by the
described portion of the routing domain.</t>
<t>lsa-v2-type: The type of LSA. There are 6 types of LSA for
OSPFv2 in total.</t>
<t>link-state-id: The identifier for this LSA which is decided
by originating router.</t>
<t>advertiser-id: The Router ID of the router that originated
the LSA.</t>
<t>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.</t>
<t>chksum: The Fletcher checksum of the complete contents of the
LSA, including the LSA header but excluding the lsa-age
field.</t>
<t>lsa-length: The length in bytes of the LSA.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>nssa-lsa: NSSA-LSAs are the Type 7 LSAs. There LSAs are
originated by NSSA AS boundary routers for imported external
routes.</t>
<t>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.</t>
<t>te-link-lsa: This LSA is used to carry the Link TLV which
describes traffic engineering information related to a single
link.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="OSPFv3 Link State Advertisement">
<t>This section demonstrates some important components of LSA for
OSPFv3 protocol.<list style="symbols">
<t>lsa-age: The time in seconds since the LSA was
originated.</t>
<t>lsa-v3-type: The type of LSA. There are 8 types of LSA for
OSPFv3 in total.</t>
<t>lsa-state-id: The identifier for this LSA which is decided by
originating router.</t>
<t>advertiser-id: The Router ID of the router that originated
the LSA.</t>
<t>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.</t>
<t>chksum: The Fletcher checksum of the complete contents of the
LSA, including the LSA header but excluding the lsa-age
field.</t>
<t>lsa-length: The length in bytes of the LSA.</t>
<t>router-lsa: Router-LSAs have LS type equal to 0x2001. Each
router in an area originates one or more router-LSAs.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
<t>nssa-lsa: NSSA-LSAs have LS type equal to 0x2007. These LSAs
are originated by AS boundary routers within an NSSA and
describe destinations external to the AS that may or may not be
propagated outside the NSSA.</t>
<t>link-lsa: Link-LSAs have LS type equal to 0x0008. A router
originates a separate link-LSA for each attached physical
link.</t>
<t>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.</t>
<t>te-link-lsa: This LSA is used to carry the Link TLV which
describes traffic engineering information related to a single
link.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="Interface-list">
<t>This list contains interfaces enabled in this area. The
information model of interface-list will be elaborated in the
section below.</t>
</section>
<section title="Network-list">
<t>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.</t>
</section>
<section title="Router-info database">
<t>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.</t>
</section>
</section>
<section title="OSPF interface">
<t>This section demonstrates the information model of OSPF
interfaces.</t>
<section title="Interface parameters">
<t><list style="symbols">
<t>interface-index: The index for this interface. It MUST be
unique globally in the same routing system.</t>
<t>interface-name: The name used to refer to this interface.</t>
<t>interface-status: The state of this interface in current
area. Valid state SHOULD be DOWN, P2P, WAITING, DR, BDR or
DROther.</t>
<t>interface-down-reason: The reason the state of this interface
changed to down. Valid reason SHOULD be Physical-down,
Admin-shutdown or IP-down.</t>
<t>interface-net-type: The network type simulated on this
interface. Valid choice SHOULD be P2P, Broadcast, NBMA, P2MP or
even virtual-link.</t>
<t>interface-role: The identification of DR, BDR or DROther role
for this interface.</t>
<t>interface-te-info: The traffic-engineer information related
to this interface.</t>
<t>interface-auth: The information related to interface
authentication, including authentication mode, password and
other attributes.</t>
<t>ip-address: The IPv4 or IPv6 address of this interface.</t>
<t>nbr-list: The neighbor list on this interface.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="Interface neighbor">
<t>This section describes the neighbor information related to one
interface.<list style="symbols">
<t>router-id: The Router-ID of one neighbor supported on this
interface.</t>
<t>interface-index: The index for the interface which this
neighbor belongs to.</t>
<t>interface-name: The name used to refer to this interface.</t>
<t>nbr-status: The status for the adjacency with this neighbor.
Valid input SHOULD be Down, Attempt, 2-way, ExStart, Exchange,
Loading and Full.</t>
<t>nbr-previous-status: The status for the adjacency with this
neighbor before the latest change.</t>
<t>nbr-down-reason: The reason this adjacency was brought. Valid
choice SHOULD be Interface-down, BFD-down, Expired and
CFG-change.</t>
<t>nbr-address: The IPv4 or IPv6 address for this neighbor.</t>
</list><figure align="center">
<artwork><![CDATA[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]]></artwork>
</figure></t>
</section>
<section title="Interface traffic engineering">
<t>This section describes the TE related data on this
interface.<list style="symbols">
<t>interface-index: The index for this interface. It MUST be
unique globally in the same routing system.</t>
<t>admin-Group: The bit mask assigned by operators used for
identifying administrative group.</t>
<t>ipv4-address: A 4-octet IPv4 address for the interface
described by interface-index.</t>
<t>nbr-ipv4-address: A single IPv4 address for a neighboring
router on this link.</t>
<t>max-link-bandwidth: The maximum bandwidth that can be used on
this link in this direction.</t>
<t>max-rsv-bandwidth: The maximum amount of bandwidth that can
be reserved in this direction on this link.</t>
<t>unrsv-bandwidth: The amount of bandwidth reservable in this
direction on this link.</t>
</list></t>
</section>
</section>
</section>
<section title="OSPF notification">
<t>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.</t>
<section title="Adjacency">
<t>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.</t>
</section>
<section title="LSDB">
<t>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.</t>
</section>
<section title="Route">
<t>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.</t>
</section>
<section title="TE">
<t>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.</t>
</section>
<section title="Protocol statistics">
<t>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.</t>
</section>
</section>
<section title="OSPF operation">
<t>Based on the standardized information model of OSPF protocol as
described above, use cases defined in <xref
target="I-D.wu-i2rs-igp-usecases"/> can be supported. This section
demonstrates several specific examples of these use cases.</t>
<section title="Router number monitoring">
<t>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.</t>
<t>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.</t>
</section>
<section title="Router-ID conflict recovery">
<t>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.</t>
<t>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.</t>
</section>
</section>
<section title="OSPF grammar">
<t>This section demonstrates the information model of OSPF
routing-protocol using the syntax stated in <xref target="RFC5511"/></t>
<section title="Instance">
<t><OSPF routing-protocol> ::= [ <OSPF instance> ... ]</t>
<t><OSPF instance> ::= <instance-parameters>
<multi-topo-list></t>
<t><instance-parameters> ::= <OSPF_INSTANCE_NAME> [
<OSPF_VPN_NAME> ] <ROUTER_ID> <protocol-status>
<ospf-type> <version> <ospf-instance-create-mode> [
<PREFERENCE> ] [ <HOSTNAME> ]</t>
<t><ospf-type> ::= <ABR> | <ASBR> | <NONE></t>
<t><protocol-status> ::= <ACTIVE> | <RESET> |
<SHUTDOWN> | <OVERLOAD></t>
<t><version> ::= <V2> | <V3></t>
</section>
<section title="Multi-topology">
<t><multi-topo-list> ::= [ <mt> ... ]</t>
<t><mt> ::= <MT_ID> <address-family>
<mt-status> [ <policy-list> ] <mt-rib>
<area-list></t>
<t><address-family> ::= <V4UR> | <V6UR> |
<V4MR> | <V6MR></t>
<t><mt-status> ::= <ACTIVE> | <INACTIVE></t>
<t><mt-rib> ::= <route-list></t>
<t><area-list> ::= [ <area> ... ]</t>
<t><policy-list> ::= [ <Policy-Rule> ... ]</t>
<t><Policy-Rule> SHOULD follow the definition in the information
model for policy as stated in <xref
target="I-D.hares-i2rs-info-model-policy"/>.</t>
<t><route-list> ::= <route> [ <route> ... ]</t>
<t><route> ::= <PREFIX> <nexthop-list> [
<back-nexthop> ] <METRIC> <TYPE>
<route-state-info></t>
<t><backup-nexthop> ::= <nexthop></t>
<t><nexthop-list> and <nexthop> SHOULD follow the
definition in the RIB iformation model as stated in <xref
target="I-D.ietf-i2rs-rib-info-model"/>.</t>
<t><route-state-info> ::= <route-current-state> [
<route-previous-state> ] [ <route-chg-reason> ] [
<LSID> <lsa-type> <advertiser> ]</t>
<t><route-current-state> ::= ( <ACTIVE> | <INACTIVE>
) ( <PRIMARY> | <BACKUP> )</t>
<t><route-previous-state> ::= ( <ACTIVE> |
<INACTIVE> ) ( <PRIMARY> | <BACKUP> )</t>
<t><route-chg-reason> ::= <ORIG_ADV> |
<ORIG_WITHDRAW> | <ADJ_DOWN> | <POLICY_DENY></t>
</section>
<section title="Area">
<t><area-list> ::= [ <area> ... ]</t>
<t><area> ::= <area-parameters> <lsdb>
<interface-list> [ <network-list> ] [
<router-info-list> ]</t>
<t><area-parameters> ::= <AREA_ID> <area-type>
<area-status> [ <LSA_ARRIVAL_INT> ] [ <LSA_ORIG_INT>
] [ <ROUTER_NUMBER> ] [ <area-auth> ]</t>
<t><area-type> ::= <NORMAL> | <STUB> |
<NSSA></t>
<t><area-status> ::= <ACTIVE> | <RESET> |
<SHUTDOWN></t>
<t><area-auth> ::= <auth-mode-type></t>
<t><auth-mode-type> ::= <mode-simple> | <mode-md5> |
<mode-hmac-sha256> | <mode-keychain></t>
<t><mode-simple> ::= <PASSWORD></t>
<t><mode-md5> ::= <PASSWORD></t>
<t><mode-hmac-sha256> ::= <KEY_ID> <PASSWORD></t>
<t><mode-keychain> ::= <KEY_ID> <PASSWORD>
<keychain-mode> [ <SEND_TIME> ] [ <RECEIVE_TIME>
]</t>
<t><keychain-mode> ::= <ABSOLUTE> | <periodic></t>
<t><periodic> ::= <DAILY> | <WEEKLY> |
<MONTHLY> | <YEARLY></t>
<t/>
<t><lsdb> ::= <lsdb-status> <LSDB_SIZE> [
<LSDB_OVERFLOW_LIMIT> ] <lsa-list></t>
<t><lsdb-status> ::= <NORMAL> | <OVERFLOW></t>
<t/>
<t><network-list> ::= [ <network> ... ]</t>
<t><network> ::= [ (<IPV4_ADDRESS> <MASK>) ... ]</t>
<t/>
<t><router-info-list> ::= [ <router-info> ... ]</t>
<t><router-info> ::= <ROUTER_ID> [ <IP_ADDRESS>
...]</t>
<t/>
<t><lsa-list> ::= <lsa2-list> | <lsa3-list></t>
<t><lsa2-list> ::= [ <lsa2> ... ]</t>
<t><lsa2> ::= <lsa2-header> <ospf-v2-lsa></t>
<t><lsa2-header> ::= <LSA_AGE> <LSA_OPTIONS>
<lsa-v2-type> <LINK_STATE_ID> <advertiser-id>
<SEQ_NO> <CHKSUM> <LSA_LENGTH></t>
<t><lsa-v2-type> ::= <ROUTER_LSA> | <NETWORK_LSA> |
<SUMMARY_LSA> | <AS_EXTERNAL_LSA> | <NSSA_LSA></t>
<t><advertiser-id> ::= <ROUTER_ID></t>
<t><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></t>
<t/>
<t><lsa3-list> ::= [ <lsa3> ... ]</t>
<t><lsa3> ::= <lsa3-header> <ospf-v3-lsa></t>
<t><lsa3-header> ::= <LSA_AGE> <lsa-v3-type>
<link-state-id> <advertiser-id> <SEQ_NO>
<CHKSUM> <LSA_LENGTH></t>
<t><lsa-v3-type> ::= <U_BIT> <flood-scope>
<function-code></t>
<t><flood-scope> ::= <LINK_LOCAL> | <AREA> |
<AS></t>
<t><function-code> ::= <ROUTER_LSA> | <NETWORK_LSA>
| <SUMMARY_LSA> | <AS_EXTERNAL_LSA> | <NSSA_LSA></t>
<t><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></t>
</section>
<section title="Interface">
<t><interface-list> ::= [ <interface> ... ]</t>
<t><interface> ::= <INTERFACE_INDEX>
<INTERFACE_NAME> <interface-status> <IP_ADDRESS> [
<interface-down-reason> ] [ <interface-net-type> ] [
<interface-role> ] [ <interface-te-info> ] [
<interface-auth> ] [ <nbr-list> ]</t>
<t><interface-net-type> ::= <P2P> | <BRODCAST> |
<NBMA> | <P2MP></t>
<t><interface-status> ::= <IF_UP> | <IF_DOWN></t>
<t><interface-down-reason> ::= <PHY_DOWN> |
<ADMIN_DOWN> | <IP_DOWN></t>
<t><interface-role> ::= <DR> | <BDR> |
<DROther></t>
<t><interface-auth> ::= <auth-mode-type></t>
<t><interface-te> ::= <ADMIN_GROUP> <IP_ADDR>
<NBR_IP_ADDR> <MAX_BANDWIDTH> <MAX_RSV_BANDWIDTH>
<UNRSV_BANDWIDTH></t>
<t><nbr-list> ::= <nbr> [ <nbr> ... ]</t>
<t><nbr> ::= <ROUTER_ID> <INTERFACE_INDEX>
<INTERFACE_NAME> <nbr-status> [
<nbr-previous-status> ] [ <nbr-down-reason> ]
<nbr-address></t>
<t><nbr-status> ::= <DOWN> | <ATTEMPT> |
<2-WAY> | <EXSTAT> | <EXCHANGE> | <LOADING> |
<FULL></t>
<t><nbr-previous-status> ::= <DOWN> | <ATTEMPT> |
<2-WAY> | <EXSTAT> | <EXCHANGE> | <LOADING> |
<FULL></t>
<t><nbr-down-reason> ::= <IF_DOWN> | <BFD_DOWN> |
<EXPIRATION> | <CFD_CHG> | <I2RS_DOWN></t>
<t><nbr-address> ::= <IP_ADDRESS></t>
</section>
</section>
<section title="I2RS YANG model of OSPF">
<t>
<figure align="center">
<artwork>
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
</artwork>
</figure>
<figure>
<artwork>
| +--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
</artwork>
</figure>
<figure>
<artwork>
| +--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
</artwork>
</figure>
<figure>
<artwork>
| | +--:(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
</artwork>
</figure>
<figure>
<artwork>
| +--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
</artwork>
</figure>
<figure>
<artwork>
+--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
</artwork>
</figure>
</t>
</section>
<section title="IANA Considerations ">
<t>This draft includes no request to IANA.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document introduces no new security threat and SHOULD follow the
security requirements as stated in <xref
target="I-D.ietf-i2rs-architecture"/>.</t>
</section>
<section title="Acknowledgements">
<t>TBD</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.I-D.ietf-i2rs-architecture"?>
<?rfc include='reference.I-D.wu-i2rs-igp-usecases'?>
<?rfc include='reference.I-D.ietf-i2rs-rib-info-model'?>
<?rfc include='reference.I-D.hares-i2rs-info-model-policy'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.2328'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.5511'?>
<?rfc include='reference.RFC.2119'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:56:10 |