Re: [spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

[Yingzhen Qu <[e-mail]>]

Hi Alvaro,

Thank you for your thorough review and comments. We just published version -30 to address IESG review comments. Please see detailed answers below inline.

Please let us know if you have more comments.

Thanks,
Yingzhen

On Jan 20, 2021, at 7:36 AM, Alvaro Retana via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:

Alvaro Retana has entered the following ballot position for
draft-ietf-spring-sr-yang-29: No Objection

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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fiesg%2Fstatement%2Fdiscuss-criteria.html&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=UzYBQkG%2F7WWwviq2NjV6Ws41jzkK6cHXIbgkGMONDS8%3D&amp;reserved=0
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-spring-sr-yang%2F&amp;data=04%7C01%7Cyingzhen.qu%40futurewei.com%7Cf34b1809d0074d6584b008d8bd591adb%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637467537718756918%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vKOEndcJtpxSOMYmSRfeNPcObJygZiXHl7Eo2gn3M9A%3D&amp;reserved=0



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) I have a significant concern about the incomplete representation of the
MSD in this document.  Even though the model is incomplete, I am not balloting
DISCUSS because this point should be easy to address.

    grouping max-sid-depth {
      description
        "Maximum SID Depth (MSD) operational state grouping.";
      leaf node-msd {
        type uint8;
        description
          "Node MSD is the lowest MSD supported by the node.";
      }
      container link-msds {
        description
          "MSD supported by an individual interface.";
        list link-msds {
          key "interface";
          description
            "List of link MSDs.";
          leaf interface {
            type if:interface-ref;
            description
              "Reference to device interface.";
          }
          leaf msd {
            type uint8;
            description
              "MSD supported by the interface.";
          }
        }
      }
    }


(a) While there is a "type" mentioned, that seems to correspond to the
MSD-Value.  The MSD-Type is not included above.

(b) Note that the MSD is really a pair of MSD-Type/MSD-Value.  The description
above, even if extended to also include the MSD-Type, seems to allow for a
single pair, where multiple could be advertised per node/link.

(c) The ERLD (entropy-readable-label-depth, for which references should be
included) is advertised in the IGPs using the same mechanism as the MSD: using
the ERLD-MSD type.  IOW, the separation of the ERLD from the MSD in the module
is redundant/incorrect.

(d) MSD is a good example of a feature that is common to both the MPLS and
IPv6 dataplanes and should be in the common part of the model, not defined
separately for each.

[Yingzhen]: we had a discussion among the authors, and we decided to remove the MSD and ERLD status from this SR-MPLS base model.
The consensus is that although MSD and ERLD are related with SR, they’re not SR specific.

From RFC 8491:

MSD advertisements MAY be useful even if Segment Routing itself is
not enabled.

We will submit a new YANG module which augments the base MPLS module (RFC 8960) with MSD info.

(2) §3: "Module ietf-segment-routing-common defines generic types and
groupings that SHOULD be reused by IGP extension modules."  The SHOULD is out
place because the module is either supported or not, if it isn't then there is
no effect on interoperability because the IGP extension module presumably
chose a different option.  s/that SHOULD/to

[Yingzhen]: fixed.

(3) §3: There should be a representation of the ietf-segment-routing-common
module in this section.

[Yingzhen]: I suppose you mean YANG tree diagram here. ietf-segment-routing-common module only has definitions,
identities and groupings, and typically we don’t generate separate trees for groupings. Their trees are shown in places
where groupings are being used.