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 protected]] On Behalf Of Suresh Krishnan Sent: Wednesday, April 4, 2018 12:39 AM To: The IESG Cc: [email protected]; [email protected]; [email protected]; [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
