Internet DRAFT - draft-hares-i2rs-isis-compare-yang

draft-hares-i2rs-isis-compare-yang







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



Hares & Wang              Expires May 14, 2015                  [Page 1]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions and Acronyms  . . . . . . . . . . . . . . . . . .   3
   3.  Comparison of draft-litkowski-isis-yang-isis-cfg-01 with
       draft-wang-ospf-dm-00 . . . . . . . . . . . . . . . . . . . .   3
   4.  Major differences in yang structures  . . . . . . . . . . . .   4
   5.  Unique features for I2RS IGP Requirements . . . . . . . . . .   5
     5.1.  mt-rib  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     5.2.  nbr-list  . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.3.  state information for route change and neighbor change  .   7
   6.  Merge Suggestions . . . . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   9.  Informative References  . . . . . . . . . . . . . . . . . . .   8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9

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.





Hares & Wang              Expires May 14, 2015                  [Page 2]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


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

2.  Definitions and Acronyms

      BGP - Border Gateway Protocol version 4

      CLI: Command Line Interface

      IGP: Interior Gateway Protocol

      ISIS: Intermediate System to Intermediate System Routing Protocol
      (IGP)

      I2RS: Interface to (2) Routing system.

      Information Model: An abstract model of a conceptual domain,
      independent of a specific implementations or data representation

      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.

      NETCONF: The Network Configuration Protocol

      RESTCONF: The RESTCONF Protocol

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:

   o  configuration,

   o  operational status information per protocol instance,

   o  RPC operations (clear adjacency, clear isis-database), and

   o  notifications events (read-only).

   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



Hares & Wang              Expires May 14, 2015                  [Page 3]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


   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:

   o  an RPC to clear a isis-adjacency within a protocol instance for a
      particular set of interfaces and levels.

   o  an RPC to clear the isis lsdb data base at a particular isis level

   The [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 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:

   o  The nodes of [I-D.wang-i2rs-isis-dm] are mostly read/write.  This
      includes the isis lsp-database and the isis-neighbor lists.  In
      [I-D.litkowski-isis-yang-isis-cfg] status nodes are only readable.

   o  [I-D.wang-i2rs-isis-dm] contains the isis mt-rib which
      [I-D.litkowski-isis-yang-isis-cfg] lacks.



Hares & Wang              Expires May 14, 2015                  [Page 4]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


5.  Unique features for I2RS IGP Requirements

   The following are unique features for I2RS IGP requirements:

   o  mt-ipv4-rib and mt-ipv6-rib - which is used for transient loop
      avoidance.

   o  nbr-list - to aid fast route convergence in the event of the loss
      of a neighbor

   o  route state information for subscribing for notification of route
      changes and neighbor changes

   These I2RS features in [I-D.wang-i2rs-isis-dm] are described in the
   sections below.

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.























Hares & Wang              Expires May 14, 2015                  [Page 5]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


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



Hares & Wang              Expires May 14, 2015                  [Page 6]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


   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

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

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

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



Hares & Wang              Expires May 14, 2015                  [Page 7]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


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", draft-ietf-i2rs-architecture-05 (work in
              progress), July 2014.

   [I-D.ietf-i2rs-rib-info-model]
              Bahadur, N., Folkes, R., Kini, S., and J. Medved, "Routing
              Information Base Info Model", draft-ietf-i2rs-rib-info-
              model-03 (work in progress), May 2014.

   [I-D.ietf-i2rs-usecase-reqs-summary]
              Hares, S. and M. Chen, "Summary of I2RS Use Case
              Requirements", draft-ietf-i2rs-usecase-reqs-summary-00
              (work in progress), November 2014.

   [I-D.litkowski-isis-yang-isis-cfg]
              Litkowski, S., "Yang Data Model for ISIS protocol", draft-
              litkowski-isis-yang-isis-cfg-01 (work in progress), June
              2014.

   [I-D.wang-i2rs-isis-dm]
              Wang, L., Hares, S., and N. Wu, "Yang Data model I2RS to
              IS-IS protocol", draft-wang-i2rs-isis-dm-00 (work in
              progress), September 2014.

   [I-D.wu-i2rs-isis-info-model]
              Wu, N., Wang, L., and S. Hares, "Information model for IS-
              IS protocol", draft-wu-i2rs-isis-info-model-00 (work in
              progress), 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.




Hares & Wang              Expires May 14, 2015                  [Page 8]

Internet-Draft         ospf yang i2rs-cfg Compare          November 2014


   [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


























Hares & Wang              Expires May 14, 2015                  [Page 9]