Éric Vyncke's No Objection on draft-ietf-6man-spring-srv6-oam-11: (with COMMENT)
Éric Vyncke via Datatracker <firstname.lastname@example.org> Wed, 02 June 2021 18:50 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EA23A16B8; Wed, 2 Jun 2021 11:50:22 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Éric Vyncke via Datatracker <email@example.com>
To: The IESG <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com, Ole Trøan <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, email@example.com
Subject: Éric Vyncke's No Objection on draft-ietf-6man-spring-srv6-oam-11: (with COMMENT)
Reply-To: Éric Vyncke <firstname.lastname@example.org>
Date: Wed, 02 Jun 2021 11:50:22 -0700
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jun 2021 18:50:23 -0000
Éric Vyncke 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: ---------------------------------------------------------------------- Top posting: thank you for the quick fix on my two DISCUSS points (I told you there were easy to fix). I also like the added text to address Martin Duke's DISCUSS point. I kept the non-blocking COMMENT points below. ---- Thank you for the work put into this document. It is comforting (even if not surprising) that the simple "good old" ping/traceroute work on a SRv6 network ;-) Thanks to Carlos Bernardos for his INT-REVIEW at https://datatracker.ietf.org/doc/review-ietf-6man-spring-srv6-oam-10-intdir-telechat-bernardos-2021-05-28/ Thanks to Ole Trøan for his shepherd document even if I regret the lack of justification for 'standards track'. Especially, because the abstract is mainly about ping/traceroute, hence should be informational but the O-flag is indeed standard track. So, all in all, this is OK. Please find below some non-blocking COMMENT points (but replies would be appreciated), and one nit. I hope that this helps to improve the document, Regards, -éric == COMMENTS == Is there any reason not to follow RFC 5952 about IPv6 address representation? I.e., not using uppercase ;-) (you may use uppercase for the 'variable' such as k). I understand that changing the case is a long and cumbersome endeavor... This comment is of course non-blocking. About the O-flag, as this I-D is about OAM, I would have expected that the document specifies some operational recommendations, e.g., collecting statistics about O-flag processing: packet count, requests ignored, ... -- Section 1 -- In the first sentence, is it RFC 8402 or RFC 8754 ? -- Section 1.3 -- I was about to raise a DISCUSS on this one... the abstract and introduction is about SRv6 and this section uses network programming example with END.X. Suggest to either modify abstract / introduction to mention RFC 8986 or simplify the example by not using END.X (e.g., not mentioning END.X as the plain SRH adj-sid behavior is END.X -- no need IMHO to introduce the network programming nomenclature). -- Section 2.1 -- Not important and feel free to ignore, but, while telemetry operation is important for OAM, OAM is broader than plain "telemetry data collect and export" (IMHO). I would have preferred the use of 'telemetry marking' for example. But, I guess it is too late to change the O-flag into a T-flag ;-) In "packet header", is the layer-2 header included ? IPFIX can export layer-2 information, hence my question. Perhaps better to use "IP header" here ? -- Section 2.1.1 -- I was again about the raise a DISCUSS on this point, S01.1 appears to be applicable to SRH/RFC 8754 while the text about PSP is clearly about net-pgm/RFC 8986. How can we reconciliate this ? Finally, in the case of PSP, should the normative pseudo-code be changed by introducing another 'if' in the pseudo-code ? -- Section 3.1.1 -- The figure 2 seems to have an incoherent 'screen shot' as 2001:db8:A:5:: is used as the ping target but the output of the ping displays "B5::". What did I miss ? The node N4 is assumed to "performs the standard SRH processing" but later it needs to process a "PSP SID", which is not standard SRH RFC but in the net-pgm one. -- Section 3.2.1 -- I wonder whether "These ICMPv6 responses are IP routed." is really useful here as plain IP routing will be applied (or do you mean no using SRH in the reply?). The example uses "DA" while I would expect that this would be the "SA" of the received ICMP messages. But, this is cosmetic. -- Section 3.2.2 -- What is a "classic IPv6 node" ? I guess it is a 'non SRv6-capable node' => to be added in the terminology section ? -- Section 3.3 -- "The local OAM process sends a full or partial copy" it really smells like a postcard OAM while IPFIX can be used to send aggregated data, which is also very useful. All in all, if this is a local send to another process, then worth mentioning it. == NITS == -- Section 1.3 -- As figure 1 uses a double border for SRv6-capable nodes, let's mention it in the text.
- Éric Vyncke's No Objection on draft-ietf-6man-spr… Éric Vyncke via Datatracker