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

Alvaro Retana via Datatracker <noreply@ietf.org> Wed, 20 January 2021 15:36 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Alvaro Retana via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-spring-sr-yang@ietf.org, spring-chairs@ietf.org, spring@ietf.org, Joel Halpern <jmh@joelhalpern.com>
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alvaro Retana <aretana.ietf@gmail.com>
Message-ID: <161115696601.10370.4919077195510776918@ietfa.amsl.com>
Date: Wed, 20 Jan 2021 07:36:06 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/spring/FCs2RwtfMDjo481oYZqnZ727n6Q>
Subject: [spring] Alvaro Retana's No Objection on draft-ietf-spring-sr-yang-29: (with COMMENT)

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://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-spring-sr-yang/



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

(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

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

[spring] Alvaro Retana's No Objection on draft-ie… Alvaro Retana via Datatracker
Re: [spring] Alvaro Retana's No Objection on draf… Yingzhen Qu
Re: [spring] Alvaro Retana's No Objection on draf… Alvaro Retana