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

From: Mahesh Jethanandani <[email-masked]>
Date: Wed, 4 Mar 2015 22:30:37 -0800

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
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 08:45:29 +0100

> 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 counte…

Resetting counters is a bad idea. Once you have more than one
application trying to reset counters you get into trouble. Note
this RFC 6991 (lifted from RFC 2578):

       Counters have no defined 'initial' value, and thus, a
       single value of a counter has (in general) no information
       content.

Applications have to read a counter C at time t0 and then again at
time t1 and then calculate the difference C(t1) - C(t0). This allows
applications to obtain statistics at different time granularities
without stepping on each other.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Mar 2015 05:53:05 -0500

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:[email-masked]] On Behalf Of
Mahesh Jethanandani
Sent: Thursday, March 05, 2015 1:31 AM
To: [email-masked]
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

[email-masked]

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 5 Mar 2015 08:07:02 -0800

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 <[email-masked]> 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:[email-masked]] On Behalf Of Mahesh Jethanandani
> [email-masked] <mailto:[email-masked]>
Mahesh Jethanandani
[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Mar 2015 17:15:50 +0100

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

> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 5 Mar 2015 08:57:29 -0800

Susan,

BTW, another great example on use of containers can be found in the BGP YANG module here <https://tools.ietf.org/html/draft-zhdankin-idr-bgp-cfg-00>.

With some clever use of containers, like bgp-neighbors and within it, bgp-neighbor-state or bhp-neighbor-statistics, you can drill down into the specific config, state or counters you would be interested in configuring/finding/purging.

Cheers.

> On Mar 5, 2015, at 8:06 AM, Mahesh Jethanandani <[email-masked]> 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.
> 

Mahesh Jethanandani
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Mar 2015 09:16:52 -0800

> state can be different from the configured state.

IMO this practice should only be used when there is a possibility
that the state can exist independently of the config.
There are costs (complexity of syncing 2 lists, memory costs
replicating data structures and keys) to be considered.

> /js

Andy

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 07:23:55 -0500

Mahesh:

This is very helpful! 

Thank you,

Sue Hares

From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Mahesh Jethanandani
Sent: Thursday, March 05, 2015 11:07 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Rtg-yang-coord] Clearing all stats in a container

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.

    config false;

<snip>

    container statistics {

        description

          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.

Mahesh:

Sue 

Mahesh Jethanandani

 <mailto:[email-masked]> [email-masked]

Mahesh Jethanandani

[email-masked]

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 07:29:17 -0500

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:[email-masked]] 
Sent: Thursday, March 05, 2015 11:16 AM
To: Mahesh Jethanandani
Cc: Susan Hares; [email-masked]
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.
> > 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.

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 6 Mar 2015 07:30:37 -0500

> On Mar 6, 2015:7:29 AM, at 7:29 AM, Susan Hares <[email-masked]> wrote:
> 
> Juergen:
> 

	Please CC: NETMOD at this time just to keep the thread consistent. 

	--Tom

> <draft-wang-i2rs-rib-dm-01.txt>_______________________________________________

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 13:59:15 +0100

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

> 
> 
> 
> 
> 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 [email-masked]"
> 
> 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: [email-masked]
>       email: [email-masked]
>       email: [email-masked]
>       email: [email-masked]
>       email: [email-masked]
>       email: [email-masked]";
> 
>   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: [email-masked]
> 
> 
>    Hariharan Ananthakrishnan
>    Packet Design
> 
>    Email: [email-masked]
> 
> 
>    Mach(Guoyi) Chen
>    Huawei
> 
>    Email: [email-masked]
> 
> 
>    Amit Dass
>    Ericsson
>    Torshamnsgatan 48.
>    Stockholm  16480
>    Sweden
> 
>    Email: [email-masked]
> 
> 
>    Sriganesh Kini
>    Ericsson
> 
>    Email: [email-masked]
> 
> 
>    Nitin Bahadur
>    Bracket Computing
> 
>    Email: [email-masked]
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Wang, et al.            Expires September 6, 2015              [Page 37]

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 08:10:25 -0500

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:[email-masked]] 
Sent: Friday, March 06, 2015 7:59 AM
To: Susan Hares
Cc: 'Mahesh Jethanandani'; [email-masked]
Subject: Re: [Rtg-yang-coord] Clearing all stats in a container

Susan,

/js

> it was generally found useful when we did the interfaces and ip YANG
models

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 08:16:18 -0500

Mahesh:

This is really helpful advice. I'm loosing track of my emails so if this is
the 2nd thank you, pleas ignore the spam. 

Sue 

From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Mahesh Jethanandani
Sent: Thursday, March 05, 2015 11:57 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Rtg-yang-coord] Clearing all stats in a container

Susan,

BTW, another great example on use of containers can be found in the BGP YANG
module here <https://tools.ietf.org/html/draft-zhdankin-idr-bgp-cfg-00> .

With some clever use of containers, like bgp-neighbors and within it,
bgp-neighbor-state or bhp-neighbor-statistics, you can drill down into the
specific config, state or counters you would be interested in
configuring/finding/purging.

Cheers.

On Mar 5, 2015, at 8:06 AM, Mahesh Jethanandani <[email-masked]>
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.

    config false;

<snip>

    container statistics {

        description

          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.

Mahesh:

Sue 

Mahesh Jethanandani

Mahesh Jethanandani

[email-masked]

 

Mahesh Jethanandani

[email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 14:22:50 +0100

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

---

From: Benoit Claise <[email-masked]>
Date: Fri, 06 Mar 2015 14:32:52 +0100

Hi Jürgen,

That makes a lot of sense, and not only for the routing YANG models 
(even if the bulk of YANG models is right now in routing)
I've been thinking about it many times, but I haven't found the right 
way to represent this high dynamic overview.

Regards, Benoit

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 6 Mar 2015 08:54:24 -0500

Benoit and Jürgen:

This is good advice.  After the draft deadline, I will post something on the
I2RS Wiki that provides this linkage for the i2RS draft.  I've forwarded
your advice to the RIB info design team and Topology design team. 

Sue 

-----Original Message-----
From: Rtg-yang-coord [mailto:[email-masked]] On Behalf Of
Benoit Claise
Sent: Friday, March 06, 2015 8:33 AM
To: Susan Hares; 'Mahesh Jethanandani'; [email-masked]
Subject: Re: [Rtg-yang-coord] Clearing all stats in a container

Hi Jürgen,

Regards, Benoit

>>> From: Juergen Schoenwaelder
[mailto:[email-masked]]
>>>                                                                   M.
Chen
Huawei
>>>                                                                   A.
Dass
>>>                                                                   S.
Kini
Ericsson
>>>                                                                N.
Bahadur
>>>                                                         Bracket
Computing
>>>                                                            March 05,
2015

---

From: Alia Atlas <[email-masked]>
Date: Fri, 6 Mar 2015 09:45:47 -0500

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 <
[email-masked]> wrote:

> > > Thank you for this advice.  If you have time (before the Draft
> deadline)
> > to
> > > pointed out, clearing stats may not be one of them. But if you wanted
> to
> > say
> > > Internet-Draft