One document matched: draft-hares-i2rs-ospf-compare-yang-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3060.xml">
<!ENTITY RFC3460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY RFC3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY RFC5511 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5511.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.atlas-i2rs-policy-framework SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.atlas-i2rs-policy-framework.xml">
<!ENTITY I-D.ietf-i2rs-usecase-reqs-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-usecase-reqs-summary.xml">
<!ENTITY I-D.bogdanovic-netmod-acl-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bogdanovic-netmod-acl-model.xml">
<!ENTITY I-D.yeung-netmod-ospf SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.yeung-netmod-ospf.xml">
<!ENTITY I-D.wu-i2rs-ospf-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-i2rs-ospf-info-model-00.xml">
<!ENTITY I-D.wang-i2rs-ospf-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-i2rs-ospf-dm.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<rfc category="std" docName="draft-hares-i2rs-ospf-compare-yang-00" ipr="trust200902">
<front>
<title abbrev="ospf yang i2rs-cfg Compare">Comparison Between 2 OSPF Yang Drafts </title>
<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>
<email>shares@ndzh.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>
<date year="2014" />
<area>Routing Area</area>
<workgroup>I2RS working group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>I2RS</keyword>
<abstract>
<t>This document contains a comparison of two OSPF yang models:
draft-yeung-netmod-ospf-02 and draft-wang-i2rs-ospf-dm.
The yang model in draft-yeung-netmod-ospf-02 is
model focused on configuration. The yang model in draft-wang-i2rs-ospf-dm-00
is focused on the status and ephemeral state changes needed for
the I2RS interface. The conclusion of comparison is that there
little overlap except the definitions of common ospf structures.
The draft-wang-i2rs-ospf-dm-00 is necessary to fulfil a majority
of the requirement drawn from the IGP use cases in the I2RS
use cases.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The Interface to the Routing System (I2RS) provides read and write
access to the information and state within the routing process within
routing elements. The I2RS client interacts with one or more I2RS agents
to collect information from network routing systems.
The processing of collecting information at the I2RS agent may require the
I2RS Agent to filter certain information, group pieces of information, or
perform actions on the I2rs collected information based on specific
I2rs policies.</t>
<t>
This draft is a comparison of the following two OSPF yang models:
<xref target="I-D.yeung-netmod-ospf"></xref>, and
<xref target="I-D.wang-i2rs-ospf-dm"></xref>.
The comparison provides an overview of the differences, overlaps, and unique features of
each yang model. The analysis also evaluates whether both
models or a single model is necessary to satisfy the requirements
for the IGP use cases found in the <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>.
Additional explanatory information on the <xref target="I-D.wang-i2rs-ospf-dm"></xref>
is available in the <xref target="I-D.wu-i2rs-ospf-info-model"></xref>.
</t>
<t>
At this time the I2RS chairs have determined that the IGP use cases found in the
<xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref> are out of scope.
</t>
<t>
The rest of this draft is the details so those who desire "sounds bytes" level reading may
stop reading now.
</t>
</section>
<section title="Definitions and Acronyms">
<t><list>
<t>BGP - Border Gateway Protocol version 4 </t>
<t>CLI: Command Line Interface</t>
<t>IGP: Interior Gateway Protocol</t>
<t> I2RS: Interface to (2) Routing system. </t>
<t>Information Model: An abstract model of a conceptual domain,
independent of a specific implementations or data representation</t>
<t>INSTANCE: Routing Code often has the ability to spin up multiple
copies of itself into virtual machines. Each Routing code instance or
each protocol instance is denoted as Foo_INSTANCE in the text below. </t>
<t>NETCONF: The Network Configuration Protocol</t>
<t>RESTCONF: The RESTCONF Protocol </t>
</list></t>
</section>
<section title="Comparison of draft-yeung-netmod-ospf-01 with draft-wang-ospf-dm-00">
<t>
The draft-yeung-netmod-ospf-01 has substantial differences with
<xref target="I-D.wang-i2rs-ospf-dm"></xref>.
However, these differences are most mostly configuration, in which the configurations utilize
different views: ospf-view (protocol), ospf-area-view, and ospf-interface-view.
<xref target="I-D.wang-i2rs-ospf-dm"></xref> has a similar structure for the
following group and type definitions: ospf ,ospf-area, ospf interface and TE information.
In the draft <xref target="I-D.wang-i2rs-ospf-dm"></xref> this information is just for the
definitions in order to attach the necessary status status. The draft <xref target="I-D.wang-i2rs-ospf-dm"></xref>
does not provide any configuration.
The real-time status information provided by <xref target="I-D.wang-i2rs-ospf-dm"></xref>
includes: ospf-mt, ospf-rib, ospf-neighbor, ospf-lsa-database, ospf state, and ospf status and state information
which is not included in draft-yeung-netmod-ospf-01. </t>
<t> The difference to these two documents is appropriate for the configuration versus I2RS split. </t>
</section>
<section title="Comparison of draft-yeung-netmod-ospf-02 with draft-wang-ospf-dm-00">
<t>
<xref target="I-D.yeung-netmod-ospf"></xref> was released on October 14, 2014.
This draft more closely aligns with <xref target="I-D.wang-i2rs-ospf-dm"></xref>.
<xref target="I-D.yeung-netmod-ospf"></xref> adds ospf-mt, ospf lsa database, ospf-TE, and ospf status
and state information which was included in <xref target="I-D.wang-i2rs-ospf-dm"></xref>.
The <xref target="I-D.yeung-netmod-ospf"></xref> has the following three parts:
<list style="symbols">
<t>configuration with the multi-topology view (write/read)</t>
<t>protocol state and ospf-lsa-database (read only) </t>
<t> notification on events (read-only) </t>
</list>
Parts 2 and 3 of <xref target="I-D.yeung-netmod-ospf"></xref>
to and provide more comprehensive support for status information.
The authors of <xref target="I-D.wang-i2rs-ospf-dm"></xref> support these additions since this
draft brings the definitions of OSPF config and OSPF I2RS closer.
</t>
</section>
<section title="Differences between the drafts">
<t> the remaining difference are the following:
<list style="symbols">
<t> The nodes of <xref target="I-D.wang-i2rs-ospf-dm"></xref> are mostly read/write.
This includes the ospf-ls-database and the ospf-neighbor. In
<xref target="I-D.yeung-netmod-ospf"></xref> nodes are only readable. </t>
<t> <xref target="I-D.wang-i2rs-ospf-dm"></xref> contains the ospf-rib which
<xref target="I-D.yeung-netmod-ospf"></xref> does not have.</t>
<t> <xref target="I-D.wang-i2rs-ospf-dm"></xref> has special nodes for I2RS OSPF use cases
which draft-yeung-netmod-ospf-02 do not have. These nodes are: router-number and route-info-list.
</t>
</list>
</t>
</section>
<section title="Unique features for I2RS IGP Requirements">
<t>The following are unique features for I2RS IGP requirements:
<list style="symbols">
<t> mt-rib - which is used for transient loop avoidance.</t>
<t> nbr-list - to aid fast route convergence in the event of the loss of a neighbor </t>
<t> router-number - which is used for router number monitoring </t>
<t> route-info-list - which is used for router-ID conflict recovery </t>
<t> route state information for subscribing for notification of route changes and neighbor changes </t>
</list>
These I2RS features in <xref target="I-D.wang-i2rs-ospf-dm"></xref> are described in the
sections below.
</t>
<section title="mt-rib">
<t> Link-state protocols may need to reconverge when the network topology changes.
During this phase packet loss and transient loops are frequently observed since
inconsistent RIBs exist, even the reachability of the destinations is not compromised
after the topology change. [IGP-REQ-02] in [I-D.ietf-i2rs-usecase-reqs-summary]
suggests that the there should be rapid cycle of querying and configuration change.
Monitoring via the mechanisms in [IGP-REQ-04] and [IGP-REQ-05], [IGP-REQ-06],
[IGP-REQ-07], and [IGP-REQ-08] in <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref> may aid
in detecting the condition.
</t>
<t>
<figure>
<artwork>
| +--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 1: draft-i2rs-wang-ospf-dm-00 mt-rib structure
</artwork>
</figure>
</t>
</section>
<section title="nbr-list">
<t>The ospf yang structure nbr-list supports fast convergence during loss of an ospf neighbor.
</t>
<t>
IGP Hello packet is used to discover and maintain adjacencies among different ospf nodes.
Without the deployment of fast detection techniques, one node has to wait for several
seconds before it realized the adjacency had broken. This kind of issue can cause one
device is cut off from its network and lose connectivity completely. No matter planned
or accidentally it may cause traffic blackhole before damage can be controlled.
[IGP-REQ-01] and [IGP-REQ-02] plus the monitoring requirements in [IGP-REQ-04] and [IGP-REQ-05],
[IGP-REQ-06], [IGP-REQ-07], and [IGP-REQ-08] in <xref target="I-D.ietf-i2rs-usecase-reqs-summary"></xref>
may aid in detecting the condition
</t>
<t>
Under the scenario of I2RS and IGP information model deployed, it is RECOMMENDED that the adjacency
data of the other end side can be removed simultaneously or LSP can be updated directly by I2RS Agent
when IS-IS is disabled or detached on one side. The configuration of [IGP-REQ-02] can aid in configuring.
The authors suggest this as a beginning step, but there are additional steps to support
fast-convergence when neighbor's change.
</t>
<t>
<figure>
<artwork>
| | +--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
Figure 2 draft-i2rs-wang-ospf-dm-00 ospf-nbr-list structure
</artwork>
</figure>
</t>
</section>
<section title="router-number">
<t>
Customers complain regarding the limits on the number of routers
routers should be deployed in one area. The answer for this
question is not clear in vendor's guide since the product specification
provide limits that guarantee operations. For operations people
looking to see the real limits, the field engineers use words like
"usually", "roughly" or "most of the time". As the consequence, the
customers may simply deploy all routers in one OSPF area, and
deal with the scaling issues after the network grows.
</t>
<t>
With the help of OSPF information model and I2RS interfaces, it is possible
to give such deployment warnings when the limits will be hit 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>
<t>
<figure>
<artwork>
+--rw area-list
| +--rw area* [area-id]
| +--rw area-id uint16
| +--rw router-number? uint32
Figure 3 draft-i2rs-wang-bgp-dm-00 router-id
</artwork>
</figure>
</t>
</section>
<section title="route-info-list">
<t> It is become more common that networks have router-ID conflict in
networks both intra and inter area, especially after different area have merged.
It is time-consuming and troublesome to detect the places 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 the 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>
<t>
<figure>
<artwork>
+--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 4 - OSPF route information
</artwork>
</figure>
</t>
</section>
<section title="ospf route status information" >
<t>The following yang top-level diagram shows additional status for each ospf route:
<figure>
<artwork>
| +--rw mt-rib
| | +--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 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
Figure 5 ospf route and neighbor additions.
</artwork>
</figure>
</t>
</section>
</section>
<section title="Merge Suggestions">
<t>
<xref target="I-D.yeung-netmod-ospf"></xref>
and <xref target="I-D.wang-i2rs-ospf-dm"></xref> cover two
separate areas: configuration and ephemeral state.
These two drafts need to align the definitional part of the drafts
(groupings, typedefs, etc.)to allow implementations to
choose configuration or configuration plus I2RS</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This draft includes no request to IANA.</t>
</section>
<section title="Security Considerations">
<t>None since this is just an analysis draft </t>
</section>
</middle>
<back>
<references title="Informative References">
&RFC2119;
&RFC3060;
&RFC3460;
&RFC3644;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
&I-D.ietf-i2rs-usecase-reqs-summary;
&I-D.wu-i2rs-ospf-info-model;
&I-D.wang-i2rs-ospf-dm;
&I-D.yeung-netmod-ospf;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:24:23 |