Robert Wilton's No Objection on draft-ietf-6man-spring-srv6-oam-11: (with COMMENT)
Robert Wilton via Datatracker <noreply@ietf.org> Thu, 03 June 2021 10:45 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ipv6@ietf.org
Delivered-To: ipv6@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D74E3A33C3; Thu, 3 Jun 2021 03:45:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Robert Wilton via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-6man-spring-srv6-oam@ietf.org, 6man-chairs@ietf.org, ipv6@ietf.org, Ole Trøan <ot@cisco.com>, ot@cisco.com
Subject: Robert Wilton's No Objection on draft-ietf-6man-spring-srv6-oam-11: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 7.30.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Robert Wilton <rwilton@cisco.com>
Message-ID: <162271715422.26113.4445478402968497630@ietfa.amsl.com>
Date: Thu, 03 Jun 2021 03:45:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/YhAifWsWadJUQOlM7UjwM3b9ii8>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Jun 2021 10:45:55 -0000
Robert Wilton has entered the following ballot position for draft-ietf-6man-spring-srv6-oam-11: 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. I would also like to thank Dan for the Opsdir review. Similarly to how some fellow ADs have commented, I found parts of this document tricky to read, particularly around the use of IPv6 addresses and trying to understand what is fixed and what is variable. I suspect that the terminology is clear to engineers who are very familiar with SRv6, but is perhaps more opaque to less familiar readers. I've added a few suggestions on how this could possible be clarified (at the authors discretion): (1) I wonder whether the diagrams would be easier to understand if perhaps the variables used angle brackets or '$' to indicate that they are a variable. E.g. rather than: "2001:db8:i:j:in::", would it be clearer as "2001:db8:<i>:<j>:<i><n>::" or perhaps "2001:db8:$i:$j:$i$n::"? (2) In other cases the locator block is defined as 2001:db8:B::/48, but it isn't defined what B is. I presume that this identifies the block, but this should be clarified, and perhaps giving a concrete example Block number might be helpful. (3) Similarly, "A" in the loopback address donot appear to be defined. Nor is it clear what "C" is, in the context of "Cij" or "C23". Separately, I also have some sympathy with John's discuss ballot where a separate Stds Track doc from the OAM flag vs an Informational draft for the Ping and traceroute examples might have been clearer. But conversely, I can also see clear benefit in having all of SRv6 related OAM work in one document. The document may benefit having a bit more of a clear distinction between the normative parts of the document that define new functionality and the illustrative parts of the document that just provide examples. In particular, I would suggest: - Changing the ordering/wording of both the abstract and introduction to describe the OAM flag first, and then the ping/traceroute examples second, which also follows the order that the concepts are discussed in the document. - Perhaps be explicit at the beginning of section 3 that the text is not normative and only provide examples of what the existing mechanisms look like when applied to SRv6. - Perhaps move section 1.3 to section 3, if I am right that the example is only applicable to section 3? A couple of comments related to PSP handling: In section 2.1.1: If the telemetry data from the ultimate segment in the segment-list is required, a penultimate segment SHOULD NOT be a Penultimate Segment Pop (PSP) SID. When the penultimate segment is a PSP SID, the SRH will be removed and the O-flag will not be processed at the ultimate segment. Would "cannot" be better than "SHOULD NOT"? I.e., isn't this more of this just won't work rather than this won't interoperate? Similarly, in section 3.1.1: The penultimate node (Node N4) does not, should not and cannot differentiate between the data packets and OAM probes. I would suggest changing "does not, should not and cannot" to just "cannot". Finally, it wasn't clear to me how the controller N100 is connected to topology. Normally, I would assume that this would be over a separate management network, but then in section 3.4 it talks about loopback probes. Hence, it wasn't clear to me whether the expectation was to be bridging data plane traffic to the management network (which seems unwise), or more likely you would have a separate dataplane connection to the controller for the loopback probes. Adding some text to section 3.4 to clarify this may be helpful for readers. Thanks, Rob
- Robert Wilton's No Objection on draft-ietf-6man-s… Robert Wilton via Datatracker