Subject: Benjamin Kaduk's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 02 Jun 2021 19:08:10 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6man-spring-srv6-oam-11: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-spring-srv6-oam/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

In Section 3.1.2, we say that:

   o  If the target SID (2001:db8:B:4::) is not locally instantiated,
      the packet is discarded

However, RFC 8754 §4.3.2 seems to say that the next header is processed
in this case.   Only if the target SID is both not locally instantiated
and does not represent a local interface will the packet be discarded,
if I understand correctly.  (Similarly for the analogous statement in
§3.2.2.)

There's also quite a few other internal incosistencies in this document,
such as copy/paste chunks that refer to "N4" as executing a given SID in
a scenario where it is actually a different node doing so, many
instances where a given IP address or SID does not match up with the
addressing structure listed in Section 1.3, places where we seem to say
that an SR ingress node can be a classic IPv6 node that lacks SRv6
capabilities, etc.  Individually, many of
these would be nit-level (and indeed are called out specifically in the
NITS section of my ballot comment), but collectively they seem to
indicate a document that is not yet in publishable state.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Dan Harkins for the secdir review and Stig Venaas for the
opsdir review (with observation on the security considerations) and the
authors for updating in response to them.  I support Roman's discuss
position to make the remaining updates.

The setup introducing a couple of the examples mentions the assumed link
metric on the links in question, but none of the procedures we describe
actually make use the assumed metric information -- it seems we could
just as easily omit mention of it.

Section 1.3

      Nodes N3, N5 and N6 are IPv6 nodes that are not SRv6-capable.
      Such nodes are referred as classic IPv6 nodes.

Can I suggest using a different adjective than "classic" for this, perhaps
"standard"?  The word "classic" can come with some connotations of being
old, outdated, or legacy, and I don't think we have IETF consensus that
SRv6 is the next evolution of IPv6 that relegates "classic IPv6" to such
a legacy status.

      A SID at node k with locator block 2001:db8:B::/48 and function F
      is represented by 2001:db8:B:k:F::.
   [...]
      2001:db8:B:k:Cij:: is explicitly allocated as the END.X SID at
      node k towards neighbor node i via jth Link between node i and
      node k.  e.g., 2001:db8:B:2:C31:: represents END.X at N2 towards

What is the "function F" in this example?  My understanding was that the
function would correspond to just End.X (and thus the value "C" for that
16-bit component), with the "ij" information needing to be in the
"argument".

Section 2.1.1

   The O-flag in SRH is used as a marking-bit in the user packets to
   trigger the telemetry data collection and export at the segment
   endpoints.

If it's to be set in "user packets", who exactly is it that sets the mark?

   controller for monitoring and analytics.  Similarly, without the loss
   of generality, this document assumes requested information elements
   are configured by the management plane through data set templates
   (e.g., as in IPFIX [RFC7012]).

Can we say anything about the scope for which the set of requested
information elements are configured?  I mostly assume that it's expected
to, say, configure node A to export some information on seeing the
O-flag, and configure node B to export different information on seeing
the O-flag.  But can it be configured at a finer granularity than just
"node", e.g., at a per-flow level?

   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-flag will not be processed at the
   ultimate segment.

This looks like a statement of fact to me, with no need to strengthen it
by normative langauge.  If you need telemetry from the ultimate segment,
and PSP is used, you won't get telemetry based on the SRH O-flag, and
that's that.

Section 2.2

   IPv6 OAM operations can be performed for any SRv6 SID whose behavior
   allows Upper Layer Header processing for an applicable OAM payload
   (e.g., ICMP, UDP).

What options are available for SIDs whose behavior does not allow such
ULH processing?

   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.

I think I understand what is meant by putting the target SID as a
transit SID in a SRH (or encapsulated analogue).  I'm not sure how this
would specifically validate that the node is exercising the behavior in
question (End.X here, so switching to the proper outgoing interface).
That is, if I'm trying to ping a given SID and confirm that it does
End.X properly, how does just adding an SRH confirm the cross-connect
part if I am still pinging that SID?  Do I need to target the ping at
the "next" SID in the SID list in order to actually use the
cross-connect?

Section 3.1.1

   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::>.

How does a *user* issue a ping (directly) with an associated segment
list?  This seems to no longer be a "classic ping" mechanism as written
... perhaps there is some automated component in the system that
translates what the user put in the packet into a segment list?  Or
should we reference some ping utility that is patched to accept
segment-list input in the vein of Figure 2?
(A similar comment applies to the traceroute analogue in Section 3.2.1.)

   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
      ICMPv6 processing on the echo request and responds with the echo
      reply message to N1.  The echo reply message is IP routed.

