Source: http://sandbox.ietf.org/doc/draft-ietf-mpls-sr-over-ip/history/
Timestamp: 2019-04-22 20:03:38+00:00

Document:
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"
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.
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.
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: "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).
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.
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 in 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.
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 in this document 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...").
In the general case the statement is wrong: Yes, the tunnel destination should be the next SR-MPLS node, but, that doesn't have to be "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.
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 make me happy.
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 Figure 2. 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..w.which is what is illustrated in §3.2.1/3.2.2.
I am balloting DISCUSS because the specification is incomplete and not clear enough. This document basically specifies how to construct forwarding entries (§3.1) and packet forwarding (§3.2). I have concerns about both the specification of the first, and about the specification of the tunnel end-points.
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.
planes. This approach preserves backward compatibility with SR-MPLS.
on the path is deficient in that way?
o The Segment Routing Global Block (SRGB) is defined in [RFC8402].
know if the usage here has since become conventional.
keep them from being normative references.
to the immediate next hop (which may or may not be NHi)?
selected tunnel type (e.g., IP)").
adopted for SR-MPLS over IP.
do SR-MPLS over IP, with no discussion of RFC 4023.
is there some intermediate "MPLS but not SR-MPLS" category or similar?
refer to Section 3 and subsections, it then becomes self-referential.
and then encapsulates the MPLS packet in a UDP tunnel to router H.
the usage of IS-IS or OSPF.
network. The address fields are set as described in Section 2.
nit: "in the case of a UDP tunnel"
RFC 8354's security considerations are, for practical purposes, empty.
Perhaps a direct reference to 5095 would be more appropriate.
excluding such packets at the network boundaries.
already-published reference that could be used instead.
pose no security risk to the network under consideration.
security risk than any other traffic" would be plenty.
environment in which they are run.
joined together, what are the counterparty risks?
+1 to Mirja's DISCUSS points.
2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN field and eventually RFC2983 for DSCP.
03 Martin Stiemerling Request for Last Call review by TSVART Completed: Ready. Reviewer: Martin Stiemerling. Sent review to list.
02 Robert Sparks Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Robert Sparks. Sent review to list.
02 Al Morton Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Al Morton. Sent review to list.
UDP as defined in RFC 7510.
02 Min Ye Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Eric Gray.
02 Deborah Brungard Eric Gray - RTG DIR reviewer.
02 Loa Andersson An IPR poll has been sent out 2019-01-04!
02 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC cleared.
01 Loa Andersson Tag Revised I-D Needed - Issue raised by WGLC set.
01 Loa Andersson IPR Poll started 2018-11-08.

References: §3
 §3

§2
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3
 §3