Re: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

Suresh:

Thank you for catching these issues.   I missed these as a Shepherd (as did
the other reviewers) and AD.  See my answers below. 

Would you or Martin hold a discuss until these critical issues are resolved
and checked with the YANG doctors?  I will work with the authors to resolve
these issues.   This revision will take some time as we seek advice from the
YANG doctors and from the community on the IEEE MAC Address being an index
or a full MAC Address. 

Susan Hares

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Suresh Krishnan
Sent: Wednesday, April 4, 2018 12:39 AM
To: The IESG
Cc: i2rs@ietf.org; draft-ietf-i2rs-rib-data-model@ietf.org;
i2rs-chairs@ietf.org; shares@ndzh.com
Subject: [i2rs] Suresh Krishnan's Discuss on
draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

Suresh Krishnan has entered the following ballot position for
draft-ietf-i2rs-rib-data-model-10: Discuss

When responding, please keep the subject line intact and reply to all email
addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-rib-data-model/

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

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

* Section 3

=> Under

identity ipv6-decapsulation {

it looks like the description is wrong ("IPv4 tunnel decapsulation.")
----
You are correct.  It will be replaced with the following
=========
   identity ipv6-decapsulation {
     base "tunnel-decapsulation-action";
     description
       "IPv6 tunnel decapsulation.";
   }

=>  What use case is the ttl-action decrease-and-copy-to-inner used for?
----
Good catch! 
This feature may be used for tunnels (7.2.1 of
draft-ietf-i2rs-rib-info-model) or nexthops chains (section 7.2.5 of
draft-ietf-i2rs-rib-info-model).   Good catch in that it does not provide
enough detail in this version.  

We've had comments over the last years to put this level of detail in or out
of the YANG model.  I believe the latest wisdom from NETMOD/NETCONF is to
put the level of detail back in 

=> 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?   

Good Catch. 

Early on it was a holding place for a the official IEEE:MAC table, and
should have been transferred to either the IEEE:MAC-ADDRESS (see page 17
RIB-INFO draft). However, this definitely needs to get fixed.  I need to
check with the YANG Doctors to determine which is the preferred fix for this
reference at this time.  I'm sure implementers have been using a fully
qualified IEEE_MAC_ADDRESS or a reference to the Table. 

High level - case points to an outgoing interface, ieee-mac address - 

       case egress-interface-mac-nexthop {
         container 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
               "The nexthop points to an interface with
                a specific mac-address.";
           }
           description
             "The egress interface must be an Ethernet
              interface. Address resolution is not required
              for this 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;"

_______________________________________________
i2rs mailing list
i2rs@ietf.org
https://www.ietf.org/mailman/listinfo/i2rs