[spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
Benjamin Kaduk via Datatracker <firstname.lastname@example.org> Thu, 24 September 2020 07:43 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5FB93A08DB; Thu, 24 Sep 2020 00:43:38 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Benjamin Kaduk via Datatracker <email@example.com>
To: "The IESG" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com, Bruno Decraene <firstname.lastname@example.org>, Joel Halpern <email@example.com>, firstname.lastname@example.org
Reply-To: Benjamin Kaduk <email@example.com>
Date: Thu, 24 Sep 2020 00:43:38 -0700
Subject: [spring] Benjamin Kaduk's Discuss on draft-ietf-spring-srv6-network-programming-20: (with DISCUSS and COMMENT)
List-Id: "Source Packet Routing in NetworkinG \(SPRING\)" <spring.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spring>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spring>, <mailto:email@example.com?subject=subscribe>
X-List-Received-Date: Thu, 24 Sep 2020 07:43:39 -0000
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 220.127.116.11 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), 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"?)?
- [spring] Benjamin Kaduk's Discuss on draft-ietf-s… Benjamin Kaduk via Datatracker