A YANG Data Model for the Routing Information Base (RIB)
draft-ietf-i2rs-rib-data-model-15

[Ballot comment]
I2RS use cases document seems to be abandoned, and generally use case documents best fit the purpose of tracking the work on specification documents. Is the reference really needed?

Please address RTG-DIR comments on RIB/Rib/rib consistency, encap/encapsulation, decap/decapsulation consisteny.

s/nexthop-replicates/nexthop-replicate, or change the description of base nexthop.

s/blow/below

s/VxLAN/VXLAN throughout the document.

nexthop-lb-weight-definition: divided by the sum of weights. Or, to simplify the text, representing a proportion. Value of 0 is not in the range.

[Ballot comment]
I2RS use cases document seems to be abandoned, and generally use case documents best fit the purpose of tracking the work on specification documents. Is the reference really needed?
Please address RTG-DIR comments on RIB/Rib/rib consistency, encap/encapsulation, decap/decapsulation consisteny.
s/nexthop-replicates/nexthop-replicate, or change the description of base nexthop.
s/blow/below
s/VxLAN/VXLAN throughout the document.
nexthop-lb-weight-definition: divided by the sum of weights. Or, to simplify the text, representing a proportion. Value of 0 is not in the range.

[Ballot comment]
I2RS use cases document seems to be abandoned, and generally use case documents best fit the purpose of tracking the work on specification documents. Is the reference really needed?
Please address RTG-DIR comments on RIB/Rib/rib consistency.
s/nexthop-replicates/nexthop-replicate, or change the description of base nexthop.
s/blow/below

[Ballot comment]

This is similar enough to Suresh's DISCUSS that I don't see the point in
making it a DISCUSS also (which it would be otherwise). I'll let him make sure
field size issues are taken care of.

>        case mac-route {
>          description
>            "MAC route case.";
>          leaf mac-address {
>            type uint32 ;
>            mandatory true;
>            description
>              "The MAC address used for matching.";
>          }
>        }

The intention here is to use IEEE EUI-48 and/or EUI-64 identifiers here, right?
These don't fit into a uint32.

This problem arises elsewhere in the module; e.g.:

>          leaf ieee-mac-address {
>            type uint32;
>            mandatory true;
>            description
>              "The nexthop points to an interface with
>              a specific mac-address.";
>          }

===========================================================================

§2.6:

>    Nexthops can be fully resolved or an unresolved.

Nit: remove "an"

---------------------------------------------------------------------------

§3:

>  import ietf-interfaces {
>    prefix if;
>        reference "RFC 7223";
>  }
>
>  import ietf-yang-types {
>    prefix yang;
>        reference "RFC 6991";
>  }

The indenting of the "reference" fields seems odd.


>  identity ipv6-decapsulation {
>    base "tunnel-decapsulation-action";
>    description
>      "IPv4 tunnel decapsulation.";
>  }

The description here appears to be incorrect (should say "IPv6")


>  identity decrease-and-copy-to-next {
>    base "ttl-action";
>    description
>      "Decrease TTL by one and copy the TTL
>      to the next header.For example: when
>      MPLS label swapping, decrease the TTL
>      of the inner label and copy it to the
>      outer label.";
>  }

Nit: insert a space before "For".


>  identity resolved {
>    base "nexthop-state";
>    description
>      "Reolved nexthop state.";
>  }

Nit: "Resolved" rather than "Reolved."


>  typedef nexthop-lb-weight-definition {
>    type uint8 {
>      range "1..99";
>    }
>    description
>      "Nexthop-lb-weight is used for load-balancing.
>      Each list member MUST be assigned a weight
>      between 1 and 99. The weight determines the
>      proportion of traffic to be sent over a nexthop
>      used for forwarding as a ratio of the weight of
>      this nexthop divided by the weights of all the
>      nexthops of this route that are used for forwarding.
>      To perform equal load-balancing, one MAY specify
>      a weight of 0 for all the member nexthops.  The
>      value 0 is reserved for equal load-balancing
>      and if applied, MUST be applied to all member nexthops.";
>  }

To match the text (which allows 0 as a special case), the range needs to be
updated to be "0..99" rather than "1..99"


>    leaf hop-limit {
>      type uint8;
>      description
>        "The hop limit the header.";
>    }

Nit: "The hop limit of the header."


