[mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 20 December 2018 16:02 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 95D68130E3B; Thu, 20 Dec 2018 08:02:19 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-rsvp-shared-labels@ietf.org, Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, loa@pi.nu, mpls@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154532173960.19019.9125813631355884281.idtracker@ietfa.amsl.com>
Date: Thu, 20 Dec 2018 08:02:19 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/SmFkVfmOeZS3frnZ8SVygYb7eys>
Subject: [mpls] Benjamin Kaduk's No Record on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Dec 2018 16:02:20 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-mpls-rsvp-shared-labels-07: No Record

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-mpls-rsvp-shared-labels/



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

[Leaving my position as "No Record" since I didn't finish my review before the telechat.
Hopefully the comments can still be useful.]

Section 2

I agree with the Gen-ART reviewer that defining "loose hop" would be
helpful.

   Delegation label:   A label assigned at the delegation hop to
      represent a set of labels that will be pushed at this hop.

A terminology question (or perhaps just my ignorance), but is "assigned at"
the proper wording for this?  My initial reading was that this label would
be added to the stack while traversing ("at") the delegation hop, but that
doesn't really make sense given the rest of the definition.

Section 5.1.2

   The downside of this approach is that the number of hops that the LSP
   can traverse is dictated by the label stack push limit of the
   ingress.

There is perhaps some more subtlety here, in that the interaction involves
both the label stack push limit at the ingress, but also the number of
delegation labels and TE link labels not included in a delegation.  Thus,
the difference between this case and the "stack to reach delegation hop"
method is that all delegation hops after the first one will decrease the
effective label stack push limit at the ingress (for the path to the first
delegation hop).  It's not clear that this paragraph does a good job of
summarizing that distinction, as-is.

Section 5.3.1

It's unclear to me whether, after such a gap in ETLD support, the next
node that supports ETLD is supposed to decrement the ETLD value by just one
or by the total number of nodes (accounting for itself and the
non-ETLD-supporting nodes), assuming that the ETLD remains positive after
such an operation.

Section 9.1

   o  When the use of TE link labels is mandated/requested for the path:
[...]
      *  When explicit delegation is mandated or automatic delegation is
         requested:

         +  the ingress SHOULD have the ability to indicate the chosen
            stacking approach (and)

         +  the delegation hop SHOULD have the ability to indicate that
            the recorded label is a delegation label.

Does the first one need to be a MUST?  The behavior of the delegation hop
depends on the chosen stacking approach, and I can't quite convince myself
that it would always be determinable just from inspecting the stack on
ingress to the delegation hop.

Section 9.4

nit: the wording "MUST be set [...] only if" is a bit awkward; what we
really want to say is that if TE link labels are not in use/recording for
this LSP, then this flag MUST NOT be set ... right?