Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hi Ron,

Thanks for your detailed review.

This is to acknowledge your email.
Please expect delays in response due to the Christmas break.

Happy Holidays,

Thanks

Regards … Zafar

From: Ron Bonica <rbonica@juniper.net>
Date: Monday, December 23, 2019 at 2:49 PM
To: "Zafar Ali (zali)" <zali@cisco.com>, Ole Troan <otroan@employees.org>, 6man WG <ipv6@ietf.org>, SPRING WG <spring@ietf.org>
Cc: 6man Chairs <6man-chairs@ietf.org>
Subject: RE: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hi Ali,

I have review what I believe to be the latest  version (in github) and have the following comments:

Major
--------

  *   A close reading of Section 3.1.1 reveals that the O-flag is processed even when Segments Left is equal to 0. This would make the SRH the only IPv6 Routing Header that requires processing when Segments Left is equal to zero. Do you really want to go there?
  *   In Section 4.1.1, Classic PING isn’t used to “ping a remote IP Prefix”. It is used to query the liveness of an interface.
  *   In Section 4.1.1, N1 sends (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2, NH =  ICMPv6)(ICMPv6 Echo Request). The SRH contains an IPv6 address that is not a SID ( A:1:: ). Is this legal?
  *   In Section 4.1.1.1, the PHP is not required. If N5 doesn’t understand SRH, it skips over it.
  *   In Section 4.2.1, N1 sends a traceroute (A:1::, B:2:C31)(A:5::, B:4:C52, B:2:C31, SL=2,). The SRH contains an IPv6 address that is not a SID ( A:1:: ). Is this legal?
  *
Minor
---------

  *   In Section 3.1.1 you make it clear that you duplicate the packet, forward one copy and send the other copy for OAM processing. A strict reading of Sections 3.3 and 3.4 suggest that you send the one and only copy of the packet for OAM processing. You may forward the packet after OAM processing is complete. I don’t think that this is what you mean to say.
Nits
-----

  *   You might want to reference RFC 2151 for Classic PING and Traceroute
  *   In Paragraph 2 of Section 4.1.2, you say that the PING failed because the next header was ICMP and not SRH. That is true if B:4:C52 requires SL to be greater than 0, but not true in the general case. In the general case, the PING fails because the ENH is ICMP, and B:4:C52 requires something other than ICMP as the ENH.

Juniper Business Use Only
From: Zafar Ali (zali) <zali@cisco.com>
Sent: Friday, December 20, 2019 10:42 AM
To: Ron Bonica <rbonica@juniper.net>; Ole Troan <otroan@employees.org>; 6man WG <ipv6@ietf.org>; SPRING WG <spring@ietf.org>
Cc: 6man Chairs <6man-chairs@ietf.org>; Zafar Ali (zali) <zali@cisco.com>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hi Ron,

Thanks for your review.

Unfortunately, you seem to have not get the latest version from the Github (which was later posted as v03).
Good news is that your comments were addressed in the latest version.

Please see specifics in-line.

Happy Holidays!

Thanks

Regards … Zafar

From: spring <spring-bounces@ietf.org<mailto:spring-bounces@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org<mailto:rbonica=40juniper.net@dmarc.ietf.org>>
Date: Wednesday, December 18, 2019 at 4:07 PM
To: Ole Troan <otroan@employees.org<mailto:otroan@employees.org>>, 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: 6man Chairs <6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>>
Subject: Re: [spring] 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Ole,

I have reviewed version-02 of this document and believe that it still has the following major issues:

- Section 3.1.1 assumes implementation details (e.g., that the implementation has an OAM process) but fails to describe any externally observable behavior. The externally observable behaviors are described, incompletely, in Sections 4.1.2 and 4.2.2.

[ZA] Like you mentioned, processing details were embedded in the Section 4. We brought them up in the Section 3 and also added additional normative language in Section 4. Specifically, In the new revision:

  *   We have added normative text at the beginning of 3.1.1 where O-bit is defined.
  *   Sections 3.3 and 3.4 adds normative texts for OAM SIDs.
  *   4.1.2 and 4.2.2 further adds additional normative text for Ping and traceroute use-cases, respectively.

- Section 3.5 seems to be incomplete. What TLV are we talking about and what role does it play?

[ZA] This has been already addressed. Specifically, indeed, the draft does not define any TLV for OAM purposes. However, section was added as future drafts may define OAM TLVs. However, the section has been removed in the new revision.

- Section 4 talks about future revisions of this document. Aren't we in WGLC?

[ZA] This has been already addressed in the latest version.

- Section 4.1.2.1 - When the ping succeeds, what does the success message look like? An ICMP Echo Response? What is the source address? A SID?

[ZA] Yes, it is an ICMP Echo Response ICMP Echo Response. The v03 specifically mentions the same. As mentioned in the draft, the upper layer header processing follows RFC4443.

- Section 4.1.2.2 - Does this work with PSP?

[ZA] This does not apply. There is no PSP flavor defined for END.OP SID.

- Section 4.2.2.1 - Do we need to examine flags even when SL == 0?

[ZA] The O-bit is for telemetry purpose and packets with SL=0 are also telemetered.

                                                                                                    Ron

Juniper Business Use Only

-----Original Message-----
From: ipv6 <ipv6-bounces@ietf.org<mailto:ipv6-bounces@ietf.org>> On Behalf Of Ole Troan
Sent: Wednesday, December 4, 2019 3:53 PM
To: 6man WG <ipv6@ietf.org<mailto:ipv6@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>>
Cc: 6man Chairs <6man-chairs@ietf.org<mailto:6man-chairs@ietf.org>>
Subject: 6man w.g. last call for <draft-ietf-6man-spring-srv6-oam>

Hello,

  As agreed in the working group session in Singapore, this message starts a new two week 6MAN Working Group Last Call on advancing:

  Title    : Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
  Author   : Z. Ali, C. Filsfils, S. Matsushima, D. Voyer, M. Chen
  Filename : draft-ietf-6man-spring-srv6-oam-02
  Pages    : 23
  Date     : 2019-11-20

    https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-22No-zDm$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-22No-zDm$>

as a Proposed Standard.

Substantive comments and statements of support for publishing this document should be directed to the mailing list.
Editorial suggestions can be sent to the author. This last call will end on the 18th of December 2019.

To improve document quality and ensure that bugs are caught as early as possible, we would require at least two reviewers to do a complete review of the document.  Please let the chairs know if you are willing to be a reviewer.

The last call will be forwarded to the spring working group, with discussion directed to the ipv6 list.

Thanks,
Bob & Ole, 6man co-chairs

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org<mailto:ipv6@ietf.org>
Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-2-1yR5ZL$<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/ipv6__;!8WoA6RjC81c!XSqnzjZKANP41cvNa8ybSjYCuTDO6XCHjQyZ4ARNtx4MhYWG7vdEvXi-2-1yR5ZL$>
--------------------------------------------------------------------

_______________________________________________
spring mailing list
spring@ietf.org<mailto:spring@ietf.org>
https://www.ietf.org/mailman/listinfo/spring<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/spring__;!!NEt6yMaO-gk!Xe39zIjcBKwYFDvV6Q2GfJ7fv99Kfb1g8vhRkYOSD6cLIna-skv10h-rVkxUzyd9$>