Hi Matt, Many thanks for the offline review of the diffs. Greatly appreciated!
We have posted the diffs discussed earlier in rev 10 of the draft. https://datatracker.ietf.org/doc/html/draft-ietf-6man-spring-srv6-oam-10 How the diffs addresses your comments are mentioned in-line with [ZA] (in the earlier email). Please review and advise of any additional comments. Thanks Regards … Zafar From: "Zafar Ali (zali)" <z...@cisco.com> Date: Thursday, April 1, 2021 at 12:56 AM To: Matt Joras <matt.jo...@gmail.com>, "gen-art@ietf.org" <gen-art@ietf.org> Cc: "draft-ietf-6man-spring-srv6-oam....@ietf.org" <draft-ietf-6man-spring-srv6-oam....@ietf.org>, "i...@ietf.org" <i...@ietf.org>, "last-c...@ietf.org" <last-c...@ietf.org>, "Zafar Ali (zali)" <z...@cisco.com> Subject: Re: Genart last call review of draft-ietf-6man-spring-srv6-oam-09 Hi Matt, Many thanks for your review and comments; much appreciated. Please see [ZA] in line. We are editing the document to address all comments and will upload a latest version once all edits are done. These comments include a pending comment from our AD: s/2001:DB8/2001:db8/g in accordance with RFC 5952 section 4.3. Thanks Regards … Zafar From: Matt Joras via Datatracker <nore...@ietf.org> Reply-To: Matt Joras <matt.jo...@gmail.com> Date: Friday, March 12, 2021 at 9:14 PM To: "gen-art@ietf.org" <gen-art@ietf.org> Cc: "draft-ietf-6man-spring-srv6-oam....@ietf.org" <draft-ietf-6man-spring-srv6-oam....@ietf.org>, "i...@ietf.org" <i...@ietf.org>, "last-c...@ietf.org" <last-c...@ietf.org> Subject: Genart last call review of draft-ietf-6man-spring-srv6-oam-09 Resent-From: <alias-boun...@ietf.org> Resent-To: <z...@cisco.com>, <cfils...@cisco.com>, <satoru.matsush...@g.softbank.co.jp>, <daniel.vo...@bell.ca>, <mach.c...@huawei.com>, <bob.hin...@gmail.com>, <otr...@employees.org>, <ek.i...@gmail.com>, <evyn...@cisco.com>, "o...@cisco.com" <o...@cisco.com>, "o...@cisco.com" <o...@cisco.com> Resent-Date: Friday, March 12, 2021 at 9:14 PM Reviewer: Matt Joras Review result: Ready with Nits 1. Introduction As Segment Routing with IPv6 data plane (SRv6) [RFC8402] simply adds a new type of Routing Extension Header, existing IPv6 OAM mechanisms can be used in an SRv6 network. This document describes how the existing IPv6 mechanisms for ping and trace route can be used in an SRv6 network. This includes illustrations of pinging an SRv6 SID for the SID connectivity checks and to validate the availability of a SID. This also includes illustrations for tracerouting to an SRv6 Trace route is spelled as two words here rather than a compound elsewhere. [ZA] Changed it to traceroute 2.1.1. O-flag Processing ... 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-bit will not be processed at the ultimate segment. This paragraph refers to it as the O-bit rather than the O-flag. [ZA] Changed it to O-flag. 2.2. OAM Operations ... Ping to a SID is used for SID connectivity checks and to validate the availability of a SID. Traceroute to a SID is used for hop-by-hop fault localization as well as path tracing to a SID. Section 3 illustrates the ICMPv6 based ping and the UDP based traceroute mechanisms for ping and traceroute to an SRv6 SID. Although this document only illustrates ICMP ping and UDP-based traceroute to an SRv6 SID, the procedures are equally applicable to other IPv6 OAM probing to an SRv6 SID (e.g., Bidirectional Forwarding Detection (BFD) [RFC5880], Seamless BFD (SBFD) [RFC7880], TWAMP Light and STAMP probe message processing as described in [I-D.gandhi-spring-twamp- srpm] and [I-D.gandhi-spring-stamp-srpm], respectively, etc.). Specifically, as long as local configuration allows the Upper-layer Header processing of the applicable OAM payload for SRv6 SIDs, the existing IPv6 OAM techniques can be used to target a probe to a (remote) SID. This paragraph mixes "ICMPv6 based ping" and "ICMP ping". There is also not consistency with "-based", e.g. "UDP-based" versus "UDP based". [ZA] changed ICMP to ICMPv6; changed UDP-based to UDP based. The reference link to [I-D.gandhi-spring-twamp-srpm] is not functional. [ZA] Fixed IPv6 OAM operations can be performed with the target SID in the IPv6 destination address without SRH or with SRH where the target SID is the last segment. In general, OAM operations to a target SID may not exercise all of its processing depending on its behavior definition. For example, ping to an END.X SID (refer [I-D.ietf-spring-srv6- network-programming]) at the target node only validates availability of the SID and does not validate switching to the correct outgoing interface. To exercise the behavior of a target SID, the OAM operation SHOULD construct the probe in a manner similar to a data packet that exercises the SID behavior, i.e. to include that SID as a transit SID in either an SRH or IPv6 DA of an outer IPv6 header or as appropriate based on the definition of the SID behavior. The reference to [I-D.ietf-spring-srv6-network-programming] is not functional and "refer" before it reads awkwardly. [ZA] Updated the reference and fixed the awkwardly (“refer [ref]”) text. 3.1.1. Classic Ping If an SRv6 capable ingress node wants to ping an IPv6 address via an arbitrary segment list <S1, S2, S3>, it needs to initiate ICMPv6 ping with an SR header containing the SID list <S1, S2, S3>. This is illustrated using the topology in Figure 1. Assume all the links have IGP metric 10 except both links between N2 and N3, which have IGP metric set to 100. User issues a ping from node N1 to a loopback of node 5, via segment list <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. The SID behavior used in the example is End.X SID (refer [I-D.ietf- spring-srv6-network-programming]) but the procedure is equally applicable to any other (transit) SID type. Suggest "initial an ICMPv6 ping". "IGP" is not defined here or subsequently in the document. Another broken reference, and the "refer" language. [ZA] Added IGP to terminology section; fixed “refer” text. “initiate” is IMO a better fit than “initial”. ... o The echo request packet at N5 arrives as an IPv6 packet with or without an SRH. If N5 receives the packet with SRH, it skips SRH processing (SL=0). In either case, Node N5 performs the standard IPv6/ ICMPv6 processing on the echo request and responds with the echo reply message. The echo reply message is IP routed. "IPv6/ ICMPv6" is a typo, suggest just being ICMPv6 as the latter implies the former. [ZA] Fixed 3.1.2. Pinging a SID The classic ping described in the previous section applies equally to perform SID connectivity checks and to validate the availability of a remote SID. This is explained using an example in the following. The example uses ping to an END SID (refer [I-D.ietf-spring-srv6- network-programming]) but the procedure is equally applicable to ping any other SID behaviors. Broken reference to [I-D.ietf-spring-srv6-network-programming] and same refer language. [ZA] Fixed 3.2.1. Classic Traceroute ... If an SRv6 capable ingress node wants to traceroute to IPv6 address via an arbitrary segment list <S1, S2, S3>, it needs to initiate traceroute probe with an SR header containing the SID list <S1, S2, S3>. That is illustrated using the topology in Figure 1. Assume all the links have IGP metric 10 except both links between N2 and N3, which have IGP metric set to 100. User issues a traceroute from node N1 to a loopback of node 5, via segment list <2001:DB8:B:2:C31::, 2001:DB8:B:4:C52::>. The SID behavior used in the example is End.X SID (refer [I-D.ietf-spring-srv6-network-programming]) but the procedure is equally applicable to any other (transit) SID type. Figure 3 contains sample output for the traceroute request. Reference works here. But again "refer" language. [ZA] Fixed ... The information about the IP address of the incoming interface on which the traceroute probe was received by the reporting node is very useful. This information can also be used to verify if SIDs 2001:DB8:B:2:C31:: and 2001:DB8:B:4:C52:: are executed correctly by N2 and N4, respectively. Specifically, the information displayed for the second hop contains the incoming interface address 2001:DB8:2:3:31:: at N3. This matches with the expected interface bound to END.X behavior 2001:DB8:B:2:C31:: (link3). Similarly, the information displayed for hop5 contains the incoming interface address 2001:DB8:4:5::52:: at N5. This matches with the expected interface bound to the END.X behavior 2001:DB8:B:4:C52:: (link10). The first sentence of this paragraph is awkwardly, perhaps just verbosely phrased. Suggest rephrasing along the lines of "The IP address of the interface on which the traceroute probe was received is useful." [ZA] Fixed 3.3. A Hybrid OAM Using O-flag ... The illustration is different than the In-situ OAM defined in [I.D- draft-ietf-ippm-ioam-data]. This is because In-situ OAM records operational and telemetry information in the packet as the packet traverses a path between two points in the network [I.D-draft-ietf- ippm-ioam-data]. The illustration in section 3 does not require the recording of OAM data in the packet. Broken reference to [I.D-draft-ietf-ippm-ioam-data] [ZA] Fixed ... Consider the example where the user wants to monitor sampled IPv4 VPN 999 traffic going from CE1 to CE2 via a low latency SR policy P installed at Node N1. To exercise a low latency path, the SR Policy P forces the packet via segments 2001:DB8:B:2:C31:: and 2001:DB8:B:4:C52::. The VPN SID at N7 associated with VPN 999 is 2001:DB8:B:7:DT999::. 2001:DB8:B:7:DT999:: is a USP SID. N1, N4, and N7 are capable of processing SRH.Flags.O-flag but N2 is not capable of processing SRH.Flags.O-flag. N100 is the centralized controller capable of processing and correlating the copy of the packets sent from nodes N1, N4, and N7. N100 is aware of SRH.Flags.O-flag processing capabilities. Controller N100 with the help from nodes N1, N4, N7 and implements a hybrid OAM mechanism using the SRH.Flags.O-flag as follows: Is it reasonable to assume understanding of "VPN 999 traffic", "CE1", "CE2", and "low latency SR policy P"? [ZA] Yes, IMP. ... o When node N2 receives the packet with SRH.Flags.O-flag set, it ignores the SRH.Flags.O-flag. This is because node N2 is not capable of processing the O-flag. Node N2 performs the standard SRv6 SID and SRH processing. Specifically, it executes the END.X (refer [I-D.ietf-spring-srv6-network-programming]) behavior (2001:DB8:B:2:C31::) and forwards the packet P1 (2001:DB8:A:1::, 2001:DB8:B:4:C52::) (2001:DB8:B:7:DT999::, 2001:DB8:B:4:C52::, 2001:DB8:B:2:C31::; SL=1; O-flag=1; NH=IPv4)(IPv4 header)(payload) over link 3 towards Node N3. Inconsistent use of "SRH.Flags.O-flag" versus simply "O-flag". [ZA] Fixed; :s/ SRH.Flags.O-flag/ O-flag/g 3.4. Monitoring of SRv6 Paths ... In the reference topology in Figure 1, N100 uses an IGP protocol like OSPF or ISIS to get the topology view within the IGP domain. N100 can also use BGP-LS to get the complete view of an inter-domain topology. The controller leverages the visibility of the topology to monitor the paths between the various endpoints. "OSPF" and "ISIS" are not defined, and neither is "BGP-LS". [ZA] Added to terminology section The controller N100 advertises an END (refer [I-D.ietf-spring-srv6- network-programming]) SID 2001:DB8:B:100:1::. To monitor any arbitrary SRv6 paths, the controller can create a loopback probe that originates and terminates on Node N100. To distinguish between a failure in the monitored path and loss of connectivity between the controller and the network, Node N100 runs a suitable mechanism to monitor its connectivity to the monitored network. Broken reference to [I-D.ietf-spring-srv6-network-programming], and another use of "refer". [ZA] Fixed, globally
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
