One document matched: draft-hares-i2rs-isis-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.litkowski-isis-yang-isis-cfg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.litkowski-isis-yang-isis-cfg.xml">
<!ENTITY I-D.wu-i2rs-isis-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-i2rs-isis-info-model-00.xml">
<!ENTITY I-D.wang-i2rs-isis-dm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.wang-i2rs-isis-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-isis-compare-yang-00" ipr="trust200902">
<front>
<title abbrev="ospf yang i2rs-cfg Compare">Comparison Between 2 ISIS 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 ISIS yang models:
draft-litkowski-isis-yang-isis-cfg-01 and draft-wang-i2rs-isis-dm.
The yang model in draft-litkowski-isis-yang-isis-cfg-01 is
model focused on configuration. The yang model in d
raft-wang-i2rs-isis-dm-00 is focused on the status and ephemeral
state changes needed for IGP use cases specified for I2RS interface by
the I2RS WG. The conclusion of comparison is that there
little overlap except the definitions of common ospf structures.
The draft-wang-i2rs-isis-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 ISIS yang models:
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref>, and
<xref target="I-D.wang-i2rs-isis-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-isis-dm"></xref>
is available in the <xref target="I-D.wu-i2rs-isis-info-model"></xref>.
</t>
<t>
Please note the IGP use cases have been determined to be out of charter (OC) by the I2RS chairs.
</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>ISIS: Intermediate System to Intermediate System Routing Protocol (IGP)</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-litkowski-isis-yang-isis-cfg-01 with draft-wang-ospf-dm-00" >
<t>
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> was released on June 27, 2014.
The <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> has the following parts:
<list style="symbols">
<t>configuration, </t>
<t>operational status information per protocol instance, </t>
<t> RPC operations (clear adjacency, clear isis-database), and </t>
<t> notifications events (read-only). </t>
</list>
</t>
<t>The configuration portion of <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref>
has a different structure than <xref target="I-D.wang-i2rs-isis-dm"></xref>
with the key difference being how the isis-mt structure is defined.
The <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> document has the following sections:
isis protocol (section 2.1), multi-topology parameters (section 2.2),
per isis-level configuration (2.3), and per interface parameters (2.4).
The draft <xref target="I-D.wang-i2rs-isis-dm"></xref> closely mirrors
one variant of the internal structure of the ISIS protocol that contains multi-topology having
configuration definitions for: protocol (isis), multi-topology support (isis-mt, mt-route),
per isis level (isis-level), lsdb (isis-lsdb), and per interface (isis-interface).
The <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> variant of configuration uses
a boolean value (isis-multi-topology-cfg)to determine if a family is supported in the isis-mt
configuration support.
</t>
<t>
The second of <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> contains the
read-only operational state information (isis-state) for adjacencies, spf events, lsp events, LSDB database,
and system-id host name mappings. The same state is included in
<xref target="I-D.wang-i2rs-isis-dm"></xref>. The isis-lsp-database in
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref>
contains a description of the lsp, but not in accordance with the mt-extensions to the ISIS protocol
since it omits the mpls-te information and multi-topology (mt) information. This information is found in
<xref target="I-D.wang-i2rs-isis-dm"></xref>.
</t>
<t> The third section of <xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> contains:
<list style="symbols">
<t> an RPC to clear a isis-adjacency within a protocol instance for a particular set of interfaces and levels.
</t>
<t> an RPC to clear the isis lsdb data base at a particular isis level
</t>
</list>
The <xref target="I-D.wang-i2rs-isis-dm"></xref> does have a read/write variable for
adjacencies and for lsdbs so the config and I2RS methods operate to do the same function.
The I2RS Agent must be aware of the possibility for an isis-adjacency and isis lsdb to be cleared
via the configuration module.
</t>
<t> The fourth section on notifications examines provides a notification based on adjacency up/down.
The I2RS notification process will specify a section of the yang module and a use notifications
to updated the information.
</t>
</section>
<section title="Major differences in yang structures">
<t> the remaining difference are the following:
<list style="symbols">
<t> The nodes of <xref target="I-D.wang-i2rs-isis-dm"></xref> are mostly read/write.
This includes the isis lsp-database and the isis-neighbor lists. In
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> status nodes are only readable. </t>
<t> <xref target="I-D.wang-i2rs-isis-dm"></xref> contains the isis mt-rib which
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref> lacks.</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-ipv4-rib and mt-ipv6-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> 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-isis-dm"></xref> are described in the
sections below.
</t>
<section title="mt-rib">
<t> Link-state protocols may need to re-converge 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-ipv4-rib* [ipv4-prefix]
| +--rw ipv4-prefix inet:ipv4-prefix
| +--rw nexthop-list* [nexthop]
| | +--rw nexthop inet:ipv4-prefix
| +--rw back-nexthop? inet:ipv4-prefix
| +--rw ipv4-isis-route-para
| +--rw metric? uint32
| +--ro type? enumeration
| +--ro route-current-state? route-state-def
| +--ro route-previous-state? route-state-def
| +--rw lsp-id? isis-lsp-id-def
| +--ro route-chg-reason? enumeration
+--rw mt-ipv6-rib* [ipv6-prefix]
| +--rw ipv6-prefix inet:ipv6-prefix
| +--rw nexthop-list* [nexthop]
| | +--rw nexthop inet:ipv6-prefix
| +--rw back-nexthop? inet:ipv4-prefix
| +--rw ipv6-isis-route-para
| +--rw metric? uint32
| +--ro type? enumeration
| +--ro route-current-state? route-state-def
| +--ro route-previous-state? route-state-def
| +--rw lsp-id? isis-lsp-id-def
| +--ro route-chg-reason? Enumeration
Figure 1: draft-i2rs-wang-isis-dm-00 mt-ipv4-rib and mt-ipv6-rib structures
</artwork>
</figure>
</t>
</section>
<section title="nbr-list">
<t>The isis 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 IS-IS nodes.
Without the deployment of fast detection techniques, one node has to wait for several seconds before
it realizes the adjacency has been broken. This kind of issue can cause one device is cut off from
its network causing a complete loss of connectivity. No matter planned or accidentally this outage causes
traffic to be blackholed 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 [I-D.ietf-i2rs-usecase-reqs-summary] may aid in detecting the condition.
</t>
<t>
Under the scenario of where I2RS and IGP information model are 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 an
ISIS neighbor changes.
</t>
<t>
<figure>
<artwork>
| +--rw l1-nbr-list* [l1nbr-system-id]
| | +--rw l1nbr-system-id isis-system-id-def
| | +--rw snpa? uint32
| | +--ro nbr-status? nbr-status-def
| | +--ro nbr-down-reason? nbr-down-reason-def
| | +--ro nbr-type? nbr-type-def
| +--rw l2-nbr-list* [l2nbr-system-id]
| | +--rw l2nbr-system-id isis-system-id-def
| | +--rw snpa? uint32
| | +--ro nbr-status? nbr-status-def
| | +--ro nbr-down-reason? nbr-down-reason-def
| | +--ro nbr-type? nbr-type-def
Figure 2 draft-i2rs-wang-isis-dm-00 l1-nbr-list and l2-nbr-list structures
</artwork>
</figure>
</t>
</section>
<section title="state information for route change and neighbor change">
<t>
The following are additions that <xref target="I-D.wang-i2rs-isis-dm"></xref> adds
to support route state querying.
<figure>
<artwork>
+--rw mt-ipv4-rib* [ipv4-prefix]
+--rw ipv4-prefix
+--rw next-hop-list*
| +--rw next-hop inet:ipv4-prefix
+--rw back-nexthop? inet:ipv4-prefix
+--rw ipv4-isis-route-para
| +--rw metric ?
| +--rw type?
| +--ro route-current-state? route-state-def
| +--ro route-previous-state? route-state-def
| +--rw lsp-id? isis-lsp-id-def
| +--ro route-chg-reason? enumeration
figure 3 draft i2rs-wang-isis-dm-00 route status information
</artwork>
</figure>
</t>
</section>
</section>
<section title="Merge Suggestions">
<t>
<xref target="I-D.litkowski-isis-yang-isis-cfg"></xref>
and <xref target="I-D.wang-i2rs-isis-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-isis-info-model;
&I-D.wang-i2rs-isis-dm;
&I-D.litkowski-isis-yang-isis-cfg;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:26:05 |