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

[Benjamin Kaduk <[e-mail]>]

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

On Thu, Jun 03, 2021 at 01:31:29PM +0000, Zafar Ali (zali) wrote:
> 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 <[e-mail]>
> Reply-To: Benjamin Kaduk <[e-mail]>
> Date: Wednesday, June 2, 2021 at 10:08 PM
> To: The IESG <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Benjamin Kaduk's Discuss on draft-ietf-6man-spring-srv6-oam-11: (with DISCUSS and COMMENT)
> Resent-From: <[e-mail]>
> Resent-To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
> Resent-Date: Wednesday, June 2, 2021 at 10:08 PM
> 
> 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
> 
> 
> 
>