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

Thanks Suresh, Martin and Sue,

The issues will be addressed in verion-11.

Best regards,
Mach

> -----Original Message-----
> From: Susan Hares [mailto:shares@ndzh.com]
> Sent: Thursday, April 05, 2018 10:08 PM
> To: 'Martin Bjorklund' <mbj@tail-f.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)
> 
> 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
> >