I think the tsv-art reviewer's remark that "the echo reply message is IP
routed" could hide quite a lot, is pretty accurate.  It seems worth
stating clearly that it does not have an SRH so that the reader can work
through the consequences for deployments where there is no native IP
connectivity for the return path.

Section 3.2

   operation at the classic IPv6 nodes in an SRv6 network.  That
   includes the classic IPv6 node with ingress, egress or transit roles.

I'm a little confused at what it would mean for a "classic IPv6" node to
act as the *ingress* role.  What is ingress, if not entrance to the SR
domain and applying an SRH?

Section 3.2.1, 3.2.2

Where do the 2001:db8:1:2:21::, 2001:db8:2:3:31::, 2001:db8:3:4::41::,
2001:db8:4:5::52:: come from?  They don't seem to match the stated
structure for "nth link between node i and j at the i side"
(2001:db8:i:j:in::); was there supposed to be a separate case for "at
the j side" in the terminology section?

Section 3.3

   o  The controller N100 processes and correlates the copy of the
      packets sent from nodes N1, N4 and N7 to find segment-by-segment
      delays and provide other hybrid OAM information related to packet
      P1.

If the controller is going to coalesce timestamped data from the various
SRv6 nodes, we need to have some discussion of the requirement for
synchronized time across the SR domain (or controller knowledge of time
offsets, which is essentially equivalent).

Section 5

   service attack.  Additionally, SRH Flags are protected by the HMAC
   TLV, as described in Section 2.1.2.1 of [RFC8754].

I think we should remind the reader that the HMAC protection is very
coarse-grained, and that once an HMAC exists that allows setting the
O-flag for a given segment list, it can be used to produce an arbitrary
amount of such traffic.

   This document does not impose any additional security challenges to
   be considered beyond security threats described in [RFC4884],
   [RFC4443], [RFC0792], and [RFC8754].

We might add RFC 8986 to this list, since we are using its endpoint
behaviors in our examples.

NITS

Secton 1

   any nodes within an SRv6 domain.  Specifically, the document
   illustrates how a centralized monitoring system can monitor arbitrary
   SRv6 paths by creating the loopback probes that originates and
   terminates at the centralized monitoring system.

singular/plural mismatch "probes" vs "originates and terminates".

Section 1.3

      The IPv6 address of the nth Link between node i and j at the i
      side is represented as 2001:db8:i:j:in::, e.g., the IPv6 address
      of link6 (the 2nd link) between N3 and N4 at N3 in Figure 1 is
      2001:db8:3:4:32::.  Similarly, the IPv6 address of link5 (the 1st
      link between N3 and N4) at node 3 is 2001:db8:3:4:31::.

The expansion of "in" as the contatnation of node index i and link index
n was confusing to me on first reading.  Also, it's not entirely clear
what ordering is used for the "first link" between a given pair of
nodes, since the links themselves are given absolute indices as opposed
to indices scoped to a given pair of nodes.  (Why does 'i' need to be in
the address twice, anyway?)

      2001:db8:B:k:Cij:: is explicitly allocated as the END.X SID at
      node k towards neighbor node i via jth Link between node i and
      node k.  e.g., 2001:db8:B:2:C31:: represents END.X at N2 towards

I suggest using 'n' for the link again (instead of repurposing 'j' which
used to be a node).

(Also, RFC 8986 spells it "End.X" with two minuscule and two majuscule
letters.  Similarly for just "End", as "END" appears later on in the
document.)

Section 2.1.1

   When N receives a packet whose IPv6 DA is S and S is a local SID, the
   line S01 of the pseudo-code associated with the SID S, as defined in
   section 4.3.1.1 of [RFC8754], is appended as follows for the O-flag
   processing.

Seeing "S" right after "DA" primes me to think about "source", not
"SID"; would a different label be workable?
Also, I'd s/appended/appended to/

      Ref1: An implementation SHOULD copy and record the timestamp as
      soon as possible during packet processing. Timestamp or any other
      metadata is not
      carried in the packet forwarded to the next hop.

The pseudocode does not make the inclusion of timestamp optional for
what's sent to the OAM process, so s/or/and/

Section 3.1.1

   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::>.

s/5/N5/

   Figure 2 contains sample output for a ping request initiated at node
   N1 to the loopback address of node N5 via a segment list

s/the loopback/a loopback/ (to match the previous paragraph).

   o  Node N2, which is an SRv6-capable node, performs the standard SRH
      processing.  Specifically, it executes the END.X behavior
      (2001:db8:B:2:C31::) and forwards the packet on link3 to N3.

I suggest "executes the End.X behavior indicated by the SID
2001:db8:B:2:C31::".  (Similarly for the other End.X behavior in this
example.)

      If 2001:db8:B:4:C52:: is a PSP SID, The penultimate node (Node N4)
      does not, should not and cannot differentiate between the data
