[Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (with COMMENT)
Spencer Dawkins <spencerdawkins.ietf@gmail.com> Tue, 04 December 2018 18:40 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
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 58EB7130F3A; Tue, 4 Dec 2018 10:40:01 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ospf-ospfv3-segment-routing-extensions@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.89.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154394880135.4620.12307141022996623217.idtracker@ietfa.amsl.com>
Date: Tue, 04 Dec 2018 10:40:01 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/lsr/VROmibrgVV0j-z1cbRWE46wCZDg>
Subject: [Lsr] Spencer Dawkins' No Objection on draft-ietf-ospf-ospfv3-segment-routing-extensions-20: (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: Tue, 04 Dec 2018 18:40:02 -0000
Spencer Dawkins has entered the following ballot position for draft-ietf-ospf-ospfv3-segment-routing-extensions-20: 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-ospf-ospfv3-segment-routing-extensions/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Introduction would have been much clearer for me if these paragraphs were much closer to the top of the section - they're at the bottom of the section now. This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. Segment Routing architecture is described in [RFC8402]. Segment Routing use cases are described in [RFC7855]. With that change, I'm not sure how much of the discussion in the Introduction would still be required, but do the right thing, of course. I'd make the same suggestion for the Abstract, Segment Routing (SR) allows a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the OSPFv3 extensions required for Segment Routing with MPLS data plane. if it was more than two paragraphs long ... I am thinking that the reference There are additional segment types, e.g., Binding SID defined in [RFC8402]. would be more useful at the beginning of Section 3, because that's where you list the additional segment types, but the reference is back in the Introduction (with only one example of the segment types). I'm thinking the SHOULD in this text Existing security extensions as described in [RFC5340] and [RFC8362] apply to these segment routing extensions. While OSPFv3 is under a single administrative domain, there can be deployments where potential attackers have access to one or more networks in the OSPFv3 routing domain. In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] SHOULD be used. is not an RFC 2119 SHOULD that describes interworking, so something like In these deployments, stronger authentication mechanisms such as those specified in [RFC4552] or [RFC7166] are needed. would be better, but if this IS a SHOULD, I'm curious why you wouldn't use stronger authentication mechanisms if they're needed. You might want to add guidance about that, so it's not confused with MUST (BUT WE KNOW YOU WON'T) as defined in https://tools.ietf.org/html/rfc6919#section-1. Is there another document that says things like Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv3 router or routing process. Reception of a malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPFv3 control plane. ? This doesn't seem very SR-specific, although I'm guessing. If there's a broader document, I don't object to including this guidance here, but adding a reference to a broader document might be useful.
- [Lsr] Spencer Dawkins' No Objection on draft-ietf… Spencer Dawkins
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Acee Lindem (acee)
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Spencer Dawkins at IETF
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Acee Lindem (acee)
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Acee Lindem (acee)
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Spencer Dawkins at IETF
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Peter Psenak
- Re: [Lsr] Spencer Dawkins' No Objection on draft-… Thomas Beaver