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

["Zafar Ali (zali)" <[e-mail]>]

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)" <[e-mail]>
Date: Thursday, April 1, 2021 at 12:56 AM
To: Matt Joras <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "Zafar Ali (zali)" <[e-mail]>
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 <[e-mail]>
Reply-To: Matt Joras <[e-mail]>
Date: Friday, March 12, 2021 at 9:14 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Genart last call review of draft-ietf-6man-spring-srv6-oam-09
Resent-From: <[e-mail]>
Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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