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

["Zafar Ali (zali)" <[e-mail]>]

Hi Eric,

Please see [ZA] in-line on proposed changes/ clarifications to address your comments

We plan to post an update to address your comments and other pending comments from Carlos Bernardos, et al
(target: Before the telechat or later during the week; please excuse delay due to out-of-office situation)

Thanks

Regards … Zafar

From: "Zafar Ali (zali)" <[e-mail]>
Date: Wednesday, June 2, 2021 at 1:00 PM
To: "Eric Vyncke (evyncke)" <[e-mail]>, The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Zafar Ali (zali)" <[e-mail]>
Subject: Re: Éric Vyncke's Discuss on draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)

Hi Eric,

Many thanks for your comments; much appreciated.

As I am out-of-office, may we please take a two-step approach:

Step1:
We have posted rev-11 to address your DISCUSS:
https://www.ietf.org/rfcdiff?url2=draft-ietf-6man-spring-srv6-oam-11.txt
https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-11

Step2:
Please expect a follow-up email from us on your comments.
We plan to post an update to address your comments (target: Before the telechat or later during the week)

Thanks

Regards … Zafar

From: Éric Vyncke via Datatracker <[e-mail]>
Reply-To: "Eric Vyncke (evyncke)" <[e-mail]>
Date: Tuesday, June 1, 2021 at 5:49 PM
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Éric Vyncke's Discuss on draft-ietf-6man-spring-srv6-oam-10: (with DISCUSS and COMMENT)
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Resent-Date: Tuesday, June 1, 2021 at 5:48 PM

É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/

[ZA] +1 Thanks Carlos! Sorry for delay in addressing the comments; I am and have been out-of-office since your comments; Plan is to address them before telechat or end of current week.

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.

[ZA] We have fixed it Rev-11.

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

 [ZA] We have fixed it Rev-11.

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

[ZA] The capital letters are used to distinguish them from hex character, e.g.,
In 2001:db8:B:2:C31
B represents SID block
C31 represents cross connect to neighbor node 3 via Link1, i.e., c is NOT meant as 0xc
I hope it clarifies

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

                [ZA] This is a good comment. We can add some operational recommendations.


                [ZA] We think it is RFC 8402, as the we are referring the following text from it:

RFC8405: SR can be applied to the IPv6 architecture, with a new type of routing header.

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


                [ZA] We can “modify abstract / introduction to mention RFC 8986”; We think that use of specific SIDs definition (like END.X) from RFC 8986 improve the illustrations.


-- 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 ?

[ZA] We can make the change

-- 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 ?

[ZA] How about we add the following text to the draft.

                --- inserted before the pseudocode ---

New Text to be added: The following pseudocode is exemplifies the O-flag processing using the SRv6 SID behaviors defined in Section 4.3.1 of [RFC8754]<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.1>. The equivalent O-flag processing is equally applicable to the SIDs defined in [RFC8986]. For example, section 3.3 illustrates O-flag usage using END.X SID.


                --- Change after the pseudocode (changes in bold) ---



      Current text:  Please note that the O-flag processing happens before execution of

   regular processing of the local SID S.  Specifically, the line S01.1

   of the pseudo-code specified in this document is inserted between

   line S01 and S02 of the pseudo-code defined in section 4.3.1.1 of<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.1.1>

   [RFC8754]<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.1.1>.



        New text:        Please note that the O-flag processing happens before execution of

   regular processing of the local SID S.  Specifically, the line S01.1

   of the pseudo-code specified in this document is inserted between

   line S01 and S02 of the pseudo-code defined in section 4.3.1.1 of<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.1.1>

                  [RFC8754]<https://datatracker.ietf.org/doc/html/rfc8754#section-4.3.1.1>. Similarly, the O-flag is processed before execution of

   regular processing of the SIDs defined in [RFC8986].


Finally, in the case of PSP, should the normative pseudo-code be changed by
introducing another 'if' in the pseudo-code ?


                    [ZA] As noted in above text from the draft, “the O-flag processing happens before execution of
  regular processing of the local SID S”, the PSP processing does not change the O-flag processing rule.


-- 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 ?

[ZA] Good catch; will fix.


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.

We can the following changes; please advise:


Current Text: Node N4, which is an SRv6-capable node, performs the standard SRH

      processing.  Specifically, it observes the END.X behavior

      (2001:db8:B:4:C52::) and forwards the packet on link10 towards N5.


New Text: Node N4, which is an SRv6-capable node, performs the

       the END.X (2001:db8:B:4:C52::) processing as defined in [RFC8986]

       and forwards the packet on link10 towards N5.


-- 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?).

                [ZA] That is a good point. There are some use-cases, where the node generating the ICMPv6 response may like to use a traffic engineered path using SRH, e.g., bi-directional SRv6 policy. How about the following diffs (in bold):


Current Text: These ICMPv6 responses are IP routed.


New Text: These ICMPv6 responses are IP routed. However, based on local configuration, the node generating the ICMPv6 response may use a traffic engineered path using SRH to send the echo reply.

The example uses "DA" while I would expect that this would be the "SA" of the
received ICMP messages. But, this is cosmetic.

                [ZA] We can fix/ clarify

-- 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 ?

                [ZA] Indeed; will fix

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

               [ZA] In rev-11 diffs, we added a clarification text around "The local OAM process sends a full or partial copy" text;
                We also added text in https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-11.txt#section-2.1.1


== NITS ==

-- Section 1.3 --
As figure 1 uses a double border for SRv6-capable nodes, let's mention it in
the text.

                [ZA] Thanks, we will fix it