Re: [Rtg-yang-coord] Clearing all stats in a container

[Alia Atlas <[e-mail]>]

Juergen,

Very good advice.  I think we're all having problems seeing how the
different models clearly connect.  We really need a roadmap of how
the proposed models and needed models will connect.

Regards,
Alia

On Fri, Mar 6, 2015 at 8:22 AM, Juergen Schoenwaelder <
[e-mail]> wrote:

> Hi,
>
> it might help if there is a short description how the various routing
> YANG data models fit together along the lines "this is a generic base
> model", "this is an extension for XYZ of that base model ABC do that",
> "this is an extension for QWE the extension model ASD doing another
> thing", "this is an information model for the data model 123"
> etc. Kind of a roadmap to all the YANG data models and information
> models so that people know how to read through the bits and pieces.
>
> /js
>
> On Fri, Mar 06, 2015 at 08:10:25AM -0500, Susan Hares wrote:
> > Juergen:
> >
> > Very understandable that you are very busy.  We'll do a general call for
> > review on Monday after the Information Model and Data Model have been
> > uploaded.
> >
> > I'll send the call for review to netmod, rtg-yang-coordination, rtrwg,
> and
> > I2RS.
> >
> > Sue
> >
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:[e-mail]
> ]
> > Sent: Friday, March 06, 2015 7:59 AM
> > To: Susan Hares
> > Cc: 'Mahesh Jethanandani'; [e-mail]
> > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container
> >
> > Susan,
> >
> > I am sorry but I can't do this by the I-D deadline. Workload is at its
> > peak everywhere around this time.
> >
> > /js
> >
> > On Fri, Mar 06, 2015 at 07:29:17AM -0500, Susan Hares wrote:
> > > Juergen:
> > >
> > > Thank you for this advice.  If you have time (before the Draft
> deadline)
> > to
> > > look at the grouping of the statistics within the I2RS RIB, and
> provide us
> > > with advice on the groupings - it would be helpful.
> > >
> > > Any other comments on the draft would aid the authors and the I2RS WG.
> > The
> > > authors would like comments sent to them until the IETF draft deadline.
> > > After that, I suspect the I2RS mail is best.
> > >
> > > Sue
> > >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder [mailto:
> [e-mail]]
> > > Sent: Thursday, March 05, 2015 11:16 AM
> > > To: Mahesh Jethanandani
> > > Cc: Susan Hares; [e-mail]
> > > Subject: Re: [Rtg-yang-coord] Clearing all stats in a container
> > >
> > > Hi,
> > >
> > > it was generally found useful when we did the interfaces and ip YANG
> > models
> > > to properly separate config data from state data. And this is not just
> > > counters, it could include other things where operational state can be
> > > different from the configured state.
> > >
> > > /js
> > >
> > > On Thu, Mar 05, 2015 at 08:07:02AM -0800, Mahesh Jethanandani wrote:
> > > > Susan,
> > > >
> > > > Here is an relevant example (I have deleted description fields for
> > > brevity) from ietf-interface YANG module of how one could maintain
> > > statistics in a module. One reason to keep them in a container of their
> > own
> > > is to be able to perform bulk operations on them. Of course, as Juergen
> > > pointed out, clearing stats may not be one of them. But if you wanted
> to
> > say
> > > <get> all the stats on a particular module, you would do a <get> on the
> > > container i.e. statistics in this example, and you would have all the
> > stats.
> > > >
> > > > container interfaces-state {
> > > >     config false;
> > > >
> > > > <snip>
> > > >
> > > >     container statistics {
> > > >         description
> > > >           "A collection of interface-related statistics objects.";
> > > >
> > > >         leaf discontinuity-time {
> > > >           type yang:date-and-time;
> > > >           mandatory true;
> > > >         }
> > > >
> > > >         leaf in-octets {
> > > >           type yang:counter64;
> > > >         }
> > > >
> > > >         leaf in-unicast-pkts {
> > > >           type yang:counter64;
> > > >        }
> > > >
> > > >         leaf in-broadcast-pkts {
> > > >           type yang:counter64;
> > > >        }
> > > >
> > > >        <snip>
> > > >
> > > >         }
> > > >       }
> > > > }
> > > >
> > > > HTH.
> > > >
> > > > > On Mar 5, 2015, at 2:53 AM, Susan Hares <[e-mail]> wrote:
> > > > >
> > > > > Mahesh:
> > > > >
> > > > > Would you post an example of how to put statistic counters into a
> > > container.  We have multiple drafts in I2RS that provide such
> counters.  I
> > > will forward your advice to all authors so they can modify their yang
> > > modules to match the appropriate form.
> > > > >
> > > > > Sue
> > > > >
> > > > > From: Rtg-yang-coord [mailto:[e-mail]] On
> > > > > Behalf Of Mahesh Jethanandani
> > > > > Sent: Thursday, March 05, 2015 1:31 AM
> > > > > To: [e-mail]
> > > > > Subject: [Rtg-yang-coord] Clearing all stats in a container
> > > > >
> > > > > Assuming one has defined stat counters in one container, like
> > > ietf-interfaces has done with its statistics, does anyone have
> suggestions
> > > on how one can essentially clear (reset to 0) all the counters in that
> > > container.
> > > > >
> > > > > Mahesh Jethanandani
> > > > > [e-mail] <mailto:[e-mail]>
> > > > Mahesh Jethanandani
> > > > [e-mail]
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > > > _______________________________________________
> > > > Rtg-yang-coord mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> > >
> > >
> > > --
> > > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > > Fax:   [phone]         <http://www.jacobs-university.de/>
> >
> > >
> > >
> > >
> > >
> > > Network Working Group                                            L.
> Wang
> > > Internet-Draft
> Huawei
> > > Intended status: Standards Track                      H.
> Ananthakrishnan
> > > Expires: September 6, 2015                                 Packet
> Design
> > >                                                                  M.
> Chen
> > >
>  Huawei
> > >                                                                  A.
> Dass
> > >                                                                  S.
> Kini
> > >
>  Ericsson
> > >                                                               N.
> Bahadur
> > >                                                        Bracket
> Computing
> > >                                                           March 05,
> 2015
> > >
> > >
> > >                     Data Model for RIB I2RS protocol
> > >                    draft-wang-i2rs-rib-data-model-01
> > >
> > > Abstract
> > >
> > >    This document defines a YANG data model for Routing Information Base
> > >    (RIB) that aligns with the I2RS RIB information model.
> > >
> > > Requirements Language
> > >
> > >    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 RFC 2119 [RFC2119].
> > >
> > > 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 September 6, 2015.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 1]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > > Copyright Notice
> > >
> > >    Copyright (c) 2015 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  . . . . . . . . . . . . . . . . . . . . . . . .
>  2
> > >      1.1.  Definitions and Acronyms  . . . . . . . . . . . . . . . .
>  3
> > >      1.2.  Tree Diagrams . . . . . . . . . . . . . . . . . . . . . .
>  3
> > >    2.  Model Structure . . . . . . . . . . . . . . . . . . . . . . .
>  3
> > >      2.1.  RIB Capability  . . . . . . . . . . . . . . . . . . . . .
>  5
> > >      2.2.  Routing Instance and Rib  . . . . . . . . . . . . . . . .
>  6
> > >      2.3.  Route . . . . . . . . . . . . . . . . . . . . . . . . . .
>  7
> > >      2.4.  Nexthop . . . . . . . . . . . . . . . . . . . . . . . . .
>  8
> > >      2.5.  Notifications . . . . . . . . . . . . . . . . . . . . . .
> 11
> > >    3.  YANG Modules  . . . . . . . . . . . . . . . . . . . . . . . .
> 13
> > >    4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .
> 36
> > >    5.  Security Considerations . . . . . . . . . . . . . . . . . . .
> 36
> > >    6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .
> 36
> > >      6.1.  Normative References  . . . . . . . . . . . . . . . . . .
> 36
> > >      6.2.  Informative References  . . . . . . . . . . . . . . . . .
> 36
> > >    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .
> 37
> > >
> > > 1.  Introduction
> > >
> > >    The Interface to the Routing System (I2RS)
> > >    [I-D.ietf-i2rs-architecture] provides read and write access to the
> > >    information and state within the routing process that exists inside
> > >    the routing elements, this is achieved via the protocol message
> > >    exchange between I2RS clients and I2RS agents associated with the
> > >    routing system.  One of the functions of I2RS is to read and write
> > >    data of Routing Information Base (RIB).
> > >    [I-D.ietf-i2rs-usecase-reqs-summary] introduces a set of RIB use
> > >    cases and the RIB information model is defined in
> > >    [I-D.ietf-i2rs-rib-info-model].
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 2]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    This document defines a YANG [RFC6020][RFC6021] data model for the
> > >    RIB that satisfies the RIB use cases and aligns with the RIB
> > >    information model.
> > >
> > > 1.1.  Definitions and Acronyms
> > >
> > >    RIB: Routing Information Base
> > >
> > >    Information Model (IM): An abstract model of a conceptual domain,
> > >    independent of a specific implementation or data representation.
> > >
> > > 1.2.  Tree Diagrams
> > >
> > >    A simplified graphical representation of the data model is used in
> > >    this document.  The meaning of the symbols in these diagrams is as
> > >    follows:
> > >
> > >    o  Brackets "[" and "]" enclose list keys.
> > >
> > >    o  Abbreviations before data node names: "rw" means configuration
> > >       (read-write) and "ro" state data (read-only).
> > >
> > >    o  Symbols after data node names: "?" means an optional node and "*"
> > >       denotes a "list" and "leaf-list".
> > >
> > >    o  Parentheses enclose choice and case nodes, and case nodes are
> also
> > >       marked with a colon (":").
> > >
> > >    o  Ellipsis ("...") stands for contents of subtrees that are not
> > >       shown.
> > >
> > > 2.  Model Structure
> > >
> > >    The following figure shows an overview of structure tree of the
> i2rs-
> > >    rib module.  To give a whole view of the structure tree, some
> details
> > >    of the tree are omitted.  The detail are introduced in the following
> > >    sub-sections.
> > >
> > >       module: i2rs-rib
> > >          +--rw nexthop-capacity
> > >          |  ...
> > >          +--rw nexthop-tunnel-encap-capacity
> > >          |  ...
> > >          +--rw routing-instance-list* [instance-name]
> > >             +--rw instance-name     string
> > >             +--rw interface-list* [name]
> > >             |  +--rw name        if:interface-ref
> > >             +--rw router-id?        yang:dotted-quad
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 3]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >             +--rw rib-list* [rib-name]
> > >                +--rw rib-name               string
> > >                +--rw rib-family             rib-family-def
> > >                +--rw enable-ip-rpf-check?        boolean
> > >                +--rw route-list* [route-index]
> > >                   +--rw route-index                uint64
> > >                   +--rw route-type                 route-type-def
> > >                   +--rw match
> > >                   |  +--rw (rib-route-type)?
> > >                   |     +--:(ipv4)
> > >                   |     |  ...
> > >                   |     +--:(ipv6)
> > >                   |     |  ...
> > >                   |     +--:(mpls-route)
> > >                   |     |  ...
> > >                   |     +--:(mac-route)
> > >                   |     |  ...
> > >                   |     +--:(interface-route)
> > >                   |        ...
> > >                   +--rw nexthop
> > >                   |  +--rw nexthop-id           uint32
> > >                   |  +--rw (nexthop-type)?
> > >                   |     +--:(nexthop-base)
> > >                   |     |  ...
> > >                   |     +--:(nexthop-primary-standby)
> > >                   |     |  ...
> > >                   |     +--:(nexthop-load-balance)
> > >                   |     |  ...
> > >                   |     +--:(nexthop-replicate)
> > >                   |        ...
> > >                   +--rw route-statistic
> > >                   |  ...
> > >                   +--rw route-attributes
> > >                   |  +--rw route-preference           uint32
> > >                   |  +--rw local-only                 boolean
> > >                   |  +--rw address-family-route-attributes
> > >                   |     +--rw (route-type)?
> > >                   |        +--:(ip-route-attributes)
> > >                   |        +--:(mpls-route-attributes)
> > >                   |        +--:(eThernet-route-attributes)
> > >                   +--rw route-vendor-attributes
> > >       notifications:
> > >          +---n nexthop-resolution-status-change
> > >          |  +--ro nexthop
> > >          |  |  +--ro nexthop-id           uint32
> > >          |  |  +--ro (nexthop-type)?
> > >          |  |     +--:(nexthop-base)
> > >          |  |     |  ...
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 4]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >          |  |     +--:(nexthop-primary-standby)
> > >          |  |     |  ...
> > >          |  |     +--:(nexthop-load-balance)
> > >          |  |     |  ...
> > >          |  |     +--:(nexthop-replicate)
> > >          |  |        ...
> > >          |  +--ro nexthop-state        nexthop-state-def
> > >          +---n route-change
> > >             +--ro instance-name            string
> > >             +--ro rib-name                 string
> > >             +--ro rib-family               rib-family-def
> > >             +--ro route-index              uint64
> > >             +--ro route-type               route-type-def
> > >             +--ro match
> > >             |  +--ro (rib-route-type)?
> > >             |     +--:(ipv4)
> > >             |     |  ...
> > >             |     +--:(ipv6)
> > >             |     |  ...
> > >             |     +--:(mpls-route)
> > >             |     |  +--ro mpls-label              uint32
> > >             |     +--:(mac-route)
> > >             |     |  +--ro mac-address             uint32
> > >             |     +--:(interface-route)
> > >             |        +--ro interface-identifier if:interface-ref
> > >             +--ro route-installed-state route-installed-state-def
> > >             +--ro route-state           route-state-def
> > >             +--ro route-reason          route-reason-def
> > >
> > >                   Figure 1 Overview of I2RS module
> > >
> > > 2.1.  RIB Capability
> > >
> > >    RIB capability negotiation is very important because not all of the
> > >    hardware will be able to support all kinds of nexthops and there
> > >    should be a limitation on how many levels of lookup can be
> > >    practically performed.  Therefore, a RIB data model MUST specify a
> > >    way for an external entity to learn about the functional
> capabilities
> > >    of a network device.
> > >
> > >    At the same time, nexthop chains can be used to specify multiple
> > >    headers over a packet, before that particular packet is forwarded.
> > >    Not every network device will be able to support all kinds of
> nexthop
> > >    chains along with the arbitrary number of headers which are chained
> > >    together.  The RIB data model MUST provide a way to expose the
> > >    nexthop chaining capability supported by a given network device.
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 5]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    The structure of the next-hop-capacity and the nexthop-tunnel-encap-
> > >    capacity is shown in the following figure:
> > >
> > >    Editor Notes: this version only includes the nexthop-hop and
> nexthop-
> > >    tunnel-encap capabilities, there may also need to define RIB
> > >    capabilities in future revision.
> > >
> > >       +--rw nexthop-capacity
> > >       |  +--rw support-tunnel?         boolean
> > >       |  +--rw support-chains?         boolean
> > >       |  +--rw support-list-of-list?   boolean
> > >       |  +--rw support-replication?    boolean
> > >       |  +--rw support-weighted?       boolean
> > >       |  +--rw support-protection?     boolean
> > >       |  +--rw lookup-limit?           uint8
> > >       +--rw nexthop-tunnel-encap-capacity
> > >       |  +--rw support-ipv4?    boolean
> > >       |  +--rw support-ipv6?    boolean
> > >       |  +--rw support-mpls?    boolean
> > >       |  +--rw support-gre?     boolean
> > >       |  +--rw support-ipsec?   boolean
> > >       |  +--rw support-vxlan?   boolean
> > >       |  +--rw support-nvgre?   boolean
> > >
> > >              Figure 2 RIB Capability
> > >
> > > 2.2.  Routing Instance and Rib
> > >
> > >    A routing instance, in the context of the RIB information model, is
> a
> > >    collection of RIBs, interfaces, and routing protocol parameters.  A
> > >    routing instance creates a logical slice of the router and can allow
> > >    multiple different logical slices; across a set of routers; to
> > >    communicate with each other.  And the routing protocol parameters
> > >    control the information available in the RIBs.  More detail about
> > >    routing instance can be found in Section 2.2 of
> > >    [I-D.ietf-i2rs-rib-info-model].
> > >
> > >    As described in [I-D.ietf-i2rs-rib-info-model], there will be
> > >    multiple routing instances for a router.  At the same time, for a
> > >    routing instance, there would be multiple RIBs as well.  Therefore,
> > >    this model uses "list" to express the routing instances and ribs.
> > >    The structure tree is shown as following figure.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 6]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    +--rw routing-instance-list* [instance-name]
> > >          +--rw instance-name     string
> > >          +--rw interface-list* [name]
> > >          |  +--rw name        if:interface-ref
> > >          +--rw router-id?        yang:dotted-quad
> > >          +--rw rib-list* [rib-name]
> > >             +--rw rib-name               string
> > >             +--rw rib-family             rib-family-def
> > >             +--rw enable-ip-rpf-check?   boolean
> > >             +--rw route-list* [route-index]
> > >                ... (refer to sec.2.3)
> > >
> > >              Figure 3 Routing Instance
> > >
> > > 2.3.  Route
> > >
> > >    A route is essentially a match condition and an action following
> that
> > >    match.  The match condition specifies the kind of route (e.g., IPv4,
> > >    MPLS, MAC, Interface etc.) and the set of fields to match on.
> > >
> > >    According to the definition in [I-D.ietf-i2rs-rib-info-model], a
> > >    route MUST associate with the following attributes:
> > >
> > >    o  ROUTE_PREFERENCE: See Section 2.3 of
> > >       [I-D.ietf-i2rs-rib-info-model].
> > >
> > >    o  ACTIVE: Indicates whether a route is fully resolved and is a
> > >       candidate for selection.
> > >
> > >    o  INSTALLED: Indicates whether the route got installed in the FIB.
> > >
> > >    In addition, a route can associate with one or more optional route
> > >    attributes(e.g., route-vendor-attributes).
> > >
> > >    For a RIB, there will have a number of routes, so the routes are
> > >    expressed as a list under the rib list.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 7]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >  +--rw route-list* [route-index]
> > >     +--rw route-index                uint64
> > >     +--rw route-type                 route-type-def
> > >     +--rw match
> > >     |  +--rw (rib-route-type)?
> > >     |     +--:(ipv4)
> > >     |     |  +--rw ipv4
> > >     |     |     +--rw ipv4-route-type
> ip-route-type-def
> > >     |     |     +--rw (ip-route-type)?
> > >     |     |        +--:(destination-ipv4-address)
> > >     |     |        |  +--rw destination-ipv4-prefix inet:ipv4-prefix
> > >     |     |        +--:(source-ipv4-address)
> > >     |     |        |  +--rw source-ipv4-prefix         inet:ipv4-prefix
> > >     |     |        +--:(destination-source-ipv4-address)
> > >     |     |           +--rw destination-source-ipv4-address
> > >     |     |              +--rw destination-ipv4-prefix inet:ipv4-prefix
> > >     |     |              +--rw source-ipv4-prefix inet:ipv4-prefix
> > >     |     +--:(ipv6)
> > >     |     |  +--rw ipv6
> > >     |     |     +--rw ipv6-route-type
> ip-route-type-def
> > >     |     |     +--rw (ip-route-type)?
> > >     |     |        +--:(destination-ipv6-address)
> > >     |     |        |  +--rw destination-ipv6-prefix inet:ipv6-prefix
> > >     |     |        +--:(source-ipv6-address)
> > >     |     |        |  +--rw source-ipv6-prefix        inet:ipv6-prefix
> > >     |     |        +--:(destination-source-ipv6-address)
> > >     |     |           +--rw destination-source-ipv6-address
> > >     |     |              +--rw destination-ipv6-prefix inet:ipv6-prefix
> > >     |     |              +--rw source-ipv6-prefix inet:ipv6-prefix
> > >     |     +--:(mpls-route)
> > >     |     |  +--rw mpls-label              uint32
> > >     |     +--:(mac-route)
> > >     |     |  +--rw mac-address             uint32
> > >     |     +--:(interface-route)
> > >     |        +--rw interface-identifier        if:interface-ref
> > >     +--rw nexthop
> > >        ... (refer to sec.2.4)
> > >
> > >                 Figure 4 Route
> > >
> > > 2.4.  Nexthop
> > >
> > >    A nexthop represents an object resulting from a route lookup.  The
> > >    detail information of nexthop is defined in Section 2.4 of
> > >    [I-D.ietf-i2rs-rib-info-model].  Currently, four types of nexthop
> are
> > >    defined.
> > >
> > >    o  base
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 8]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    o  load-balance: design for load-balance case.
> > >
> > >    o  primary-standby: designed for protection scenario where it
> > >       normally will have primary and standby nexthop.
> > >
> > >    o  replicate: designed for multiple destinations forwarding.
> > >
> > >    To support some complex use cases (e.g., multicast with load-balance
> > >    and/or protection), the nexthop is defined in the way of recursion.
> > >
> > >    The structure tree of nexthop is shown in the following figures.
> > >
> > >       +--rw nexthop
> > >       |  +--rw nexthop-id           uint32
> > >       |  +--rw (nexthop-type)?
> > >       |     +--:(nexthop-base)
> > >       |     |  +--rw nexthop-base
> > >       |     |     +--rw nexthop-chain* [nexthop-chain-id]
> > >       |     |        +--rw nexthop-chain-id        uint32
> > >       |     |        +--rw (nexthop-chain-type)?
> > >       |     |              ... (refer to Figure 6)
> > >       |     +--:(nexthop-primary-standby)
> > >       |     |  +--rw nexthop-ps
> > >       |     |     +--rw nexthop-primary        nexthop-ref
> > >       |     |     +--rw nexthop-standby        nexthop-ref
> > >       |     +--:(nexthop-load-balance)
> > >       |     |  +--rw nexthop-lb
> > >       |     |     +--rw nexthop-lbs* [nexthop-lbs-id]
> > >       |     |        +--rw nexthop-lbs-id        uint32
> > >       |     |        +--rw nhop-lb-weight        nhop-lb-weight-def
> > >       |     |        +--rw nexthop-lb-member        nexthop-ref
> > >       |     +--:(nexthop-replicate)
> > >       |        +--rw nexthop-replicate
> > >       |           +--rw nexthop-replicates* [nexthop-replicates-id]
> > >       |              +--rw nexthop-replicates-id        uint32
> > >       |              +--rw nexthop-replicate?        nexthop-ref
> > >
> > >                   Figure 5 Nexhop
> > >
> > >    Figure 6 (as shown blow) is a sub-tree of nexthop, it's under the
> > >    nexthop chain node.
> > >
> > >    +--rw (nexthop-chain-type)?
> > >       +--:(nexthop-chain-member-special)
> > >       |  +--rw nexthop-chain-member-special
> > >       |     +--rw nexthop-chain-member-special? special-nexthop-def
> > >       +--:(nexthop-chain-member-identifier)
> > >       |  +--rw (nexthop-identifier-type)?
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015               [Page
> 9]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >       |     +--:(nexthop-chain-name)
> > >       |     |  +--rw nexthop-chain-name         string
> > >       |     +--:(nexthop-chain-id)
> > >       |        +--rw nexthop-chain-id           uint32
> > >       +--:(egress-interface-next-hop)
> > >       |  +--rw outgoing-interface               if:interface-ref
> > >       +--:(ipv4-address-next-hop)
> > >       |  +--rw next-hop-ipv4-address            inet:ipv4-address
> > >       +--:(ipv6-address-next-hop)
> > >       |  +--rw next-hop-ipv6-address            inet:ipv6-address
> > >       +--:(egress-interface-ipv4-next-hop)
> > >       |  +--rw next-hop-egress-interface-ipv4-address
> > >       |     +--rw outgoing-interface            if:interface-ref
> > >       |     +--rw next-hop-egress-ipv4-address inet:ipv4-address
> > >       +--:(egress-interface-ipv6-next-hop)
> > >       |  +--rw next-hop-egress-interface-ipv6-address
> > >       |     +--rw outgoing-interface           if:interface-ref
> > >       |     +--rw next-hop-egress-ipv6-address inet:ipv4-address
> > >       +--:(egress-interface-mac-next-hop)
> > >       |  +--rw next-hop-egress-interface-mac-address
> > >       |     +--rw outgoing-interface        if:interface-ref
> > >       |     +--rw ieee-mac-address          uint32
> > >       +--:(tunnel-encap-next-hop)
> > >       |  +--rw tunnel-encap
> > >       |     +--rw (tunnel-type)?
> > >       |     |  +--:(ipv4)
> > >       |     |  |  +--rw source-ipv4-address inet:ipv4-address
> > >       |     |  |  +--rw destination-ipv4-address inet:ipv4-address
> > >       |     |  |  +--rw protocol                 uint8
> > >       |     |  |  +--rw ttl?                     uint8
> > >       |     |  |  +--rw dscp?                    uint8
> > >       |     |  +--:(ipv6)
> > >       |     |  |  +--rw source-ipv6-address inet:ipv6-address
> > >       |     |  |  +--rw destination-ipv6-address inet:ipv6-address
> > >       |     |  |  +--rw next-header              uint8
> > >       |     |  |  +--rw traffic-class?           uint8
> > >       |     |  |  +--rw flow-label?              uint16
> > >       |     |  |  +--rw hop-limit?               uint8
> > >       |     |  +--:(mpls)
> > >       |     |  |  +--rw (mpls-action-type)?
> > >       |     |  |     +--:(mpls-push)
> > >       |     |  |     |  +--rw mpls-push          boolean
> > >       |     |  |     |  +--rw mpls-label         uint32
> > >       |     |  |     |  +--rw s-bit?             boolean
> > >       |     |  |     |  +--rw tos-value?         uint8
> > >       |     |  |     |  +--rw ttl-value?         uint8
> > >       |     |  |     +--:(mpls-pop)
> > >       |     |  |        +--rw mpls-pop           boolean
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 10]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >       |     |  |        +--rw ttl-action?        uint8
> > >       |     |  +--:(gre)
> > >       |     |  |  +--rw gre-ip-destination        inet:ipv4-address
> > >       |     |  |  +--rw gre-protocol-type         inet:ipv4-address
> > >       |     |  |  +--rw gre-key?                  uint64
> > >       |     |  +--:(ipsec)
> > >       |     |  |  +--rw ipsec-spi                 uint32
> > >       |     |  |  +--rw ipsec-sequence-number        uint32
> > >       |     |  +--:(nvgre)
> > >       |     |     +--rw (nvgre-type)?
> > >       |     |     |  +--:(ipv4)
> > >       |     |     |  |  +--rw source-ipv4-address inet:ipv4-address
> > >       |     |     |  |  +--rw destination-ipv4-address
> inet:ipv4-address
> > >       |     |     |  |  +--rw protocol                 uint8
> > >       |     |     |  |  +--rw ttl?                     uint8
> > >       |     |     |  |  +--rw dscp?                    uint8
> > >       |     |     |  +--:(ipv6)
> > >       |     |     |     +--rw source-ipv6-address inet:ipv6-address
> > >       |     |     |     +--rw destination-ipv6-address
> inet:ipv6-address
> > >       |     |     |     +--rw next-header              uint8
> > >       |     |     |     +--rw traffic-class?           uint8
> > >       |     |     |     +--rw flow-label?              uint16
> > >       |     |     |     +--rw hop-limit?               uint8
> > >       |     |     +--rw virtual-subnet-id           uint32
> > >       |     |     +--rw flow-id?                    uint16
> > >       |     +--rw outgoing-interface?         string
> > >       +--:(logical-tunnel-next-hop)
> > >       |  +--rw logical-tunnel
> > >       |     +--rw tunnel-type        tunnel-type-def
> > >       |     +--rw tunnel-name        string
> > >       +--:(rib-name)
> > >           +--rw rib-name?                             string
> > >
> > >                   Figure 6 Nexthop Chain
> > >
> > > 2.5.  Notifications
> > >
> > >    Asynchronous notifications are sent by the RIB manager of a network
> > >    device to an external entity when some event triggers on the network
> > >    device.  A RIB data-model MUST support sending 2 kind of
> asynchronous
> > >    notifications.
> > >
> > >    1.  Route change notification:
> > >
> > >    o Installed (Indicates whether the route got installed in the FIB) ;
> > >
> > >    o Active (Indicates whether a route is fully resolved and is a
> > >    candidate for selection) ;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 11]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    o Reason - E.g.  Not authorized
> > >
> > >    2.  Nexthop resolution status notification
> > >
> > >    Nexthops can be fully resolved nexthops or an unresolved nexthop.
> > >
> > >    A resolved nexthop has adequate level of information to send the
> > >    outgoing packet towards the destination by forwarding it on an
> > >    interface of a directly connected neighbor.
> > >
> > >    An unresolved nexthop is something that requires the RIB manager to
> > >    determine the final resolved nexthop.  For example, in a case when a
> > >    nexthop could be an IP address.  The RIB manager would resolve how
> to
> > >    reach that IP address, e.g. by checking if that particular IP is
> > >    address reachable by regular IP forwarding or by a MPLS tunnel or by
> > >    both.  If the RIB manager cannot resolve the nexthop, then the
> > >    nexthop remains in an unresolved state and is NOT a suitable
> > >    candidate for installation in the FIB.
> > >
> > >    The structure tree of notifications is shown in the following
> figure.
> > >
> > >    notifications:
> > >       +---n nexthop-resolution-status-change
> > >       |  +--ro nexthop
> > >       |  |  +--ro nexthop-id           uint32
> > >       |  |  +--ro (nexthop-type)?
> > >       |  |     +--:(nexthop-base)
> > >       |  |     |  +--ro nexthop-base
> > >       |  |     |     +--ro nexthop-chain* [nexthop-chain-id]
> > >       |  |     |        +--ro nexthop-chain-id     uint32
> > >       |  |     |        +--ro (nexthop-chain-type)?
> > >       |  |     |           ...
> > >       |  |     +--:(nexthop-primary-standby)
> > >       |  |     |  +--ro nexthop-ps
> > >       |  |     |     +--ro nexthop-primary     nexthop-ref
> > >       |  |     |     +--ro nexthop-standby     nexthop-ref
> > >       |  |     +--:(nexthop-load-balance)
> > >       |  |     |  +--ro nexthop-lb
> > >       |  |     |     +--ro nexthop-lbs* [nexthop-lbs-id]
> > >       |  |     |        +--ro nexthop-lbs-id       uint32
> > >       |  |     |        +--ro nhop-lb-weight     nhop-lb-weight-def
> > >       |  |     |        +--ro nexthop-lb-member nexthop-ref
> > >       |  |     +--:(nexthop-replicate)
> > >       |  |        +--ro nexthop-replicate
> > >       |  |           +--ro nexthop-replicates* [nexthop-replicates-id]
> > >       |  |              +--ro nexthop-replicates-id     uint32
> > >       |  |              +--ro nexthop-replicate?       nexthop-ref
> > >       |  +--ro nexthop-state     nexthop-state-def
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 12]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >       +---n route-change
> > >          +--ro instance-name            string
> > >          +--ro rib-name                 string
> > >          +--ro rib-family               rib-family-def
> > >          +--ro route-index              uint64
> > >          +--ro route-type               route-type-def
> > >          +--ro match
> > >          |  +--ro (rib-route-type)?
> > >          |     +--:(ipv4)
> > >          |     |  +--ro ipv4
> > >          |     |     ...
> > >          |     +--:(ipv6)
> > >          |     |  +--ro ipv6
> > >          |     |     ...
> > >          |     +--:(mpls-route)
> > >          |     |  +--ro mpls-label              uint32
> > >          |     +--:(mac-route)
> > >          |     |  +--ro mac-address             uint32
> > >          |     +--:(interface-route)
> > >          |        +--ro interface-identifier if:interface-ref
> > >          +--ro route-installed-state route-installed-state-def
> > >          +--ro route-state              route-state-def
> > >          +--ro route-reason             route-reason-def
> > >
> > >                     Figure 7 Notifications
> > >
> > > 3.  YANG Modules
> > >
> > > //<code begins> file "i2rs [e-mail]"
> > >
> > > module i2rs-rib {
> > >   namespace "urn:TBD1:params:xml:ns:yang:rt:i2rs:rib";
> > >     // replace with iana namespace when assigned
> > >     prefix "i2rs-rib";
> > >
> > >   import ietf-inet-types {
> > >     prefix inet;
> > >     //rfc6991
> > >   }
> > >
> > >   import ietf-interfaces {
> > >     prefix "if";
> > >   }
> > >
> > >   import ietf-routing {
> > >     prefix "rt";
> > >   }
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 13]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >   organization
> > >     "TBD2";
> > >   contact
> > >      "email: [e-mail]
> > >       email: [e-mail]
> > >       email: [e-mail]
> > >       email: [e-mail]
> > >       email: [e-mail]
> > >       email: [e-mail]"quot;;
> > >
> > >   description
> > >     "
> > >       terms and acronyms
> > >
> > >       isis (isis):intermediate system to intermediate system
> > >
> > >       ip (ip): internet protocol
> > >
> > >       ipv4 (ipv4):internet protocol version 4
> > >
> > >       ipv6 (ipv6): internet protocol version 6
> > >
> > >       metric(metric): multi exit discriminator
> > >
> > >       igp (igp): interior gateway protocol
> > >
> > >       mtu (mtu) maximum transmission uint
> > >      ";
> > >
> > >
> > >   revision "2015-03-04" {
> > >     description "initial revision";
> > >     reference "draft-ietf-i2rs-rib-info-model-06";
> > >   }
> > >
> > >
> > >   container nexthop-capacity{
> > >     leaf support-tunnel{
> > >       type boolean;
> > >     }
> > >     leaf support-chains{
> > >       type boolean;
> > >     }
> > >     leaf support-list-of-list{
> > >       type boolean;
> > >     }
> > >     leaf support-replication{
> > >       type boolean;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 14]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     }
> > >     leaf support-weighted{
> > >       type boolean;
> > >     }
> > >     leaf support-protection{
> > >       type boolean;
> > >     }
> > >     leaf lookup-limit{
> > >       type uint8;
> > >     }
> > >   }
> > >
> > >
> > >   container nexthop-tunnel-encap-capacity{
> > >     leaf support-ipv4{
> > >       type boolean;
> > >     }
> > >     leaf support-ipv6{
> > >       type boolean;
> > >     }
> > >     leaf support-mpls{
> > >       type boolean;
> > >     }
> > >     leaf support-gre{
> > >       type boolean;
> > >     }
> > >     leaf support-ipsec{
> > >       type boolean;
> > >     }
> > >     leaf support-vxlan{
> > >       type boolean;
> > >     }
> > >     leaf support-nvgre{
> > >       type boolean;
> > >     }
> > >   }
> > >
> > >   list routing-instance-list{
> > >     description
> > >       "configuration of a 'i2rs' pseudo-protocol instance
> > >         consists of a list of routes.";
> > >     key "instance-name";
> > >     leaf instance-name {
> > >       description
> > >         "A routing instance is identified by its name,
> > >         INSTANCE_name.  This MUST be unique across all routing
> instances
> > >         in a given network device.";
> > >       type string ;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 15]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >       mandatory true;
> > >     }
> > >     list interface-list {
> > >       description
> > >         "This represents the list of interfaces associated
> > >         with this routing instance.  The interface list helps constrain
> > >         the boundaries of packet forwarding.  Packets coming on these
> > >         interfaces are directly associated with the given routing
> > >         instance.  The interface list contains a list of identifiers,
> > >         with each identifier uniquely identifying an interface.";
> > >       key "name";
> > >       leaf name {
> > >         type if:interface-ref;
> > >          description
> > >          "A reference to The name of a configured network layer
> > >          interface.";
> > >       }
> > >     }
> > >     uses rt:router-id ;
> > >     list rib-list {
> > >       description
> > >         "This is the list of RIBs associated with this routing
> > >         instance.  Each routing instance can have multiple RIBs to
> > >         represent routes of different types.";
> > >       key "rib-name";
> > >       leaf rib-name {
> > >         description
> > >          "A reference to The name of a rib.";
> > >        type string;
> > >         mandatory true;
> > >       }
> > >       leaf rib-family {
> > >         type rib-family-def;
> > >         mandatory true;
> > >       }
> > >       leaf enable-ip-rpf-check {
> > >         description
> > >           "Each RIB can be optionally associated with a
> > >            ENABLE_IP_RPF_CHECK attribute that enables Reverse
> > >            path forwarding (RPF) checks on all IP routes in that
> > >            RIB.  Reverse path forwarding (RPF) check is used to
> > >            prevent spoofing and limit malicious traffic.";
> > >         type boolean;
> > >       }
> > >       list route-list{
> > >         key "route-index";
> > >         uses route;
> > >       }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 16]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     }
> > >   }
> > >
> > >   grouping route-prefix{
> > >     description
> > >       "The common attributes used for all routes";
> > >     leaf route-index {
> > >       type uint64 ;
> > >       mandatory true;
> > >     }
> > >     leaf route-type {
> > >       type route-type-def ;
> > >       mandatory true;
> > >     }
> > >     container match {
> > >       choice rib-route-type {
> > >         case ipv4 {
> > >           description
> > >             "Match on destination IP address in the IPv4 header";
> > >           container ipv4{
> > >             leaf ipv4-route-type {
> > >               type ip-route-type-def ;
> > >               mandatory true;
> > >             }
> > >             choice ip-route-type {
> > >
> > >               case destination-ipv4-address {
> > >                 leaf destination-ipv4-prefix {
> > >                   type inet:ipv4-prefix;
> > >                   mandatory true;
> > >                 }
> > >               }
> > >               case source-ipv4-address {
> > >                 leaf source-ipv4-prefix {
> > >                   type inet:ipv4-prefix;
> > >                   mandatory true;
> > >                 }
> > >               }
> > >               case destination-source-ipv4-address {
> > >                 container destination-source-ipv4-address {
> > >                   leaf destination-ipv4-prefix {
> > >                     type inet:ipv4-prefix;
> > >                     mandatory true;
> > >                   }
> > >                   leaf source-ipv4-prefix {
> > >                     type inet:ipv4-prefix;
> > >                     mandatory true;
> > >                   }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 17]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >                 }
> > >               }
> > >             }
> > >           }
> > >         }
> > >         case ipv6 {
> > >           description
> > >             "Match on destination IP address in the IPv6 header";
> > >           container ipv6{
> > >             leaf ipv6-route-type {
> > >               type ip-route-type-def ;
> > >               mandatory true;
> > >             }
> > >             choice ip-route-type {
> > >               case destination-ipv6-address {
> > >                 leaf destination-ipv6-prefix {
> > >                   type inet:ipv6-prefix;
> > >                   mandatory true;
> > >                 }
> > >               }
> > >               case source-ipv6-address {
> > >                 leaf source-ipv6-prefix {
> > >                   type inet:ipv6-prefix;
> > >                   mandatory true;
> > >                 }
> > >               }
> > >               case destination-source-ipv6-address {
> > >                 container destination-source-ipv6-address {
> > >                   leaf destination-ipv6-prefix {
> > >                     type inet:ipv6-prefix;
> > >                     mandatory true;
> > >                   }
> > >                   leaf source-ipv6-prefix {
> > >                     type inet:ipv6-prefix;
> > >                     mandatory true;
> > >                   }
> > >                 }
> > >               }
> > >             }
> > >           }
> > >         }
> > >         case mpls-route {
> > >           description
> > >             "Match on a MPLS label at the top of the MPLS label stack";
> > >           leaf mpls-label {
> > >             type uint32 ;
> > >             mandatory true;
> > >           }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 18]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >         }
> > >
> > >         case mac-route {
> > >           description
> > >             "Match on MAC destination addresses in the ethernet
> header";
> > >           leaf mac-address {
> > >             type uint32 ;
> > >             mandatory true;
> > >           }
> > >         }
> > >         case interface-route {
> > >           description
> > >             "Match on incoming interface of the packet";
> > >           leaf interface-identifier {
> > >             type if:interface-ref;
> > >             mandatory true;
> > >           }
> > >         }
> > >       }
> > >     }
> > >   }
> > >
> > >   grouping route
> > >   {
> > >     description
> > >       "The common attributes usesd for all routes";
> > >     uses route-prefix;
> > >     container nexthop
> > >     {
> > >       uses nexthop;
> > >     }
> > >     container route-statistic{
> > >       leaf route-state {
> > >         type route-state-def ;
> > >         config false;
> > >       }
> > >       leaf route-installed-state {
> > >         type route-installed-state-def ;
> > >         config false;
> > >       }
> > >       leaf route-reason {
> > >         type route-reason-def ;
> > >         config false;
> > >       }
> > >     }
> > >     container route-attributes{
> > >       uses route-attributes;
> > >     }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 19]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     container route-vendor-attributes{
> > >       uses route-vendor-attributes;
> > >     }
> > >   }
> > >
> > >   typedef nexthop-ref {
> > >     type leafref {
> > >       path  "/i2rs-rib:routing-instance-list/i2rs-rib:rib-list
> > >
> /i2rs-rib:route-list/i2rs-rib:nexthop/i2rs-rib:nexthop-id";
> > >
> > >     }
> > >   }
> > >
> > >   grouping nexthop {
> > >     leaf nexthop-id {
> > >       mandatory true;
> > >       type uint32;
> > >     }
> > >     choice nexthop-type {
> > >       case nexthop-base {
> > >         container nexthop-base {
> > >           list nexthop-chain {
> > >             key "nexthop-chain-id";
> > >             uses nexthop-chain-member;
> > >           }
> > >         }
> > >       }
> > >
> > >       case nexthop-primary-standby {
> > >         container nexthop-ps {
> > >            leaf nexthop-primary {
> > >              mandatory true;
> > >              type nexthop-ref;
> > >            }
> > >            leaf nexthop-standby {
> > >              mandatory true;
> > >              type nexthop-ref;
> > >            }
> > >         }
> > >       }
> > >
> > >       case nexthop-load-balance {
> > >         container nexthop-lb {
> > >           list nexthop-lbs {
> > >             key "nexthop-lbs-id";
> > >             leaf nexthop-lbs-id {
> > >               mandatory true;
> > >               type uint32;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 20]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >             }
> > >             leaf nhop-lb-weight {
> > >               mandatory true;
> > >               type nhop-lb-weight-def;
> > >             }
> > >             leaf nexthop-lb-member {
> > >               mandatory true;
> > >               type nexthop-ref;
> > >             }
> > >           }
> > >         }
> > >       }
> > >
> > >       case nexthop-replicate {
> > >         container nexthop-replicate {
> > >           list nexthop-replicates{
> > >             key "nexthop-replicates-id";
> > >             leaf nexthop-replicates-id {
> > >               mandatory true;
> > >               type uint32;
> > >             }
> > >             leaf nexthop-replicate {
> > >               type nexthop-ref;
> > >             }
> > >           }
> > >         }
> > >       }
> > >     }
> > >   }
> > >
> > >   grouping nexthop-chain-member {
> > >     description
> > >       "One Nexthop content for routes.";
> > >     leaf nexthop-chain-id{
> > >       type uint32;
> > >       mandatory true;
> > >     }
> > >     choice nexthop-chain-type {
> > >       case nexthop-chain-member-special {
> > >         container nexthop-chain-member-special {
> > >           leaf nexthop-chain-member-special{
> > >             type special-nexthop-def;
> > >           }
> > >         }
> > >       }
> > >
> > >       case nexthop-chain-member-identifier{
> > >         uses nexthop-chain-member-identifier;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 21]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >       }
> > >
> > >       case egress-interface-next-hop {
> > >          description
> > >            "Simple next-hop is specified as an outgoing interface,
> > >             next-hop address or both.";
> > >          leaf outgoing-interface {
> > >            type if:interface-ref;
> > >            mandatory true;
> > >            description
> > >              "Name of The outgoing interface.";
> > >          }
> > >       }
> > >
> > >       case ipv4-address-next-hop {
> > >         leaf next-hop-ipv4-address {
> > >           type inet:ipv4-address;
> > >           mandatory true;
> > >           description
> > >             "Ipv4 address of The next-hop.";
> > >         }
> > >       }
> > >
> > >       case ipv6-address-next-hop {
> > >         leaf next-hop-ipv6-address {
> > >           type inet:ipv6-address;
> > >           mandatory true;
> > >           description
> > >             "Ipv6 address of The next-hop.";
> > >         }
> > >       }
> > >
> > >       case egress-interface-ipv4-next-hop {
> > >         container next-hop-egress-interface-ipv4-address{
> > >           leaf outgoing-interface {
> > >             type if:interface-ref;
> > >             mandatory true;
> > >             description    "Name of The outgoing interface.";
> > >           }
> > >           leaf next-hop-egress-ipv4-address {
> > >             type inet:ipv4-address;
> > >             mandatory true;
> > >             description
> > >               "Ipv4 address of The next-hop.";
> > >           }
> > >           description
> > >             "Egress-interface and ip address: This can be usesd
> > >              in cases e.g.where The ip address is a link-local
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 22]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >              address.";
> > >         }
> > >       }
> > >
> > >       case egress-interface-ipv6-next-hop {
> > >         container next-hop-egress-interface-ipv6-address{
> > >           leaf outgoing-interface {
> > >             type if:interface-ref;
> > >             mandatory true;
> > >             description    "Name of The outgoing interface.";
> > >           }
> > >           leaf next-hop-egress-ipv6-address {
> > >             type inet:ipv4-address;
> > >             mandatory true;
> > >             description
> > >               "Ipv4 address of The next-hop.";
> > >           }
> > >           description
> > >             "Egress-interface and ip address: This can be usesd
> > >              in cases e.g.where The ip address is a link-local
> > >              address.";
> > >         }
> > >       }
> > >
> > >       case egress-interface-mac-next-hop {
> > >         container next-hop-egress-interface-mac-address{
> > >           leaf outgoing-interface {
> > >             type if:interface-ref;
> > >             mandatory true;
> > >             description    "Name of The outgoing interface.";
> > >           }
> > >           leaf ieee-mac-address {
> > >             type uint32;
> > >             mandatory true;
> > >             description    "Name of The mac-address.";
> > >           }
> > >           description
> > >             "Egress-interface and ip address: This can be usesd
> > >              in cases e.g.where The ip address is a link-local
> > >              address.";
> > >         }
> > >       }
> > >
> > >       case tunnel-encap-next-hop {
> > >         container tunnel-encap {
> > >           uses tunnel-encap;
> > >             leaf outgoing-interface {
> > >               type string;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 23]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >           }
> > >           description
> > >             "This can be an encap representing an ip tunnel or
> > >              mpls tunnel or others as defined in this document.
> > >              An optional egress interface can be specified to
> > >              indicate which interface to send The packet out on.
> > >              The egress interface is usesful when the network
> > >              device contains eThernet interfaces and one needs
> > >              to perform address resolution for The ip packet.";
> > >         }
> > >       }
> > >
> > >       case logical-tunnel-next-hop {
> > >         container logical-tunnel {
> > >           uses logical-tunnel;
> > >           description
> > >             "This can be a mpls lsp or a gre tunnel (or others
> > >               as defined in This document), that is represented
> > >               by a unique identifier (e.g. name).";
> > >         }
> > >       }
> > >
> > >       case rib-name {
> > >         leaf rib-name {
> > >           type string;
> > >             description
> > >               "A nexthop pointing to a rib indicates that the
> > >                route lookup needs to continue in The specified
> > >                rib.  This is a way to perform chained lookups.";
> > >         }
> > >       }
> > >     }
> > >   }
> > >
> > >   grouping nexthop-chain-member-identifier{
> > >     choice nexthop-identifier-type{
> > >       case nexthop-chain-name {
> > >         leaf nexthop-chain-name {
> > >           type string;
> > >           mandatory true;
> > >         }
> > >       }
> > >       case nexthop-chain-id {
> > >         leaf nexthop-chain-id {
> > >           type uint32;
> > >           mandatory true;
> > >         }
> > >       }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 24]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     }
> > >   }
> > >
> > >   grouping route-vendor-attributes{
> > >
> > >   }
> > >
> > >   grouping logical-tunnel{
> > >     leaf tunnel-type {
> > >       type tunnel-type-def ;
> > >       mandatory true;
> > >     }
> > >     leaf tunnel-name {
> > >       type string ;
> > >       mandatory true;
> > >     }
> > >   }
> > >
> > >   grouping ipv4-header{
> > >     leaf source-ipv4-address {
> > >       type inet:ipv4-address;
> > >       mandatory true;
> > >     }
> > >     leaf destination-ipv4-address {
> > >       type inet:ipv4-address;
> > >       mandatory true;
> > >     }
> > >     leaf protocol {
> > >       type uint8;
> > >       mandatory true;
> > >     }
> > >     leaf ttl {
> > >       type uint8;
> > >     }
> > >     leaf dscp {
> > >       type uint8;
> > >     }
> > >   }
> > >
> > >   grouping ipv6-header{
> > >     leaf source-ipv6-address {
> > >       type inet:ipv6-address;
> > >       mandatory true;
> > >     }
> > >     leaf destination-ipv6-address {
> > >       type inet:ipv6-address;
> > >       mandatory true;
> > >     }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 25]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     leaf next-header {
> > >       type uint8;
> > >       mandatory true;
> > >     }
> > >     leaf traffic-class {
> > >       type uint8;
> > >     }
> > >     leaf flow-label {
> > >       type uint16;
> > >     }
> > >     leaf hop-limit {
> > >       type uint8;
> > >     }
> > >   }
> > >
> > >   grouping nvgre-header{
> > >     choice nvgre-type {
> > >       description
> > >         "nvgre-header.";
> > >       case ipv4 {
> > >         uses ipv4-header;
> > >       }
> > >       case ipv6 {
> > >         uses ipv6-header;
> > >       }
> > >     }
> > >     leaf virtual-subnet-id {
> > >       type uint32;
> > >       mandatory true;
> > >     }
> > >     leaf flow-id {
> > >       type uint16;
> > >     }
> > >   }
> > >
> > >   grouping vxlan-header{
> > >     choice vxlan-type {
> > >       description
> > >         "vxlan-header.";
> > >       case ipv4 {
> > >         uses ipv4-header;
> > >       }
> > >       case ipv6 {
> > >         uses ipv6-header;
> > >       }
> > >     }
> > >     leaf vxlan-identifier {
> > >       type uint32;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 26]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     }
> > >   }
> > >
> > >   grouping gre-header{
> > >     leaf gre-ip-destination {
> > >       type inet:ipv4-address;
> > >       mandatory true;
> > >     }
> > >     leaf gre-protocol-type {
> > >       type inet:ipv4-address;
> > >       mandatory true;
> > >     }
> > >     leaf gre-key {
> > >       type uint64;
> > >     }
> > >   }
> > >
> > >   grouping ipsec-header{
> > >     description
> > >     "The IPSEC header begins with two 4-byte fields (Security
> > >      Parameters Index (SPI) and Sequence Number).  Following
> > >      these fields is the Payload Data, which has substructure
> > >      that depends on the choice of encryption algorithm and
> > >      mode, and on the use of TFC padding, which is examined
> > >      in more detail later.";
> > >     leaf ipsec-spi {
> > >       type uint32;
> > >       mandatory true;
> > >     }
> > >     leaf ipsec-sequence-number {
> > >       type uint32;
> > >       mandatory true;
> > >     }
> > >   }
> > >
> > >   grouping mpls-header{
> > >     choice mpls-action-type {
> > >       description
> > >         "mpls-header.";
> > >       case mpls-push {
> > >         leaf mpls-push {
> > >           type boolean;
> > >           mandatory true;
> > >         }
> > >         leaf mpls-label {
> > >           type uint32;
> > >           mandatory true;
> > >         }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 27]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >         leaf s-bit {
> > >           type boolean;
> > >         }
> > >         leaf tos-value {
> > >           type uint8;
> > >         }
> > >         leaf ttl-value {
> > >           type uint8;
> > >         }
> > >           }
> > >       case mpls-pop {
> > >         leaf mpls-pop {
> > >           type boolean;
> > >           mandatory true;
> > >         }
> > >         leaf ttl-action {
> > >           type uint8;
> > >         }
> > >       }
> > >     }
> > >   }
> > >
> > >   grouping tunnel-encap{
> > >     choice tunnel-type {
> > >       description
> > >         "options for next-hops.";
> > >       case ipv4 {
> > >         uses ipv4-header;
> > >       }
> > >       case ipv6 {
> > >         uses ipv6-header;
> > >       }
> > >       case mpls {
> > >         uses mpls-header;
> > >       }
> > >       case gre {
> > >         uses gre-header;
> > >       }
> > >       case ipsec {
> > >         uses ipsec-header;
> > >       }
> > >       case nvgre {
> > >         uses nvgre-header;
> > >       }
> > >     }
> > >   }
> > >
> > >   grouping route-attributes{
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 28]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     leaf route-preference {
> > >       description
> > >         "ROUTE_PREFERENCE: This is a numerical value that
> > >          allows for comparing routes from different
> > >          protocols.  Static configuration is also
> > >          considered a protocol for the purpose of this
> > >          field.  It iss also known as administrative-distance.
> > >          The lower the value, the higher the preference.";
> > >         type uint32 ;
> > >       mandatory true;
> > >     }
> > >     leaf local-only {
> > >       type boolean ;
> > >       mandatory true;
> > >     }
> > >     container address-family-route-attributes{
> > >       choice route-type {
> > >         case ip-route-attributes {
> > >         }
> > >         case mpls-route-attributes {
> > >         }
> > >         case eThernet-route-attributes {
> > >         }
> > >       }
> > >     }
> > >   }
> > >
> > >   typedef nhop-lb-weight-def {
> > >     description
> > >       "Nhop-lb-weight is a number between 1 and 99.";
> > >     type uint8 {
> > >       range "1..99";
> > >     }
> > >   }
> > >
> > >   identity mpls-action {
> > >     description "The mpls-action. ";
> > >   }
> > >
> > >   identity push {
> > >     base "mpls-action";
> > >   }
> > >
> > >   identity pop {
> > >     base "mpls-action";
> > >   }
> > >
> > >   identity swap {
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 29]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     base "mpls-action";
> > >   }
> > >
> > >   typedef mpls-action-def {
> > >     type identityref {
> > >       base "mpls-action";
> > >     }
> > >   }
> > >
> > >   identity special-nexthop {
> > >     description "special-nexthop. ";
> > >   }
> > >
> > >   identity discard {
> > >     base "special-nexthop";
> > >   }
> > >
> > >   identity discard-with-error {
> > >     base "special-nexthop";
> > >   }
> > >
> > >   identity receive {
> > >     base "special-nexthop";
> > >   }
> > >
> > >   identity cos-value {
> > >     base "special-nexthop";
> > >   }
> > >
> > >   typedef special-nexthop-def {
> > >     type identityref {
> > >       base "special-nexthop";
> > >     }
> > >   }
> > >
> > >   identity ip-route-type {
> > >     description "The ip route type. ";
> > >   }
> > >
> > >   identity src {
> > >     base "ip-route-type";
> > >   }
> > >
> > >   identity dest {
> > >     base "ip-route-type";
> > >   }
> > >
> > >   identity dest-src {
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 30]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     base "ip-route-type";
> > >   }
> > >
> > >   typedef ip-route-type-def {
> > >     type identityref {
> > >       base "ip-route-type";
> > >     }
> > >   }
> > >
> > >   identity rib-family {
> > >     description "The rib-family. ";
> > >   }
> > >
> > >   identity ipv4-rib-family {
> > >     base "rib-family";
> > >   }
> > >
> > >   identity ipv6-rib-family {
> > >     base "rib-family";
> > >   }
> > >
> > >   identity mpls-rib-family {
> > >     base "rib-family";
> > >   }
> > >
> > >   identity ieee-mac-rib-family {
> > >     base "rib-family";
> > >   }
> > >
> > >   typedef rib-family-def {
> > >     type identityref {
> > >       base "rib-family";
> > >     }
> > >   }
> > >
> > >   identity route-type {
> > >     description "The route type. ";
> > >   }
> > >
> > >   identity ipv4-route {
> > >     base "route-type";
> > >   }
> > >
> > >   identity ipv6-route {
> > >     base "route-type";
> > >   }
> > >
> > >   identity mpls-route {
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 31]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     base "route-type";
> > >   }
> > >
> > >   identity ieee-mac {
> > >     base "route-type";
> > >   }
> > >
> > >   identity interface {
> > >     base "route-type";
> > >   }
> > >
> > >   typedef route-type-def {
> > >     type identityref {
> > >       base "route-type";
> > >     }
> > >   }
> > >
> > >   identity tunnel-type {
> > >     description "the tunnel type.";
> > >   }
> > >
> > >   identity ipv4-tunnel {
> > >     base "tunnel-type";
> > >     description "ipv4";
> > >   }
> > >
> > >   identity ipv6-tunnel {
> > >     base "tunnel-type";
> > >     description "ipv6";
> > >   }
> > >
> > >   identity mpls-tunnel {
> > >     base "tunnel-type";
> > >     description "mpls";
> > >   }
> > >
> > >   identity gre-tunnel {
> > >     base "tunnel-type";
> > >     description "gre";
> > >   }
> > >
> > >   identity ipsec-tunnel {
> > >     base "tunnel-type";
> > >     description "ipsec";
> > >   }
> > >
> > >   identity vxlan-tunnel {
> > >     base "tunnel-type";
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 32]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     description "vxlan";
> > >   }
> > >
> > >   identity nvgre-tunnel {
> > >     base "tunnel-type";
> > >     description "nvgre";
> > >   }
> > >
> > >   typedef tunnel-type-def {
> > >     type identityref {
> > >       base "tunnel-type";
> > >     }
> > >   }
> > >
> > >   identity route-state {
> > >     description "The route state. ";
> > >   }
> > >
> > >   identity active {
> > >     base "route-state";
> > >   }
> > >
> > >   identity inactive {
> > >     base "route-state";
> > >   }
> > >
> > >   typedef route-state-def {
> > >     type identityref {
> > >       base "route-state";
> > >     }
> > >   }
> > >
> > >   identity nexthop-state {
> > >     description "The nexthop state. ";
> > >   }
> > >
> > >   identity resolved {
> > >     base "nexthop-state";
> > >   }
> > >
> > >   identity unresolved {
> > >     base "nexthop-state";
> > >   }
> > >
> > >   typedef nexthop-state-def {
> > >     type identityref {
> > >       base "nexthop-state";
> > >     }
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 33]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >   }
> > >
> > >   identity route-installed-state {
> > >     description "The route installed state. ";
> > >   }
> > >
> > >   identity uninstalled {
> > >     base "route-installed-state";
> > >   }
> > >
> > >   identity Installed {
> > >     base "route-installed-state";
> > >   }
> > >
> > >   typedef route-installed-state-def {
> > >     type identityref {
> > >       base "route-installed-state";
> > >     }
> > >   }
> > >
> > >   identity route-reason {
> > >     description "The reason of invalid Route. ";
> > >   }
> > >
> > >   identity low-preference {
> > >     base "route-reason";
> > >     description "low preference";
> > >   }
> > >
> > >   identity unresolved-nexthop {
> > >     base "route-reason";
> > >     description "unresolved nexthop";
> > >   }
> > >
> > >   identity higher-metric {
> > >     base "route-reason";
> > >     description "higher metric";
> > >   }
> > >
> > >   typedef route-reason-def {
> > >     type identityref {
> > >       base "route-reason";
> > >     }
> > >   }
> > >
> > >
> > >   notification nexthop-resolution-status-change {
> > >     description
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 34]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >         "Nexthop resolution status (resolved/unresolved)
> > >          notification.";
> > >     container nexthop{
> > >       uses nexthop;
> > >     }
> > >     leaf nexthop-state {
> > >       description
> > >        "Nexthop resolution status (resolved/unresolved)
> > >         notification.";
> > >       type nexthop-state-def;
> > >       mandatory true;
> > >     }
> > >   }
> > >
> > >   notification route-change {
> > >     description
> > >         "Route change notification.";
> > >     leaf instance-name {
> > >       description
> > >         "A routing instance is identified by its name,
> > >         INSTANCE_name.  This MUST be unique across all
> > >         routing instances in a given network device.";
> > >       type string ;
> > >       mandatory true;
> > >     }
> > >     leaf rib-name {
> > >       description
> > >        "A reference to The name of a rib.";
> > >       type string;
> > >       mandatory true;
> > >     }
> > >     leaf rib-family {
> > >       type rib-family-def;
> > >       mandatory true;
> > >     }
> > >     uses route-prefix;
> > >     leaf route-installed-state {
> > >       description
> > >        "Indicates whether the route got installed in the FIB.";
> > >       type route-installed-state-def;
> > >       mandatory true;
> > >     }
> > >     leaf route-state {
> > >       description
> > >        "Indicates whether a route is fully resolved and
> > >         is a candidate for selection.";
> > >       type route-state-def;
> > >       mandatory true;
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 35]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >     }
> > >     leaf route-reason {
> > >       description
> > >        "Need to be added.";
> > >       type route-reason-def;
> > >       mandatory true;
> > >     }
> > >   }
> > > }
> > > //   </code ends>
> > >
> > > 4.  IANA Considerations
> > >
> > >    This draft includes no request to IANA.
> > >
> > > 5.  Security Considerations
> > >
> > >    This document introduces no new security threat and SHOULD follow
> the
> > >    security requirements as stated in [I-D.ietf-i2rs-architecture].
> > >
> > > 6.  References
> > >
> > > 6.1.  Normative References
> > >
> > >    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
> > >               Requirement Levels", BCP 14, RFC 2119, March 1997.
> > >
> > > 6.2.  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-08 (work in
> > >               progress), January 2015.
> > >
> > >    [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-05 (work in progress), January 2015.
> > >
> > >    [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.
> > >
> > >    [RFC6020]  Bjorklund, M., "YANG - A Data Modeling Language for the
> > >               Network Configuration Protocol (NETCONF)", RFC 6020,
> > >               October 2010.
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 36]
> > >
> >
> > > Internet-Draft                   RIB DM                       March
> 2015
> > >
> > >
> > >    [RFC6021]  Schoenwaelder, J., "Common YANG Data Types", RFC 6021,
> > >               October 2010.
> > >
> > > Authors' Addresses
> > >
> > >    Lixing Wang
> > >    Huawei
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >    Hariharan Ananthakrishnan
> > >    Packet Design
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >    Mach(Guoyi) Chen
> > >    Huawei
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >    Amit Dass
> > >    Ericsson
> > >    Torshamnsgatan 48.
> > >    Stockholm  16480
> > >    Sweden
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >    Sriganesh Kini
> > >    Ericsson
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >    Nitin Bahadur
> > >    Bracket Computing
> > >
> > >    Email: [e-mail]
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Wang, et al.            Expires September 6, 2015              [Page
> 37]
> >
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <http://www.jacobs-university.de/>
> >
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
> _______________________________________________
> Rtg-yang-coord mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>