Summary: Has a DISCUSS. Needs 2 more YES or NO OBJECTION positions to pass.
I am balloting DISCUSS because the specification is incomplete and not clear enough. I have concerns about both the construction of forwarding entries, including the setting of the tunnel endpoints. (1) Forwarding Entries The procedures in §3.1 seem to want to be specified by example, but I think that this approach doesn't serve the document well as it goes into specifics for the protocols used in the example only (even using Normative language), and doesn't provide a general specification. As §3 says, "the examples in Section 3.1 and Section 3.2 assume that OSPF or ISIS is enabled: in fact, other mechanisms of discovery and advertisement could be used including other routing protocols (such as BGP) or a central controller." I would prefer if the text would talk about the general process first. If the authors think that the examples serve an important function then it's ok to leave them. Others have raised the point about the link state extensions needing to be Normative references. The way the text is written, Normative language is used in some cases to specifically talk about the use of those extensions...so I would agree. Using the extensions just in examples (and not mixing them with specification text) would solve that issue. What would I like to see? For example, the third step talks about "If A and E are in different IGP areas/levels, then..." How does the rest of the text help with understanding how BGP, for example, would be used? In this case I believe that the step can be summarized into the need to advertise the SID and encapsulation with enough information so that the receiver "knows the characteristics of the router that originated the advertisement", even if not in the same routing/flooding domain (maybe: "information MUST be advertised across flooding domain boundaries..." -- I'm sure the authors can come up with better text). Making that (or some text to the effect) the normative statement would be better than using normative language in the example (e.g. "MUST set the "router-ID" field to a valid value") and hoping/expecting for the reader to be able to translate that into whatever makes sense for BGP, or OSPFv3 or the central controller... After the general specification, you can then use an example ("for example, if using OSPF, then the router-ID field is set to a valid value..."). (2) Tunnel Endpoints §2: "The tunnel selected MUST have its remote end point (destination) address equal to the address of the next SR-MPLS capable node along the path (i.e., the egress of the active node segment)." I find this statement misleading and confusing. In the general case the statement is wrong: Yes, the tunnel destination should be the next SR-MPLS node, but that isn't always "the egress of the active node segment". For example, in Figure 2 the SID could direct the traffic to the Egress Router (e.g. using it's Node SID) while having individual tunnels from the Ingress Router to the first SR, then to the next SR, etc., as explained in §3.2.1/3.2.2. I realize that the sentence after the statement above is "This is shown in Figure 1." Figure 1 is a degenerate case of the (almost) general case from Figure 2. Even in the single tunnel (Figure 1) case, "the egress of the active node segment" doesn't have to be R2, it could be another node inside the SR-MPLS network (as R2, being SR-MPLS aware, should be able to forward the frames). As I hopefully explained above, I have two issues with the statement: 1. It is wrong. I think that what makes it wrong is the clarification that "the next SR-MPLS capable node along the path" is "the egress of the active node segment". Taken the text is parenthesis out would solve this issue. 2. It is a general statement. The placement is somewhat unfortunate because it seems that it may apply only to the Figure 1 case...but it applies in general...and there is no similar statement then describing other cases. Instead of adding something similar for Figure 2, perhaps move the sentence to a place that covers all the use cases. A third issue with the statement comes up when considering §3.1/§3.2: there is no specification there that explains how to figure out which should be the tunnel destination address. The example in §3.1 only talks about receiving information from E, including the "the encapsulation endpoint and the tunnel type of any tunnel used to reach E"...but says nothing about other potential SR-MPLS capable nodes between A and E, or how A would use a tunnel to one of those transit nodes on the way to E...which is what is illustrated in §3.2.1/3.2.2. (3) A very, very late IPR declaration came in after the IETF LC started. I didn't find a thread where the WG was made aware of it. https://datatracker.ietf.org/ipr/3439/
Thank you for writing this document! In general, the use of terminology (defined in rfc8402 and elsewhere) needs to be cleaned up throughout the document. (1) [nit] From the Abstract: "SR-MPLS could be leveraged...while preserving backward compatibility with SR-MPLS." I'm sure you want to say something related to making no changes to SR-MPLS for this application...the use of backwards compatibility with itself just sounds strange. The Introduction has similar text, but it does go on to clarify a little. (2) [nit] §3.1: "the FIB can be used to tell a router how to process packets" The FIB is generally in the router, so no need to tell it anything. ;-) Maybe: "the FIB can be used by the router to process packets". (3) §3.2: "Not all of the nodes in an SR-MPLS domain are SR-MPLS capable." By definition, all nodes in an SR domain participate in the source-based routing model [rfc8402]. I think that you meant to say that not all nodes in the network (or maybe just the domain) are SR-MPLS capable. Note that the SR domain in the networks in Figure 1, for example, includes both the SR-MPLS networks at both sides and the tunneled portion. If you mean for that picture to represent 3 different SR domains, then please don't use "SR-MPLS domain" to describe what is happening in the IP network portion. (4) §3.2: "There are six types of node in an SR-MPLS domain..." Again, I think you mean to point at the types of nodes in the network and not in the SR domain. (5) Security Considerations: Please also point at the considerations in rfc8402.
I'm still chatting with Adrian/whoever else about a possible mention of RFC 7510 Section 5 congestion control and its applicability to this draft, as the TSV-ART reviewer seemed to be pointing towards. But I'm sure we'll do the right thing (because if we did the right thing for MPLS over UDP, how could we not do the right thing for MPLS-SR over UDP?) Make good choices.
Thanks for this clearly-written document! I do have several suggestions for improvements, and note many places where IS-IS and OSPF seem to be described as normative references would, in the vein of Mirja's DISCUSS. I think it is possible to adjust the document to keep those as informative references, but the changes might be pretty intrusive. I'm a little confused about what exactly the new protocol specified here is -- there seems to be a lot of "use these existing technologies together in the following way" going on, that may be screening the actual new bits from prominence. The only thing that comes to mind is the requirement to use the explicit null label when the last label has PHP and is going over the tunnel, which is admittely important behavior to have! (To be clear, the implication is that a document consisting solely of "glue these existing pieces together" could well be published as Informational, though does not strictly speaking need to be.) It might also be helpful to have a reference to RFC 4023 for the plain MPLS-in-IP encapsulation, even just to contrast it to the MPLS-in-UDP (RFC 7510) that we do use. (This reader did not discern why the RFC 4023 encapsulation was unpreferred.) Section-by-section comments follow. Abstract SR-MPLS could be leveraged to realize a source routing mechanism across MPLS, IPv4, and IPv6 data planes by using an MPLS label stack as a source routing instruction set while preserving backward compatibility with SR-MPLS. Is this really saying "SR-MPLS could be leveraged ... while preserving compatibility with SR-MPLS"? Section 1 (Introduction) Similarly to the above: SR-MPLS uses an MPLS label stack to encode a source routing instruction set. This can be used to realize a source routing mechanism that can operate across MPLS, IPv4, and IPv6 data planes. This approach preserves backward compatibility with SR-MPLS. No matter what SR-MPLS does, it is definitionally backward compatible with SR-MPLS. Section 2 o If encoding of entropy ([RFC6790] is desired, IP tunneling mechanisms that allow encoding of entropy, such as MPLS-in-UDP encapsulation [RFC7510] where the source port of the UDP header is I think it was already noted, but this language reads a little oddly, and it might be better as "If injection of additional entropy into the flow is needed". Section 3.1 Consider router A that receives a labeled packet with top label L(E) that corresponds to the prefix-SID SID(E) of prefix P(E) advertised by router E. Suppose the i-th next-hop router (termed NHi) along the shortest path from router A toward SID(E) is not SR-MPLS capable while both routers A and E are SR-MPLS capable. [...] Do we ever actually use the fact that it is specifically the i-th router that is SR-MPLS-incapable, or just need to know that at least one router on the path is deficient in that way? o The Segment Routing Global Block (SRGB) is defined in [RFC8402]. Router E is SR-MPLS capable, so it advertises an SRGB as described in [I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-isis-segment-routing-extensions]. I see the first sentence was added in discussion with another reviewer; I wonder if the text would flow better if the order of the sentences was swapped (particularly since this is the very first "processing step", and that declarative sentence does not describe any processing actions). o When Router E advertises the prefix-SID SID(E) of prefix P(E) it MUST also advertise the encapsulation endpoint and the tunnel type of any tunnel used to reach E. It does this using the mechanisms described in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. This "it does this" still is implying that IS-IS and OSPF are the only ways this can be done, which (AIUI) is not the intention. (Similarly for the next bullet point's sub-bullets.) * If router E is running ISIS and advertises the ISIS capabilities TLV (TLV 242) [RFC7981], it MUST set the "router- nit: 7981 seems to call this the "ISIS Router CAPABILITY TLV"; I don't know if the usage here has since become conventional. o Router A programs the FIB entry for prefix P(E) corresponding to the SID(E) as follows: Keeping with the theme, this is a declarative statement of procedure, and the following sub-bullets only cover OSPF and ISIS. It would need to be a statement of requirements for behavior/functionality in order to keep them from being normative references. Once constructed, the FIB can be used to tell a router how to process packets. It encapsulates the packets according to the encapsulation advertised in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards the next hop NHi. Oh, finally, "NHi" appears again. But are we actually forwarding towards the SR-MPLS-incapable router specifically, or just generically to the immediate next hop (which may or may not be NHi)? Also, I'll note that we introduced this list with "the following processing steps apply [for A wanting to send a packet towards E]", but most of the procedures therein involve things that E has to do to advertise the information that A will need in order to make the encapsulation, which feels like somewhat mismatched language. In short, this list of points doesn't tell me much about what specifically *A* does with this packet -- the last point handles what to do with the top label, but I guess we defer to the encapsulation scheme for the gory details (which is probably fine, but maybe the language could be tidied up to mention something about "using the appropriate mechanism for the selected tunnel type (e.g., IP)"). packets. It encapsulates the packets according to the encapsulation advertised in [I-D.ietf-isis-encapsulation-cap] or [I-D.ietf-ospf-encapsulation-cap]. Then it sends the packets towards nit: advertised *using the mechanisms in* Section 3.2 [RFC7510] specifies an IP-based encapsulation for MPLS, i.e., MPLS- in-UDP. This approach is applicable where IP-based encapsulation for MPLS is required and further fine-grained load balancing of MPLS packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs) is also required. This section provides details about the forwarding procedure when when UDP encapsulation is adopted for SR-MPLS over IP. (side note) Presumably this is just my lack of background showing, but this text seems to assume that the UDP encapsulation is the only way to do SR-MPLS over IP, with no discussion of RFC 4023. Nodes that are SR-MPLS capable can process SR-MPLS packets. Not all of the nodes in an SR-MPLS domain are SR-MPLS capable. Some nodes may be "legacy routers" that cannot handle SR-MPLS packets but can forward IP packets. An SR-MPLS-capable node MAY advertise its capabilities using the IGP as described in Section 3. There are six types of node in an SR-MPLS domain: (side note) Similarly, we only talk about SR-MPLS and IP routers here; is there some intermediate "MPLS but not SR-MPLS" category or similar? Also, the top-level Section 3 is just introductory text and doesn't really describe much of anything, and if we are considering this to refer to Section 3 and subsections, it then becomes self-referential. Section 3.2.1 Routers A, E, G, and H advertise their Segment Routing related information via IS-IS or OSPF. [still declarative] To handle this, when a router (here it is router G) pops the final SR-MPLS label, it inserts an explicit null label [RFC3032] before encapsulating the packet in an MPLS-over-UDP tunnel toward router H and sending it out. That is, router G pops the top label, discovers it has reached the bottom of stack, pushes an explicit null label, and then encapsulates the MPLS packet in a UDP tunnel to router H. This seems like a critical functional behavior that is not specific to the usage of IS-IS or OSPF. Section 3.2.3 For instance, in the example as described in Figure 4, assume F is now an SR-MPLS-capable transit node while all the other assumptions keep unchanged, since F is not identified by a SID in the stack and an MPLS-over-UDP tunnel is preferred to an MPLS LSP according to local policies, router E would replace the current top label with an MPLS-over-UDP tunnel toward router G and send it out. (nit: There's a comma splice before "since F".) This description is a little sparse, and seems to assume the reader knows that, all else being equal, with E, F, and G all being MPLS-capable, the segment from E to G would transit native MPLS, absent the indicated local policy. Since this is explicitly the thing we are contrasting against, it's probably good style to mention the behavior explicitly, too. IP Header Fields: When encapsulating an MPLS packet in UDP, the resulting packet is further encapsulated in IP for transmission. IPv4 or IPv6 may be used according to the capabilities of the network. The address fields are set as described in Section 2. (Does Section 2 say how to set the source address?) Entropy and ECMP: When encapsulating an MPLS packet with an IP tunnel header that is capable of encoding entropy (such as [RFC7510]), the corresponding entropy field (the source port in case UDP tunnel) MAY be filled with an entropy value that is nit: "in the case of a UDP tunnel" Section 5 [I'm going to comment on basically every line here; sorry to be so nitpicky.] The security consideration of [RFC8354] and [RFC7510] apply. DTLS RFC 8354's security considerations are, for practical purposes, empty. Perhaps a direct reference to 5095 would be more appropriate. (The RFC 7510 security considerations are of course quite relevant and helpful.) [RFC6347] SHOULD be used where security is needed on an MPLS-SR-over- UDP segment. I think you need to give some indication of when that might be the case, e.g., if the IP segment crosses the public Internet or some other untrusted environment. It is difficult for an attacker to pass a raw MPLS encoded packet into a network and operators have considerable experience at excluding such packets at the network boundaries. This is describing an expected/desired state (hopefully also the current state!) but not why that should be or what the consequences of failing to achieve that state are. I'm happy to contribute some text, but this seems like a generic MPLS consideration and I hope there is an already-published reference that could be used instead. It is easy for an ingress node to detect any attempt to smuggle an IP packet into the network since it would see that the UDP destination port was set to MPLS. SR packets not having a destination address Easy, sure, if you know to look for it. Where is that requirement mandated? terminating in the network would be transparently carried and would pose no security risk to the network under consideration. I'm not sure I see how the second sentence relates to the first; is this just trying to say that SR-MPLS is transparent to traffic flowing over such a network? There would still be generic capacity risks, of course, though maybe we don't need to be so specific -- "pose no different security risk than any other traffic" would be plenty. Where control plane techniques are used (as described in Section 3), it is important that these protocols are adequately secured for the environment in which they are run. What does "adequately secured" mean? Is there a best-practices document, or security considerations for the control protocols in question that cover this? Is the needed property that "any packets interpreted as MPLS must be originated from authorized network devices within the administrative domain (or group of such domains), with no ability for attackers to inject such traffic inside the domain and blocking at the boundary"? When different administrative domains are joined together, what are the counterparty risks?
Thank you very much for writing this - I think it is useful. Also, thanks to Al Morton for the OpsDir review, and for addressing his comment.
Thanks for addressing my two smallish discuss points! I still support Alvaro's discuss.
+1 to Mirja's DISCUSS points.
Hello, maybe I didn't sleep enough and maybe this relates to Alvaro's DISCUSS, but I don't see what, in 3.1, is specific to the fact that "i-th next-hop router (termed NHi) along the shortest path from router A toward SID(E) is not SR-MPLS capable"