Matt, thank you for your review. I have entered a No Objection ballot for this document. Lars > On 2021-3-13, at 4:14, Matt Joras via Datatracker <noreply@xxxxxxxx> wrote: > > 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. > > 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. > > 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". The > reference link to [I-D.gandhi-spring-twamp-srpm] is not functional. > > 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. > > 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. > > ... > 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. > > 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. > > 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. > > ... > 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." > > 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] > > ... > 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"? > > ... > 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". > > 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". > > 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". > > > > > _______________________________________________ > Gen-art mailing list > Gen-art@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
Attachment:
signature.asc
Description: Message signed with OpenPGP
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
