[spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-spring-srv6-network-programming-20: 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 IESG DISCUSS and COMMENT positions.


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



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

The current requirement that IANA-assigned SRv6 Endpoint Behavior
codepoints are used, with no range reserved for local assignment, seems
to be inviting codepoint squatting from the nominally reserved range.
Why is there an absolute requirement for registration (even FCFS)
without ranges for local or experimental use?  (What are the various
reserved ranges reserved for?)

The (normative) pseudocode does not seem to handle the case when the SRH
is omitted for the degenerate case where there is only a single segment,
or for the PSP flavor.

The pseudocode for the PSP and USP procedures seem incorrect -- Hdr Ext
Len is measured in units of 8 octets, and does not include the first 8
octets of the extension header, but Payload Length is measured in
octets.  Literally decreasing the Payload Length by the Hdr Ext Len
value will produce a malformed IPv6 packet.

If "PSP operation is deterministically controlled by the SR Source
Node", why do we need to define behavior codepoints that (for example)
use both PSP and USP?  I don't see how there is full determinism in this
case while being different from the "PSP only" flavor.

There are numerous factual errors and un/under-specified protocol
behavior (see COMMENT), including: how to set the outer Hop Limit
(multiple instances), the order of segments in the SRH, specification of
headend behavior by reference to informal example, L2 frame
en/decapsulation procedures, and the "Opaque" note for endpoint behavior
65535.

A discussion topic, which may or may not entail changes to this
document: RFC 8200 notes that specifications of new extension headers
need to indicate their ordering constraints with respect to the other
extension headers, but RFC 8754 makes no such indications.  Are there in
practice ordering constraints that we should attempt to document?


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

I note that this document references
draft-filsfils-spring-srv6-net-pgm-illustration, which uses
the IPv4 CIDR 20/8 in examples instead of addresses from the RFC 5737
range.  It would be disappointing to have a PS refer to a draft that
squats on the IPv4 namespace in such a manner.

Abstract, Introduction

   This document defines the SRv6 Network Programming concept and
   specifies the base set of SRv6 behaviors that enables the creation of
   interoperable overlays with underlay optimization (Service Level
   Agreements).

I don't understand what the parenthetical is intending to convey.

Section 2

   The following terms used within this document are defined in
   [RFC8402]: Segment Routing, SR Domain, Segment ID (SID), SRv6, SRv6
   SID, SR Policy, Prefix SID, and Adjacency SID.

[RFC 8402 spells it Prefix-SID (with hyphen) and Adj-SID.]

Section 3

The text allegedly reproduced from RFC 8754 §4.3 differs in case and
hyphenation.

Section 3.1

   This document defines an SRv6 SID as consisting of LOC:FUNCT:ARG,
   where a locator (LOC) is encoded in the L most significant bits of
   the SID, followed by F bits of function (FUNCT) and A bits of
   arguments (ARG).  L, the locator length, is flexible, and an operator
   is free to use the locator length of their choice.  F and A may be
   any value as long as L+F+A <= 128.  When L+F+A is less than 128 then
   the remaining bits of the SID MUST be zero.

Why does A have to be a fixed value; can't it safely be a function of F
(even if we exclude things like huffman coding for F)?

   An SRv6 Segment Endpoint Behavior may require additional information
   for its processing (e.g. related to the flow or service).  This
   information may be encoded in the ARG bits of the SID.

(Assuming that it can be sufficiently compactly encoded?)

   The ARG value of a routed SID SHOULD remain constant among packets in
   a given flow.  Varying ARG values among packets in a flow may result

(Thus limiting the type of information that can be represented in the
ARG?)

Section 3.2

   SIDs.  The provider historically deployed IPv6 and assigned
   infrastructure addresses from a portion of the fc00::/7 prefix.  They
   further subdivided the prefix into three /48 prefixes (Country X,
   Country Y, Country Z) to support their SRv6 infrastructure.  From
   those /48 prefixes each router is assigned a /64 prefix from which
   all SIDs of that router are allocated.

This is not the language I would have expected for use of the ULA
address range.  It looks like this may be related to Erik Kline's
Discuss point...

   IPv6 address consumption in both these examples is minimal,
   representing one billionth and one millionth of the assigned address
   space, respectively.

I'm not sure I understand the calculation that produced these values.

   An SR Source Node cannot infer the behavior by examination of the
   FUNCT value of a SID.

   Therefore, the SRv6 Endpoint Behavior codepoint is advertised along
   with the SID in the control plane.

These two sentences feel a little out of place in this spot, occurring
after previous discussion that the endpoint behavior codepoint is
advertised in the control plane.

   o  At Router 3, within the locator 2001:db8:bbbb:3::/64, network
      operator or the router performs dynamic assignment for:

nit: missing article ("the network operator").

      *  Function 100 associated with the behavior End.X (Endpoint with
         cross-connect) between router 3 and its connected neighbor
         router, for example Router 4.  This function is encoded as
         16-bit value and has no arguments.

Please clarify that "function 100" is a hex literal.

I also suggest noting clearly at the start of the example that F is 16
and A is 0.

      *  Function 101 associated with the behavior End.X (Endpoint with
         cross-connect) between router 3 and its connected neighbor
         router, for example Router 2.  This function is encoded as
         16-bit value and has no arguments.

F is a constant for the SR domain; saying it at each SID assignment is
misleading.

[same note about hex for 101]

Section 4

   The list is not exhaustive.  In practice, any function can be
   attached to a local SID: e.g. a node N can bind a SID to a local VM
   or container which can apply any complex processing on the packet.

Yes, but it can't advertise the behavior corresponding to that function
without a codepoint.

Section 4.1.1

   When processing the Upper-layer Header of a packet matching a FIB
   entry locally instantiated as an SRv6 End SID, if Upper-layer Header
   processing is allowed by local configuration (e.g.  ICMPv6), then

nit: the parenthetical is placed so as to apply to "local
configuration", which doesn't really make sense; I presume the intent is
to say that upper-layer header processing is allowed *for that
upper-layer protocol*.  Also, comma after "e.g.".

   problem message to the Source Address and discard the packet.  Error
   code 4 (SR Upper-layer Header Error) and Pointer set to the offset of
   the upper-layer header.

nit: this is not a complete sentence.

Section 4.2

   It is the SRv6 instantiation of an Adjacency-SID [RFC8402] and it is
   required to express any traffic-engineering policy.

This text reads as if End.X specifically is required for TE, which does
not seem correct to me.

Section 4.4, 4.5

                                        This is equivalent to the per-CE
   VPN label in MPLS [RFC4364].

The phrase "per-CE VPN" does not appear in RFC 4364.

Section 4.5

   S05.  If the End.DX4 SID is bound to an array of L3 adjacencies, then
   one entry of the array is selected based on the hash of the packet's
   header Section 7.

nit: I suggest "(see Section 7)" to match section 4.4.

Section 4.6, 4.7

   is required.  This is equivalent to the per-VRF VPN label in MPLS
   [RFC4364].

The phrase "per-VRF VPN" does not appear in RFC 4364.
(A similar comment applies to Section 4.8 as well.)

   Note that an End.DT6 may be defined for the main IPv6 table in which
   case and End.DT6 supports the equivalent of an IPv6inIPv6

nit: s/and/an/

Section 4.7

   The "Endpoint with decapsulation and specific IPv4 table lookup"
   behavior (End.DT4 for short) is a variant of the End behavior.

nit: variant of End.T, just like End.DT6, no?

Section 4.9

   S04.  An End.DX2 behavior could be customized to expect a specific
   IEEE header (e.g.  VLAN tag) and rewrite the egress IEEE header
   before forwarding on the outgoing interface.

Would this customized behavior require a new codepoint?
Similarly for End.DX2V (Section 4.10)

Section 4.10

   S04. Remove the outer IPv6 Header with all its extension headers,
           lookup the exposed VLANs in L2 table T, and forward
           via the matched table entry.

Just to check my understanding: the "exposed VLANs" (plural?!) are in
the Ethernet header of the packet that we are left with after removing
the outer IPv6 header, right?

   S01.  IANA has allocated the Internet Protocol number 143 to Ethernet
   (see Section 10.1).

This seems like a copy/paste leftover from End.DX2 -- we don't mention
143 in this section.

Section 4.12

   Two of the applications of the End.DT2M behavior are the EVPN
   Bridging of broadcast, unknown and multicast (BUM) traffic with
   Ethernet Segment Identifier (ESI) filtering and the EVPN ETREE use-
   cases.

Are there references for either/both of these?

   S04. Remove the IPv6 header and all its extension headers

nit: the rest of the document uses "Remove the outer IPv6 header with
all its extension headers".

   S06. Forward via all L2 OIFs excluding the one specified in Arg.FE2

nit: s/one/ones/

   Arg.FE2 is encoded in the SID as an (k*x)-bit value.  These bits
   represent a list of up to k OIFs, each identified with an x-bit
   value.  Values k and x are defined on a per End.DT2M SID basis.  The
   interface identifier 0 indicates an empty entry in the interface
   list.

(editorial) rather than have to come up with the concept of an "empty
entry" in the interface list, I would probably just say that the
identifier 0 is reserved and is ignored when doing the exclusion of
OIFs.

I also think we need to say that the order and identifier assignment of
elements of the interface list (that is, what the x-bit values index
into) is under the local control of N, but has to remain stable as long
as SIDs are advertised that list members of the list in ARG.  (There is
otherwise a great deal of freedom in assignment since the values are
only consumed by the node that advertises them.)

Section 4.13

It's probably worth calling out the MTU considerations of pushing the
new IPv6 header+SRH and tunneling the packets.  (I know we reference
2473 already, but the MTU is pretty important.)

   S17.  The Payload Length, Traffic Class and Next-Header fields are
   set as per [RFC2473].  The Flow Label is computed as per [RFC6437].

How is the Hop Limit set for the outer header?
(I assume §6.3 of RFC 2473, but given that you provide a reference for
all the other fields, it seems like an omission to not mention Hop Limit
as well.)

Section 4.14

   The SRH MAY be omitted when the SRv6 Policy only contains one segment
   and there is no need to use any flag, tag or TLV.

If this is the case does it matter if I use End.B6.Encaps or
End.B6.Encaps.Red?

Section 4.16

I don't think I understand what it would mean for a specific SID to
support the multiple flavors "in combinations".

Section 4.16.1.2

   A penultimate SR Segment Endpoint Node is one that, as part of the
   SID processing, copies the last SID from the SRH into the IPv6
   Destination Address and decrements Segments Left value from one to
   zero.

I think technically it copies the first SID from the SRH (SRH.Segment
List[0]), which is the last SID from the SR Policy.
Also, nit: "the" for "the Segments Left value".

 S14.2.      Update the Next Header field in the preceding header to the
                Next Header value of the SRH

nit: personally, I would write "from the SRH", since "next header value
of the SRH" is very close to "next header value of SRH", i.e., 43.

   As a reminder, [RFC8754] defines in section 5 the SR Deployment Model
   within the SR Domain [RFC8402].  Within this framework, the
   Authentication Header (AH) is not used to secure the SRH as described
   in Section 7.5 of [RFC8754].

I strongly recommend adding another sentence clarifying why this is
relevant to discussion of removing an extension header from the packet.

Section 5

   This list can be expanded in case any new functionality requires it.

How?  By an RFC that Updates: this one?

Section 5.x

I agree with the directorate reviewer that the protocol behavior should
be written out explicitly, without reference to the handling of example
packet(s).

Section 5.1

   S03.   Set outer payload length, traffic class and flow label

What about the outer Hop Limit?

   S03: As described in [RFC6437] (IPv6 Flow Label Specification)

Why is this all the way at the bottom of the section instead of included
with the corresponding content?

Section 5.3

   The encapsulating node MUST remove the preamble or frame check
   sequence (FCS) from the Ethernet frame upon encapsulation and the
   decapsulating node MUST regenerate the preamble or FCS before
   forwarding Ethernet frame.

"or"?  I get to choose one or the other?  It's okay to only put back a
preamble but no FCS (or vice versa)?

Section 6

   traffic that matched that SID and was processed correctly.  The
   retrieval of these counters via MIB, NETCONF/YANG or any other means
   is outside the scope of this document.

(editorial) a MIB is an abstract data structure (likewise a YANG
module); information might be retrieved *from* it but not *via* it.  For
*via*, that would be SNMP, NETCONF, and/or RESTCONF.

Section 8.1

Does it make sense to reference RFCs 8491, 8476, 8841, etc. for
advertising MSD via IGP?

   In particular, the SR source (e.g., H.Encaps), intermediate endpoint
   (e.g., End, End.X) and final endpoint (e.g., End.DX4, End.DT6)
   behaviors.  [...]

This is not a complete sentence, and I really have no idea what verb was
intended.

Section 8.2, 8.3

Can we get references for the BGP variants here and their usage for
signaling SRv6 capabilities and (SID,behavior codepoint) pairs?

Section 9

I would really like to have a stronger reference to Section 5 of RFC
8754 where the conceptual model of a SR Domain as a single system, where
all packets in the domain are encapsulated using IPv6 headers [with SIDs
as SA/DA].  The part in brackets is not spelled out very clearly and
could well be expounded upon in this document.  I can write up some
(very ad hoc) ideas for what I had in mind, which you are welcome to
adopt but expected to wordsmith/edit appropriately:

% Section 5 of [RFC8754] describes the SR deployment model and the
% baseline requirements for securing the SR Domain.  In many ways the SR
% Domain is analogous to an MPLS domain -- it's a tightly controlled
% system where packet processing is controlled by a list (or stack) of
% opaque identifiers that, by and large, only have defined semantics in
% the context of the node that receives and processes the packet when
% that identifier is "topmost" or "current".  Experience in securing and
% operating MPLS domains should be readily transferrable to SRv6
% domains, in ensuring that all traffic within the network is tightly
% controlled, with all external inputs being properly encapsulated (for
% SRv6, by an IPv6 header usually with SRH; for MPLS, by the label
% stack).  The dedicated format for the MPLS label stack and label
% identifiers makes a clear mechanical separation between "internal" and
% "external" identifiers. In contrast, SRv6 uses SIDs for the internal
% identifiers, which have format and operation of IPv6 addresses.  While
% this lets SRv6 benefit from IP longest-prefix routing and thus the
% structure of SID values, it also means that there is not a crisp
% mechanical separation between "internal" and "external" identifiers.
% As such, care and rigor in annotating which IPv6 addresses/headers are
% internal vs external is required in order to maintain the integrity
% and security of the SRv6 domain.

There might also be room for discussion (in the main body of the
document) of how the various decapsulation procedures occur precisely
when the packet is leaving the SR Domain.

Having the ARG structure specified as part of the behavior codepoint
registration means that a node that can apply that SID can also spoof
the ARG to force a different (e.g.) outgoing interface list.
Specifically, it gives the attacker a degree of freedom greater than
just the SID behaviors that the node advertises.  The HMAC TLV would
mitigate this to the extent that it limits what SIDs the node in
question is allowed to apply and what changes can be made on-path.

   services.  Additionally, [RFC8754] defines an HMAC TLV permitting SR
   Endpoint Nodes in the SR domain to verify that the SRH applied to a
   packet was selected by an authorized party and to ensure that the
   segment list is not modified after generation, regardless of the
   number of segments in the segment list.  When enabled by local

I suggest adding a sentence similar to "(This does, however, require
that the segment list, and thus, the SRH is present in the packet; the
optional ability to elide the SRH when there is only a single segment
and no flags, tags, or TLVs needed inherently excludes the protection of
the HMAC TLV.)"

Section 10.1

   definition: The value 143 in the Next Header field of an IPv6 header
   or any extension header indicates that the payload is an Ethernet
   [IEEE.802.3_2018].

nit: is there a missing word here ("frame"?)?