s/T/t/

Section 3.1.2

      processing.  Specifically, it executes the END.X behavior
      (2001:db8:B:2:C31::) on the echo request packet.  If

[same comment as above]

Section 3.2.1

   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,

s/initiate/initiate a/

   IPv6 MTU [RFC4443].  The SR header is also included in these ICMPv6
   messages initiated by the classic IPv6 transit nodes that are not
   running SRv6 software.  Specifically, a node generating ICMPv6

I'm not sure why "also" is appropriate here, since the initial example
involves N3, a classit IPv6 node, returning information for link3.  Is
that not a case of a classic IPv6 transit node that is not running SRv6
software and includes the SRH in the ICMPv6 replies that it generates?

   bound to END.X behavior 2001:db8:B:2:C31:: (link3).  Similarly, the
   information displayed for hop5 contains the incoming interface

There is no hop 5; this looks like hop 4 to me.

Section 3.2.2

   of traceroute mechanism.  The UDP encoded message to traceroute a SID
   uses the UDP ports assigned by IANA for "traceroute use".

I don't think we actually show the UDP port anywhere, so phrasing like
"would use the UDP ports assigned by IANA" might be more appropriate.

   o  When Node N2 receives the packet with hop-count > 1, it performs
      the standard SRH processing.  Specifically, it executes the END.X
      behavior (2001:db8:B:2:C31::) on the traceroute probe.  If
      2001:db8:B:2:C31:: is a PSP SID, node N4 executes the SID like any

N2 != N4; I assume this is a copy/paste issue and the "N4" should be
"N2".

   o  If the target SID (2001:db8:B:4::) is locally instantiated, the
      node processes the upper layer header.  As part of the upper layer
      header processing node N4 responses with the ICMPv6 message (Type:

s/responses/responds/

Section 3.3

      packet to be monitored via the hybrid OAM.  Node N1 sets O-flag
      during encapsulation required by policy P.  As part of setting the

"during the encapsulation"

      processing.  Specifically, it executes the END.X behavior
      (2001:db8:B:2:C31::) as described in [RFC8986] and forwards the

[same comment as in §3.1.1; also later in this section]

   o  When node N7 receives the packet P1 (2001:db8:A:1::,
      2001:db8:B:7:DT999::) (2001:db8:B:7:DT999::, 2001:db8:B:4:C52::,
      2001:db8:B:2:C31::; SL=0; O-flag=1; NH=IPv4)(IPv4
      header)(payload), it processes the O-flag.  As part of processing
      the O-flag, it sends a timestamped copy of the packet to a local
      OAM process.  The local OAM process sends a full or partial copy
      of the packet P1 to the controller N100.  The OAM process includes
      the recorded timestamp, additional OAM information like incoming
      and outgoing interface, etc. along with any applicable metadata.
      Node N4 performs the standard SRv6 SID and SRH processing on the

N4 != N7

---

From: "Zafar Ali (zali)" <[email-masked]>
Date: Thu, 3 Jun 2021 13:31:29 +0000

Hi Ben,

Thank you for your review.

You are right. The SID may represent a locally instantiated SRv6 SID or a local interface. We will make the following changes to fix (all instances).

Existing Text> If the target SID (2001:db8:B:4::) is not locally instantiated, the packet is discarded

New Text> If the target SID (2001:db8:B:4::) is not locally instantiated and does not represent a local interface, the packet is discarded

Also many thanks for spotting the various nits. I am sorry, these nits should have been spotted before your review. We will fix these nits and do a thorough review of the document.

Thanks

Regards … Zafar

From: Benjamin Kaduk via Datatracker <[email-masked]>
Reply-To: Benjamin Kaduk <[email-masked]>
Date: Wednesday, June 2, 2021 at 10:08 PM
To: The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Benjamin Kaduk's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]>
Resent-To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent-Date: Wednesday, June 2, 2021 at 10:08 PM

Section 1.3

Section 2.1.1

Section 2.2

Section 3.1.1

Section 3.2

Section 3.2.1, 3.2.2

Section 3.3

Section 5

NITS

Secton 1

Section 1.3

Section 2.1.1

Section 3.1.1

s/5/N5/

Section 3.1.2

[same comment as above]

Section 3.2.1

s/initiate/initiate a/

Section 3.2.2

s/responses/responds/

Section 3.3

N4 != N7

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 Jun 2021 16:06:30 -0700

Thanks, Zafar, for the quick response while you are still on vacation; the
new text below looks like it brings us back into compliance with RFC 8754.
I think the rest can wait until your return, and enjoy your vacation!

-Ben