[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?
- [mpls] Benjamin Kaduk's No Record on draft-ietf-m… Benjamin Kaduk