>    choice nvgre-type {
>      description
>        "NvGRE can use eigher IPv4
>        or IPv6 header for encapsulation.";

Nit: "either"


>    leaf flow-id {
>      type uint16;
>      description
>        "The flow identifier of the NvGRE header.";
>    }

Why is this a uint16 rather than a uint8?

[Ballot discuss]
This model tries to squeeze the 20 bit IPv6 flow label into a 16 bit field. This will result in a loss of data and needs to be fixed before the document is published.

[Ballot comment]
* Section 3

=> Under

identity ipv6-decapsulation {

it looks like the description is wrong ("IPv4 tunnel decapsulation.")

=>  What use case is the ttl-action decrease-and-copy-to-inner used for?

=> Under
case egress-interface-mac-nexthop {

It is not clear to me how you fit a MAC address into a 32 bit space ,or am I misreading this somehow and this is some form of index?

"          leaf ieee-mac-address {
              type uint32;"

[Ballot comment]
I agree with Alissa's comments.

Requirements Language: There are at least a few instances of lower case versions of 2119 keywords. Please consider using the boilerplate from RFC 8174.

Abstract: Missing article before "Routing Information Base"

§1, first paragraph: Missing article before "Routing Information Base"

[Ballot comment]
I agree with Alissa's comment.

A couple nits:

In Section 2.6:
    Nexthops can be fully resolved or an unresolved.
I don't think the "an" is needed.

In the module itself:
  typedef nexthop-lb-weight-definition {
    type uint8 {
      range "1..99";
    }
    description
      "Nexthop-lb-weight is used for load-balancing.
        Each list member MUST be assigned a weight
        between 1 and 99. The weight determines the
        proportion of traffic to be sent over a nexthop
        used for forwarding as a ratio of the weight of
        this nexthop divided by the weights of all the

"sum of the weights", presumably.

        nexthops of this route that are used for forwarding.
        To perform equal load-balancing, one MAY specify
        a weight of 0 for all the member nexthops.  The
        value 0 is reserved for equal load-balancing
        and if applied, MUST be applied to all member nexthops.";
  }

Also, there's a mismatch between the MUST (1-99) and MAY (0).

[Ballot comment]
Sec 1.2:

"YANG tree diagrams provide a concise representation of a YANG module,
  and SHOULD be included to help readers understand YANG module
  structure."

This document does not seem like an appropriate place to have normative guidance about this. And if this sentence is removed, I don't see the point of including Section 1.2 otherwise. This would also imply deleting the reference to I-D.ietf-netmod-yang-tree-diagrams.

Sec 2.1: Again here I'm confused about the use of normative language. Why do you need to specify normative requirements for what this very document is specifying? Or are these supposed to be requirements on implementations?

Sec 2.5: s/causes/caused/

[Ballot comment]
(1) "This document defines a YANG data model for Routing Information Base (RIB) that aligns with the I2RS RIB information model."  That and the multiple references to the information model (in the text and on the e-mail archive) make it a required document to understand for the implementation of the data model.  draft-ietf-i2rs-rib-info-model should then be a Normative reference.

I am not making this point a DISCUSS because I think it is easy to solve: just move the reference.

(2) In Figure 1: s/route-reason-definition/route-change-reason-definition

(3) For completeness: in S2.3, the Reason attribute is missing (from S4 in draft-ietf-i2rs-rib-info-model).

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-i2rs-rib-data-model-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the ns registry on the IETF XML Registry page located at:

https://www.iana.org/assignments/xml-registry/

a single, new namespace will be registered as follows:

ID: yang:ietf-i2rs-rib
URI: rn:ietf:params:xml:ns:yang:ietf-i2rs-rib
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. If there is no expert designated for the registry, we will work with the IESG to have one assigned. Expert review will need to be completed before your document can be approved for publication as an RFC.


Second, in the YANG Module Names registry on the YANG Parameters registry page located at:

https://www.iana.org/assignments/yang-parameters/

a single, new YANG module will be registered as follows:

Name: ietf-i2rs-rib
File: [ TBD-at-Registration ]
Maintained by IANA?
Namespace: urn:ietf:params:xml:ns:yang:ietf-i2rs-rib
Prefix: iir
Module:
Reference: [ RFC-to-be ]

IANA Question --> What should be the entry for the registry value "Maintained by IANA?" for this new YANG module?

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-30):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , draft-ietf-i2rs-rib-data-model@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Routing Information Base (RIB)) to Proposed Standard


The IESG has received a request from the Interface to the Routing System WG
(i2rs) to consider the following document: - 'A YANG Data Model for Routing
Information Base (RIB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-30. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model for Routing Information Base
  (RIB) that aligns with the I2RS RIB information model.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ballot/


No IPR declarations have been submitted directly on this I-D.

The following Last Call announcement was sent out (ends 2018-03-06):

From: The IESG
To: IETF-Announce
CC: i2rs@ietf.org, Susan Hares , draft-ietf-i2rs-rib-data-model@ietf.org, i2rs-chairs@ietf.org, akatlas@gmail.com, shares@ndzh.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for Routing Information Base (RIB)) to Proposed Standard


The IESG has received a request from the Interface to the Routing System WG
(i2rs) to consider the following document: - 'A YANG Data Model for Routing
Information Base (RIB)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document defines a YANG data model for Routing Information Base
  (RIB) that aligns with the I2RS RIB information model.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/ballot/


No IPR declarations have been submitted directly on this I-D.

Template: 2/24/2012

Things for AD and shepherd to watch during WG LC
=============================================
1) authors add NMDA text  and yang 1.1
2) authors change to align to yang high-level marking
  draft-ietf-netmod-yang-tree-diagrams-06
