Subject: Robert Wilton's No Objection on draft-ietf-6man-spring-srv6-oam-11: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 03 Jun 2021 03:45:54 -0700

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