[mpls] Adam Roach's No Objection on draft-ietf-mpls-rsvp-shared-labels-07: (with COMMENT)
Adam Roach <adam@nostrum.com> Wed, 19 December 2018 22:09 UTC
Return-Path: <adam@nostrum.com>
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 CBF71130EDA; Wed, 19 Dec 2018 14:09:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
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: <154525735582.1826.11425645649794902713.idtracker@ietfa.amsl.com>
Date: Wed, 19 Dec 2018 14:09:15 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/l6H-I91PW9-h1SyGNOL3wF3lJk8>
Subject: [mpls] Adam Roach's No Objection 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: Wed, 19 Dec 2018 22:09:16 -0000
Adam Roach has entered the following ballot position for draft-ietf-mpls-rsvp-shared-labels-07: 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-mpls-rsvp-shared-labels/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks to everyone who worked on this document. I have a handful of comments. --------------------------------------------------------------------------- §7: > The following logic could be used by the node constructing the label > stack: > > Each RRO label sub-object SHOULD be processed starting with the > label sub-object from the first downstream hop. Any label > provided by the first downstream hop MUST always be pushed on the > label stack regardless of the label type. If the label type is a > TE link label, then any label from the next downstream hop MUST > also be pushed on the constructed label stack. If the label type > is a regular label, then any label from the next downstream hop > MUST NOT be pushed on the constructed label stack. If the label > type is a delegation label, then the type of stacking approach > chosen by the ingress for this LSP (Section 5.1) MUST be used to > determine how the delegation labels are pushed in the label stack. The use of normative language in example text is very confusing. I fear that this processing will be read as normative rather than the example that it appears to be ("could be used"). I believe what you want is something more like: Each RRO label sub-object will be processed starting with the label sub-object from the first downstream hop. Any label provided by the first downstream hop will always be pushed on the label stack regardless of the label type. If the label type is a TE link label, then any label from the next downstream hop will also be pushed on the constructed label stack. If the label type is a regular label, then any label from the next downstream hop will not be pushed on the constructed label stack. If the label type is a delegation label, then the type of stacking approach chosen by the ingress for this LSP (Section 5.1) will be used to determine how the delegation labels are pushed in the label stack. Alternately, if the text is meant to be normative, then the introductory sentence needs to be changed ("is used" or "must be used"), and the paragraph itself should probably not be indented. --------------------------------------------------------------------------- §8.1: > To provide link protection at a Point of Local Repair (PLR) with a > shared MPLS forwarding plane, the LSR SHOULD allocate a separate TE > link label for the TE link that will be used for RSVP-TE tunnels that > request link protection from the ingress. This isn't really my area, but from the fuzzy model I have in my head about link protection, it seems to me that this won't actually work unless a new label is allocated -- right? If that's the case, then the preceding "SHOULD" would appear to actually be a "MUST". Or is the notion that some LSR might choose to simply treat all traffic as link-protected? --------------------------------------------------------------------------- §9.2: > When a node that does not cater to the mandate > receives a Path message carrying the LSP_REQUIRED_ATTRIBUTES object > with this flag set, it MUST send a PathErr message with an error code > of 'Routing Problem (24)' and an error value of 'TE link label usage > failure (TBD3)'. I'm a little confused about how this is intended to work. At first, this looked like it might just be a restatement of the behavior of LSP_REQUIRED_ATTRIBUTES; however, it's unclear how existing, already deployed nodes are going to be able to send an error value of TBD3. This same comment applies to §9.4.
- [mpls] Adam Roach's No Objection on draft-ietf-mp… Adam Roach
- Re: [mpls] Adam Roach's No Objection on draft-iet… Vishnu Pavan Beeram