3) making sure the Yang catalog gets unscrambled.

=================


(1)Type: Proposed Standard
Why?  - It is a yang data model


(2) The IESG approval announcements:

Technical Summary
  This document defines a YANG data model for Routing Information Base
  (RIB) that aligns with the I2RS RIB information model.

  This yang data model complies with the network management datastore
  architecture.  It can be loaded in configuration datastores or in dynamic
  datastores.

Working Group Summary

  I2RS has aided the transformation IETF network management
into the network management datastore  architecture.
The journey has tested the IETF's ability to work cross area,
and across groups to support this data model.

The 3rd WG LC for the WG draft found the WG to be worn
out by this activity.  The data model has not changed since the
early days, but WG group has change the world that it lives in.
If you are on the IESG, look at all the EMAILs regarding this draft.
You will not see anything in the last 3 years.

Benoit Claise and Alia Atlas wanted me to push to publish
this draft ahead of all of the NMDA work.  As a nerd,
I wanted to make sure it aligned.

Benoit and Alia were right and I was wrong.  If I had only
listened, we would not be closing I2RS because the
WG would not be as frustrated with the slow progress toward
the NMDA architecture. 

Document Quality

  Are there existing implementations of the protocol?
  Some early implementations of this protocol existed as far back
  as 3 years ago. I'm not sure how close they are to the
NMDA.

The thought and design in this RIB is better than
anything the IETF has come up within 15 years.

Personnel

  Who is the Document Shepherd?  Susan Hares
  AD: Alia Atlas
RTG-DIR reviewers: John Scudder
SEC-DIR: Derrell Piper
YANG-Doctors: Ebben Aries

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

Shepherd sent this draft to RTG-DIR early reviews, OPS-DIR
YANG Doctor's early reviews, and SEC-DIR reviews.
The RTG-DIR and OPS-DIR early reviews did not come back as
requested in January (1/4/2018).  No amount of pushing
or begging and pleading seems to get more.

WG LC should shake some loose.

Authors have promised to be responsive.
The shepherd will keep updating the top of shepherd's review.
 

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

This did not get the requested RTG-DIR, OPS-DIR, and Yang-Doctors reviews
in January.  We can no longer wait - so these reviews should come during WG LC.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

YANG doctors and RTG-DIR.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

This document is the best example of a RIB I have observed.
It is capable of going to the dynamic datastore or configuration.
It aligns with the NMDA.  Help it get out into the wild by
getting the appropriate reviews and NITs.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Lixing Wang
https://mailarchive.ietf.org/arch/msg/i2rs/ddXYGcITllYYPtXfSzCtu9Ft-OQ

Amit Dass
https://mailarchive.ietf.org/arch/msg/i2rs/hdngkBEhPO2mixlYuHfN3R4BxhU

Mach(Guoyi) Chen
https://mailarchive.ietf.org/arch/msg/i2rs/DCE6oh718znQLfTucfG3gcIh02M

H. Ananthakrishnan (Hari)
https://mailarchive.ietf.org/arch/msg/i2rs/OcRT7dcggU3c3mr_BGCmBkRuF0Q

Sriganesh Kini
https://mailarchive.ietf.org/arch/msg/i2rs/7x-r1VB4EWP-GXOCFbbW0cbZnMg


(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

Solid enough to push the IETF concepts from its old config data model
to the NMDA model.  Thanks Benoit and Alia for all the support!

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

nope!

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Line length (1 line)
outdated documents:  (will be fixed during WG LC)
    draft-ietf-netmod-yang-tree-diagrams-04
    draft-ietf-i2rs-rib-info-model-13


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

See Yang Doctors early review.

(13) Have all references within this document been identified as
either normative or informative?

yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

Nope - all normative are RFCs or in RFC editor's queue.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

no.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

It aligns with yang model suggestions.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No new registries.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

Request for posting confirmation emailed to previous authors: Hariharan Ananthakrishnan , Lixing Wang , " amit.dass@ericsson.com" , Nitin Bahadur , Sriganesh Kini , Mach Chen

Request for posting confirmation emailed to previous authors: Hariharan Ananthakrishnan , Lixing Wang , " amit.dass@ericsson.com" , Sriganesh Kini , i2rs-chairs@ietf.org, Nitin Bahadur , Mach Chen

Request for posting confirmation emailed to previous authors: Hariharan Ananthakrishnan , Lixing Wang , " amit.dass@ericsson.com" , Sriganesh Kini , Nitin Bahadur , Mach Chen

Request for posting confirmation emailed to previous authors: "Mach Chen" , "Sriganesh Kini" , "Nitin Bahadur" , " amit.dass@ericsson.com" , "Lixing Wang" , i2rs-chairs@ietf.org, "Hariharan Ananthakrishnan"