[Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Wed, 26 September 2018 22:02 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 4A7D6130DD4; Wed, 26 Sep 2018 15:02:00 -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-ospf-segment-routing-msd@ietf.org, Acee Lindem <acee@cisco.com>, aretana.ietf@gmail.com, lsr-chairs@ietf.org, acee@cisco.com, lsr@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.84.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153799932029.21668.4310004028084936568.idtracker@ietfa.amsl.com>
Date: Wed, 26 Sep 2018 15:02:00 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/URuPCApfaPXoijq-ub6P3lgeNtU>
Subject: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf-segment-routing-msd-21: (with DISCUSS and 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 22:02:01 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ospf-segment-routing-msd-21: Discuss 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-ospf-segment-routing-msd/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This is essentially a process discuss, and hopefully easy to resolve. In Section 4, we say: The meaning of the absence of both Node and Link MSD advertisements for a given MSD type is specific to the MSD type. Generally it can only be inferred that the advertising node does not support advertisement of that MSD type. However, in some cases the lack of advertisement might imply that the functionality associated with the MSD type is not supported. The correct interpretation MUST be specified when an MSD type is defined. I don't think we can make this sort of normative requirement on a registry created by a different document, at least not without updating the registry to also point to this document. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Can SID be expanded on first usage -- https://www.rfc-editor.org/materials/abbrev.expansion.txt does not list it as "well known". (It also doesn't appear to list "Segment Identifier" as one of the expansions.) This is basically the same thing I said for the IS-IS document that creates the MSD types registry, but I'm not sure I followed correctly the meaning of MSD type 1 for SR-enabled vs. non-SR-enabled networks. In particular, I still don't really understand why it's okay to use the same codepoint for the max SID depth in SR-enabled networks and for the max label depth in non-SR MPLS networks. Why couldn't they just be separate MSD Type codepoints? Section-by-section comments follow. Section 2 If the Node MSD TLV appears in multiple Router Information LSAs that have the same flooding scope, the Node MSD TLV in the Router Information (RI) LSA with the numerically smallest Instance ID MUST be used and subsequent instances of the Node MSD TLV MUST be ignored. [...] Unless there is a sorting requirement I've forgotten about, shouldn't this be "other" rather than "subsequent"? Section 6 Thanks for the updates in response to the secdir review; they help a lot. If the value is larger than supported - instantiation of a path that can't be supported by the head-end (the node performing the SID imposition). This is supposed to mean "(instantiation by the head-end) of a (path that can't be supported)", not "instantiation of a path (that can't be supported by the head-end)", right?
- [Lsr] Benjamin Kaduk's Discuss on draft-ietf-ospf… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Acee Lindem (acee)
- Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-… Benjamin Kaduk