Éric Vyncke's Discuss on draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-6man-spring-srv6-oam-10: 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 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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

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 two blocking but trivial DISCUSS points, some non-blocking
COMMENT points (but replies would be appreciated), and one nit.

I hope that this helps to improve the document,

Regards,

-éric

== DISCUSS ==

-- Section 2.1 --
As "a penultimate segment SHOULD NOT be a Penultimate Segment Pop (PSP) SID" is
normative, then the network programming RFC 8986 should be a normative
reference. Trivial to fix.

-- Section 9.2 --
Trivial to fix, RFC 8174 should be normative.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

== 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.