Hi Ron, Many thanks for your detailed review and the comments.
Please see [ZA] in-line. Please also refer to the latest version in the GitHub on how the comments are addressed: https://github.com/ietf-6man/srv6-oam Thanks Regards … Zafar From: Ron Bonica <rbon...@juniper.net> Date: Monday, December 23, 2019 at 2:49 PM To: "Zafar Ali (zali)" <z...@cisco.com>, Ole Troan <otr...@employees.org>, 6man WG <i...@ietf.org>, SPRING WG <spring@ietf.org> Cc: 6man Chairs <6man-cha...@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? [ZA] As a reminder, the O-flag tells the segment endpoint to send a copy of incoming packet to a controller (as it reaches the segment end nodes). [ZA] Please note that the draft states, “When N receives a packet whose IPv6 DA is S and S is a local SID … ” [ZA] All routing headers are processed in sequence, including the SRH. [ZA] Section 3.1.1 indicates that an implementation supporting this draft checks the O-flag, regardless of SL value. [ZA] Subsequent processing of the SRH does not change. * 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. [ZA] To address your comment, in the latest version at the GitHub, we made a change as follows: [ZA] OLD: The existing mechanism to ping a remote IP prefix. [ZA] NEW: The existing mechanism to query liveliness of a remote IP address. * 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? [ZA] Did you mean A:5:: is in SRH, instead of A:1::? Yes, it is legal. Please see all the examples in section 6.3, 6.4, 6.5 of the SRH draft. * In Section 4.1.1.1, the PHP is not required. If N5 doesn’t understand SRH, it skips over it. [ZA] Did you mean in Section 4.1.1 (instead of Section 4.1.1.1)? [ZA] The text does not say that PHP is required, it just gives an illustration for the PHP case. [ZA] Nonetheless, text in the latest version at the GitHub addresses this comment. * 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? [ZA] Same as previous comment. 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. [ZA] Yes, the OAM process does NOT forward the packet back on the wire. A text stating, “The OAM SIDs terminate the forwarding of the probe packets for the upper layer processing” has been added to address your comment. Nits ----- * You might want to reference RFC 2151 for Classic PING and Traceroute [ZA] Reference added. * 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. [ZA] Addressed in the latest revision in the GitHub. Juniper Business Use Only From: Zafar Ali (zali) <z...@cisco.com> Sent: Friday, December 20, 2019 10:42 AM To: Ron Bonica <rbon...@juniper.net>; Ole Troan <otr...@employees.org>; 6man WG <i...@ietf.org>; SPRING WG <spring@ietf.org> Cc: 6man Chairs <6man-cha...@ietf.org>; Zafar Ali (zali) <z...@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-boun...@ietf.org<mailto:spring-boun...@ietf.org>> on behalf of Ron Bonica <rbonica=40juniper....@dmarc.ietf.org<mailto:rbonica=40juniper....@dmarc.ietf.org>> Date: Wednesday, December 18, 2019 at 4:07 PM To: Ole Troan <otr...@employees.org<mailto:otr...@employees.org>>, 6man WG <i...@ietf.org<mailto:i...@ietf.org>>, SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: 6man Chairs <6man-cha...@ietf.org<mailto:6man-cha...@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-boun...@ietf.org<mailto:ipv6-boun...@ietf.org>> On Behalf Of Ole Troan Sent: Wednesday, December 4, 2019 3:53 PM To: 6man WG <i...@ietf.org<mailto:i...@ietf.org>>; SPRING WG <spring@ietf.org<mailto:spring@ietf.org>> Cc: 6man Chairs <6man-cha...@ietf.org<mailto:6man-cha...@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 i...@ietf.org<mailto:i...@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$>
_______________________________________________ spring mailing list spring@ietf.org https://www.ietf.org/mailman/listinfo/spring
