Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
Joe Clarke <jclarke@cisco.com> Fri, 26 October 2018 19:42 UTC
Return-Path: <jclarke@cisco.com>
X-Original-To: ietf@ietf.org
Delivered-To: ietf@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC8B130E4C; Fri, 26 Oct 2018 12:42:13 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Joe Clarke <jclarke@cisco.com>
To: ops-dir@ietf.org
Cc: lsr@ietf.org, ietf@ietf.org, draft-ietf-ospf-ospfv3-segment-routing-extensions.all@ietf.org
Subject: Opsdir last call review of draft-ietf-ospf-ospfv3-segment-routing-extensions-16
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154058293310.8782.9766839380541329981@ietfa.amsl.com>
Date: Fri, 26 Oct 2018 12:42:13 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/z9SCSfMkWkOMlLpV0NYVsa-VTGI>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 19:42:14 -0000
Reviewer: Joe Clarke Review result: Has Nits I have been assigned to review draft-ietf-ospf-ospfv3-segment-routing-extensions on behalf of the ops directorate. This document defines OSPFv3 extensions needed for segment routing (SR). And therein lies my first nit. While the document begins to set forth this overarching scope, a small paragraph in section 1 further limits it to MPLS dataplanes only. I think perhaps the abstract should be updated to clarify that. Other items I found are listed below. Overall, there are a lot of terminology used like RSVP, LDP, LSP, SID, etc. I think this document would benefit from a terminology section. With respect to TLV types 8, 9, 14, and 15, they are defined in draft-ietf-ospf-segment-routing-extensions, and it took me a while to figure out where you were getting those values and why they weren't spelled out in the IANA considerations. You have a normative reference to this, which is good, but you only mention it with respect to the algorithm parameters. I think another mention is required. I'm going to be pedantic here. According to RFC7770, when a new OSPF Router Information LSA TLV is defined, the spec needs to explicitly state if it's applicable to OSPFv2, v3, or both. While you reference the TLVs from draft-ietf-ospf-segment-routing-extensions, I didn't see that either document _explicitly_ states that they are applicable to both. === Section 2.1 s/length is other then 3 or 4/length is other than 3 or 4/ === Section 3.2 s/If more then one SID/Label/If more than one SID/label/ === Section 3.2 "When a router receives multiple overlapping ranges, it MUST conform to the procedures defined in [I-D.ietf-spring-segment-routing-mpls]." It would be useful to include a section pointer here. I think your referring to Section 2.3 where the router ignores the range? Is it likely that will change to something other than "ignore?" If not, maybe it's just worth mentioning that here. === Section 3.3 s/If more then one SID/Label/If more than one SID/Label/ === Section 3.3 "The originating router MUST NOT advertise overlapping ranges." You specify what a router should do if it receives overlapping ranges above. I think the same text should be used here, too. === Section 5 "Other bits: Reserved. These MUST be zero when sent and are ignored when received." The normative language changes. In other places you say the bits SHOULD be 0. I suggest: Other bits: Reserved. These SHOULD be set to 0 when sent and MUST be ignored when received. === Section 7.4.1 s/state lower then 2-Way/state lower than 2-Way/ ===
- Opsdir last call review of draft-ietf-ospf-ospfv3… Joe Clarke
- Re: Opsdir last call review of draft-ietf-ospf-os… Peter Psenak
- Re: Opsdir last call review of draft-ietf-ospf-os… Acee Lindem (acee)
- RE: Opsdir last call review of draft-ietf-ospf-os… Les Ginsberg (ginsberg)
- Re: Opsdir last call review of draft-ietf-ospf-os… Acee Lindem (acee)
- Re: Opsdir last call review of draft-ietf-ospf-os… Benjamin Kaduk
- Re: Opsdir last call review of draft-ietf-ospf-os… Joe Clarke
- Re: Opsdir last call review of draft-ietf-ospf-os… Peter Psenak
- Re: Opsdir last call review of draft-ietf-ospf-os… Peter Psenak