Re: [Gen-art] Genart last call review of draft-ietf-6man-spring-srv6-oam-09

[Lars Eggert <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gen-art