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

Hi,

There are standard types for IPv6 flow label and for MAC addresses
defined in RFC 6991:

   inet:ipv6-flow-label
   yang:mac-address 

/martin

"Susan Hares" <shares@ndzh.com> wrote:
> 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
> 
> _______________________________________________
> i2rs mailing list
> i2rs@ietf.org
> https://www.ietf.org/mailman/listinfo/i2rs
> 