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

Martin:

Thank you for the proactive response on the types.  I'll work with the
authors to change to these standard types.   

Sue 

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Thursday, April 5, 2018 10:06 AM
To: shares@ndzh.com
Cc: suresh@kaloom.com; iesg@ietf.org; i2rs@ietf.org;
draft-ietf-i2rs-rib-data-model@ietf.org; i2rs-chairs@ietf.org
Subject: 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
> 