I2RS working group S. Hares
Internet-Draft L. Wang
Intended status: Standards Track Huawei
Expires: May 14, 2015 November 10, 2014

Comparison Between 2 ISIS Yang Drafts
draft-hares-i2rs-isis-compare-yang-00

Abstract

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.

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."

This Internet-Draft will expire on May 14, 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

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.

This draft is a comparison of the following two ISIS yang models: [I-D.litkowski-isis-yang-isis-cfg], and [I-D.wang-i2rs-isis-dm]. 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 [I-D.ietf-i2rs-usecase-reqs-summary]. Additional explanatory information on the [I-D.wang-i2rs-isis-dm] is available in the [I-D.wu-i2rs-isis-info-model].

Please note the IGP use cases have been determined to be out of charter (OC) by the I2RS chairs.

The rest of this draft is the details so those who desire "sounds bytes" level reading may stop reading now.

2. Definitions and Acronyms

3. Comparison of draft-litkowski-isis-yang-isis-cfg-01 with draft-wang-ospf-dm-00

[I-D.litkowski-isis-yang-isis-cfg] was released on June 27, 2014. The [I-D.litkowski-isis-yang-isis-cfg] has the following parts:

The configuration portion of [I-D.litkowski-isis-yang-isis-cfg] has a different structure than [I-D.wang-i2rs-isis-dm] with the key difference being how the isis-mt structure is defined. The [I-D.litkowski-isis-yang-isis-cfg] 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 [I-D.wang-i2rs-isis-dm] 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 [I-D.litkowski-isis-yang-isis-cfg] variant of configuration uses a boolean value (isis-multi-topology-cfg)to determine if a family is supported in the isis-mt configuration support.

The second of [I-D.litkowski-isis-yang-isis-cfg] 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 [I-D.wang-i2rs-isis-dm]. The isis-lsp-database in [I-D.litkowski-isis-yang-isis-cfg] 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 [I-D.wang-i2rs-isis-dm].

The third section of [I-D.litkowski-isis-yang-isis-cfg] contains: [I-D.wang-i2rs-isis-dm] 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.

The

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.

4. Major differences in yang structures

the remaining difference are the following:

5. Unique features for I2RS IGP Requirements

The following are unique features for I2RS IGP requirements: [I-D.wang-i2rs-isis-dm] are described in the sections below.

These I2RS features in

5.1. mt-rib

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 [I-D.ietf-i2rs-usecase-reqs-summary] may aid in detecting the condition.

        +--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
		

5.2. nbr-list

The isis yang structure nbr-list supports fast convergence during loss of an ospf neighbor.

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.

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.

 
            |  +--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
		

5.3. state information for route change and neighbor change

         +--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  
		

The following are additions that [I-D.wang-i2rs-isis-dm] adds to support route state querying.

6. Merge Suggestions

[I-D.litkowski-isis-yang-isis-cfg] and [I-D.wang-i2rs-isis-dm] 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

7. IANA Considerations

This draft includes no request to IANA.

8. Security Considerations

None since this is just an analysis draft

9. Informative References

[I-D.ietf-i2rs-architecture] Atlas, A., Halpern, J., Hares, S., Ward, D. and T. Nadeau, "An Architecture for the Interface to the Routing System", Internet-Draft draft-ietf-i2rs-architecture-00, August 2013.
[I-D.ietf-i2rs-rib-info-model] Bahadur, N., Folkes, R., Kini, S. and J. Medved, "Routing Information Base Info Model", Internet-Draft draft-ietf-i2rs-rib-info-model-01, October 2013.
[I-D.ietf-i2rs-usecase-reqs-summary] Hares, S. and M. Chen, "Summary of I2RS Use Case Requirements", Internet-Draft draft-ietf-i2rs-usecase-reqs-summary-00, November 2014.
[I-D.litkowski-isis-yang-isis-cfg] Litkowski, S., "Yang Data Model for ISIS protocol", Internet-Draft draft-litkowski-isis-yang-isis-cfg-01, June 2014.
[I-D.wang-i2rs-isis-dm] Wang, L., Hares, S. and N. Wu, "Yang Data model I2RS to IS-IS protocol", Internet-Draft draft-wang-i2rs-isis-dm-00, September 2014.
[I-D.wu-i2rs-isis-info-model] Wu, N., Wang, L. and S. Hares, "Information model for IS-IS protocol", Internet-Draft draft-wu-i2rs-isis-info-model-00, September 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3060] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, "Policy Core Information Model -- Version 1 Specification", RFC 3060, February 2001.
[RFC3460] Moore, B., "Policy Core Information Model (PCIM) Extensions", RFC 3460, January 2003.
[RFC3644] Snir, Y., Ramberg, Y., Strassner, J., Cohen, R. and B. Moore, "Policy Quality of Service (QoS) Information Model", RFC 3644, November 2003.

Authors' Addresses

Susan Hares Huawei 7453 Hickory Hill Saline, MI 48176 USA EMail: shares@ndzh.com
Lixing Wang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing, 10095 China EMail: wanglixing@huawei.com