MPLS Segment Routing over IP
draft-ietf-mpls-sr-over-ip-07

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.

Thank you all for the work put into this document

== COMMENTS ==

Generic question of mine: is there a way to leverage SRv6 in the underlay ?

-- Section 3.2.3 --

About the IP encapsulation, is the hop limit / TTL simply copied from the 'payload packet header'? What is the procedure at the exit of the tunnel wrt hop limit / TTL of the 'payload packet header' ?

+1 to Mirja's DISCUSS points.

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?

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"

Thanks for addressing my two smallish discuss points! I still support Alvaro's discuss.

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 a clear and well written document. I only had one question. The document seems to rely on draft-ietf-ospf-encapsulation-cap-09 and draft-ietf-isis-encapsulation-cap-01 to provide the tunnel encapsulation parameters. These two IGP documents allow for the UDP destination ports to be specified in the tunnel encapsulation attribute, while RFC7510 requires the use of 6635 as the destination port. I think it would be good if this draft specifies what happens if a different UDP port is received in the IGP tunnel encapsulation attribute. i.e. use the received value, ignore and use 6635, or fail with error.