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

From: Suresh Krishnan <[email-masked]>
Date: Tue, 03 Apr 2018 21:39:04 -0700

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

=>  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;"

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Apr 2018 09:48:27 -0400

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:[email-masked]] On Behalf Of Suresh Krishnan
Sent: Wednesday, April 4, 2018 12:39 AM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked]
Subject: [i2rs] Suresh Krishnan's Discuss on
draft-ietf-i2rs-rib-data-model-10: (with DISCUSS and COMMENT)

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

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.

* Section 3

=> Under

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 {

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.";
         }
       }

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Apr 2018 16:05:41 +0200 (CEST)

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

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 5 Apr 2018 10:07:40 -0400

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:[email-masked]] 
Sent: Thursday, April 5, 2018 10:06 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]
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" <[email-masked]> wrote:
> 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
> YANG doctors and from the community on the IEEE MAC Address being an 
> index or a full MAC Address.
> 
> Susan Hares
> 
> 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
> This will result in a loss of data and needs to be fixed before the 
> document is published.
> 
> 
> You are correct.  It will be replaced with the following =========
> 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
>  
> 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.
> 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?
>

---

From: Mach Chen <[email-masked]>
Date: Sun, 8 Apr 2018 08:27:15 +0000

Thanks Suresh, Martin and Sue,

The issues will be addressed in verion-11.

Best regards,
Mach

> From: Susan Hares [mailto:[email-masked]]
> Sent: Thursday, April 05, 2018 10:08 PM
> To: 'Martin Bjorklund' <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-i2rs-rib-data-
> [email-masked]; [email-masked]
> Subject: RE: [i2rs] Suresh Krishnan's Discuss on draft-ietf-i2rs-rib-data-model-10:
> (with DISCUSS and COMMENT)
> 
> Martin:
> 
> Cc: [email-masked]; [email-masked]; [email-masked]; draft-ietf-i2rs-rib-data-
> [email-masked]; [email-masked]
> There are standard types for IPv6 flow label and for MAC addresses defined in
> RFC 6991:
> 
>    inet:ipv6-flow-label
>    yang:mac-address
> 
> 
> /martin
> 
> 
> > ,or am
> I