[Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 21:46 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: lsr@ietf.org
Delivered-To: lsr@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AD10129C6A; Wed, 26 Sep 2018 14:46:15 -0700 (PDT)
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-isis-segment-routing-msd@ietf.org, Christian Hopps <chopps@chopps.org>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, chopps@chopps.org, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153799837555.21625.17869101343542542632.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 14:46:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/ExgOuQ23XvV99U_WF2XcV0LlWuo>
Subject: [Lsr] Benjamin Kaduk's No Objection on draft-ietf-isis-segment-routing-msd-17: (with COMMENT)
X-BeenThere: lsr@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Link State Routing Working Group <lsr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lsr>, <mailto:lsr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lsr/>
List-Post: <mailto:lsr@ietf.org>
List-Help: <mailto:lsr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lsr>, <mailto:lsr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Sep 2018 21:46:16 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-isis-segment-routing-msd-17: 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-isis-segment-routing-msd/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The shepherd writeup is silent about the WG's discussion of the IPR disclosure (but the corresponding ospf draft says this sort of thing is typical for LSR drafts). Section 3 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 223 to carry the MSD of the interface associated with the link. MSD Please add the appropriate qualifier (IS-IS?) before the list of TLV numbers. MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 represents lack of the ability to support SID stack of any depth; any other value represents that of the link. It's unclear that there's a referent for "that of the link" to attach to. That is, is it better to say "represents the maximum SID depth supported by the link" (or similar)? Section 6 As discussed in the secdir review, this section needs to include guidance to the Experts to check that the meaning of the absence of an MSD type is specified. Given the text in draft-ietf-ospf-segment-routing-msd that attempts to place a similar requirement on future MSD types (but for OSPF vs. IS-IS usage thereof), hopefully this guidance can be phrased in an appropriately general fashion so as to apply to all places where the registered MSD value would be used. Section 7 Advertisement of the additional information defined in this document that is false, e.g., an MSD that is incorrect, may result in a path computation failing, having a service unavailable, or calculation of a path that cannot be supported by the head-end (the node performing the imposition). In the analogous OSPF document we split out the case of a value that is too small and a value that is too large, to describe the different consequences. I would also suggest rewording to something like "calculation by the head-end of a path that cannot be supported" to avoid the mis-parsing "(calculation of a path) (that cannot be supported by the head-end)".
- [Lsr] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Alvaro Retana
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Les Ginsberg (ginsberg)
- Re: [Lsr] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk