MPLS Segment Routing over IP
RFC 8663

Received changes through RFC Editor sync (created alias RFC 8663, changed title to 'MPLS Segment Routing over IP', changed abstract to 'MPLS Segment Routing (SR-MPLS) is a method of source routing a packet through an MPLS data plane by imposing a stack of MPLS labels on the packet to specify the path together with any packet-specific instructions to be executed on it. SR-MPLS can 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 making no changes to SR-MPLS specifications and interworking with SR-MPLS implementations.

This document describes how SR-MPLS-capable routers and IP-only routers can seamlessly coexist and interoperate through the use of SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-over-UDP as defined in RFC 7510.', changed pages to 17, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-12-06, changed IESG state to RFC Published)

[Ballot comment]
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.

[Ballot 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' ?

[Ballot comment]
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"

[Ballot comment]
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.

[Ballot discuss]
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/

[Ballot discuss]
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 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. 

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 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...").


(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 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.

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 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.


(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/

[Ballot discuss]
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.

(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 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. 

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 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...").


(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 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.

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 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.


(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/

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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.

[Ballot discuss]
These points should be easy to resolve:

1) Given section 3.1, the following drafts all seems that they should be normative references: ietf-isis-encapsulation-cap, ietf-ospf-encapsulation-cap, ietf-ospf-segment-routing-extensions, ietf-isis-segment-routing-extensions

2) Sec 3.2.3 on IP Header fields should refer to RFC6040 for the ECN field and eventually RFC2983 for DSCP.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-mpls-sr-over-ip-02, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Amanda Baber
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-02-26):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, draft-ietf-mpls-sr-over-ip@ietf.org, mpls-chairs@ietf.org, Loa Andersson , loa@pi.nu
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SR-MPLS over IP) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'SR-MPLS over IP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-02-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  MPLS Segment Routing (SR-MPLS) is an MPLS data plane-based source
  routing paradigm in which the sender of a packet is allowed to
  partially or completely specify the route the packet takes through
  the network by imposing stacked MPLS labels on the packet.  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.

  This document describes how SR-MPLS capable routers and IP-only
  routers can seamlessly co-exist and interoperate through the use of
  SR-MPLS label stacks and IP encapsulation/tunneling such as MPLS-in-
  UDP as defined in RFC 7510.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-sr-over-ip/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/3210/
  https://datatracker.ietf.org/ipr/3211/

The MPLS Working Group requests that

                            SR-MPLS over IP
                    draft-ietf-mpls-sr-over-ip

is published as an RFC on the standards track

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

- we request that the document is published as a Proposed Standard.
- the title page header says "Standards Track"
- PS is the proper type of RFC since the document specifies new
  protocol procedures for SR-MPLS capable LSRs.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

- SR-MPLS is a source routing paradigm for the MPLS data plane.
  SR-MPLS allows the sender of the packet to (partly or completely)
  specify the route the packet takes through an MPLS network, this is
  done by encapsulating the packet in a label stack.

- SR-MPLS may be used realize a source routing mechanism across MPLS,
  IPv4, and IPv6 data planes. While SR-MPLS works seamlessly over
  MPLS and SRv6 capable networks, it does not work over IPv4 networks
  without this mechanism. The MPLS label stack is used as a
  set of source routing instructions, being backward compatible with
  SR-MPLS.

- This document describes how SR-MPLS capable LSRs, non-SR MPLS
  capable LSRs and IP-only routers can seamlessly co-exist and
  interoperate through the use of SR-MPLS label stacks and IP
  encapsulation, such as MPLS-in-UDP as defined in RFC 7510.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

- The working group process has been very smooth and straight
  forward. We have very good support for the document.

- Early there were two competing individual documents, and the
  discussion was quite heated. The WG chairs for both the SPRING and
  MPLS working groups early suggested to merge the documents. That
  this merge actually could take place is very much thanks to the strong
  leadership of Zhenbin (Robin) Li who worked  with the the two author
  teams to make this happen.

- Most of the discussion on which working group should progress the
  draft took place before making the draft a working group document.
  That discussion was whether the document should be progressed
  in SPRING or MPLS, since this builds on RFC 7510 (an MPLS RFC) and
  describes how the MPLS label stack is used as a set of source
  routing instructions, the discussion converged on progressing the
  document in the MPLS WG.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

- we do not currently know for certain if there are implementations
  of this specification. An implementation poll has been sent to the
  MPLS working group, the shepherd write-up will be updated as soon
  as we get further information.

- there were no special reviews outside the normal working group
  process (MPLS-RT review, adoption poll, mailing list discussion
  and WGLC).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

- Loa Anderson is the Document Shepherd
- Deborah Brungard is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

- The document shepherd has reviewed the document basically at the
  steps in the working group process, when the documents that were
  merged were posted, when the documents were merged, before the WGAP
  and WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

- No such concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

- No such reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

- No such concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

- All the co-authors have stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- All the contributors has stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- There are 6 co-authors and 13 contributors, the process to get
  responses to the IPR poll were lengthy. When we sent the document
  to WGLC one of the contributors had not responded to the IPR poll.
  The working group was notified about this, but it generated no
  discussion, and during the WGLC we got the final response in.

- the high number of authors/contributors is becasue this is a merge
  of two documents, and both document contributed both authors and
  contributors, the number of authors has been decrease to an
  acceptable number (6), by moving former "authors" to
  "contributors". This has been done even though we know that among
  the listed contributors there are people that have independently
  contributed text. The process of reducing the number of authors
  has required quite a bit discussion, and the WG chairs and the
  WG very appreciate the spirit of cooperation that made this
  process possible.
 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

- There are two IPR disclosures against documents that were
  predecessors to the working group document, they are both pointing
  to the same US patent.

  The working group has been notified of the IPR disclosures, but no
  discussion toom place. The customary interpretation of this is is
  that the conditions listed in the IPR disclosures are acceptable to
  the working group.
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

- The support for this document is very strong. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

- No such threats

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

- The document passes ID nits clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

- No such formal reviews necessary

(13) Have all references within this document been identified as
either normative or informative?

- All references are correctly split into Normative and Informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

- All the normative references (with one exception) are to published
  standard track RFCs.

- The exception is ietf-spring-segment-routing-mpls, which has been
  submitted to the IESG for publication.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

- no downward references

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

- the publication of this document will not change the status of any
  existing RFC


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

- There are no request for IANA actions in this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

- No new regisgtries are specified in the document

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a forchecks or mal
language, such as XML code, BNF rules, MIB definitions, etc.

- No such automated checks or reviews are necessary.

The MPLS Working Group requests that

                            SR-MPLS over IP
                    draft-ietf-mpls-sr-over-ip

is published as an RFC on the standards track

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

- we request that the document is published as a Proposed Standard.
- the title page header says "Standards Track"
- PS is the proper type of RFC since the document specifies new
  protocol procedures for SR-MPLS capable LSRs.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

- SR-MPLS is a source routing paradigm for the MPLS data plane.
  SR-MPLS allows the sender of the packet to (partly or completely)
  specify the route the packet takes through an MPLS network, this is
  done by encapsulating the packet in a label stack.

- SR-MPLS may be used realize a source routing mechanism across MPLS,
  IPv4, and IPv6 data planes. While SR-MPLS works seamlessly over
  MPLS and SRv6 capable networks, it does not work over IPv4 networks
  without this mechanism. The MPLS label stack is used as a
  set of source routing instructions, being backward compatible with
  SR-MPLS.

- This document describes how SR-MPLS capable LSRs, non-SR MPLS
  capable LSRs and IP-only routers can seamlessly co-exist and
  interoperate through the use of SR-MPLS label stacks and IP
  encapsulation, such as MPLS-in-UDP as defined in RFC 7510.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

- The working group process has been very smooth and straight
  forward. We have very good support for the document.

- Early there were two competing individual documents, and the
  discussion was quite heated. The WG chairs for both the SPRING and
  MPLS working groups early suggested to merge the documents. That
  this merge actually could take place is very much thanks to the strong
  leadership of Zhenbin (Robin) Li who worked  with the the two author
  teams to make this happen.

- Most of the discussion on which working group should progress the
  draft took place before making the draft a working group document.
  That discussion was whether the document should be progressed
  in SPRING or MPLS, since this builds on RFC 7510 (an MPLS RFC) and
  describes how the MPLS label stack is used as a set of source
  routing instructions, the discussion converged on progressing the
  document in the MPLS WG.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

- we do not currently know for certain if there are implementations
  of this specification. An implementation poll has been sent to the
  MPLS working group, the shepherd write-up will be updated as soon
  as we get further information.

- there were no special reviews outside the normal working group
  process (MPLS-RT review, adoption poll, mailing list discussion
  and WGLC).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

- Loa Anderson is the Document Shepherd
- Deborah Brungard is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

- The document shepherd has reviewed the document basically at the
  steps in the working group process, when the documents that were
  merged were posted, when the documents were merged, before the WGAP
  and WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

- No such concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

- No such reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

- No such concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

- All the co-authors have stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- All the contributors has stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- There are 6 co-authors and 13 contributors, the process to get
  responses to the IPR poll were lengthy. When we sent the document
  to WGLC one of the contributors had not responded to the IPR poll.
  The working group was notified about this, but it generated no
  discussion, and during the WGLC we got the final response in.

- the high number of authors/contributors is becasue this is a merge
  of two documents, and both document contributed both authors and
  contributors, the number of authors has been decrease to an
  acceptable number (6), by moving former "authors" to
  "contributors". This has been done even though we know that among
  the listed contributors there are people that have independently
  contributed text. The process of reducing the number of authors
  has required quite a bit discussion, and the WG chairs and the
  WG very appreciate the spirit of cooperation that made this
  process possible.
 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

- There are two IPR disclosures against documents that were
  predecessors to the working group document, they are both pointing
  to the same US patent.

  The working group has been notified of the IPR disclosures, but no
  discussion toom place. The customary interpretation of this is is
  that the conditions listed in the IPR disclosures are acceptable to
  the working group.
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

- The support for this document is very strong. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

- No such threats

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

- The document passes ID nits clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

- No such formal reviews necessary

(13) Have all references within this document been identified as
either normative or informative?

- All references are correctly split into Normative and Informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

- All the normative references (with one exception) are to published
  standard track RFCs.

- The exception is ietf-spring-segment-routing-mpls, which has been
  submitted to the IESG for publication.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

- no downward references

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

- the publication of this document will not change the status of any
  existing RFC


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

- There are no request for IANA actions in this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

- No new regisgtries are specified in the document

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a forchecks or mal
language, such as XML code, BNF rules, MIB definitions, etc.

- No such automated checks or reviews are necessary.

The MPLS Working Group requests that

                            SR-MPLS over IP
                    draft-ietf-mpls-sr-over-ip

is published as an RFC on the standards track

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

- we request that the document is published as a Proposed Standard.
- the title page header says "Standards Track"
- PS is the proper type of RFC since the document specifies new
  protocol procedures for SR-MPLS capable LSRs.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

- SR-MPLS is a source routing paradigm for the MPLS data plane.
  SR-MPLS allows the sender of the packet to (partly or completely)
  specify the route the packet takes through an MPLS network, this is
  done by encapsulating the packet in a label stack.

- SR-MPLS may be used realize a source routing mechanism across MPLS,
  IPv4, and IPv6 data planes. While SR-MPLS works seamlessly over
  MPLS and SRv6 capable networks, it does not work over IPv4 networks
  without this mechanism. The MPLS label stack is used as a
  set of source routing instructions, being backward compatible with
  SR-MPLS.

- This document describes how SR-MPLS capable LSRs, non-SR MPLS
  capable LSRs and IP-only routers can seamlessly co-exist and
  interoperate through the use of SR-MPLS label stacks and IP
  encapsulation, such as MPLS-in-UDP as defined in RFC 7510.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

- The working group process has been very smooth and straight
  forward. We have very good support for the document.

- Early there were two competing individual documents, and the
  discussion was quite heated. The WG chairs for both the SPRING and
  MPLS working groups early suggested to merge the documents.That
  this merge actually could take place is very much thanks to the strong
leadership of Zhenbin (Robin) Li who worked  with the the two author
teams to make this happen.

- Most of the discussion on which working group should progress the
  draft took place before making the draft a working group document.
  That discussion was whether the document should be progressed
  in SPRING or MPLS, since this builds on RFC 7510 (an MPLS RFC) and
  describes how the MPLS label stack is used as a set of source
  routing instructions, the discussion converged on progressing the
  document in the MPLS WG.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

- we do not currently know for certain if there are implementations
  of this specification. An implementation poll has been sent to the
  MPLS working group, the shepherd write-up will be updated as soon
  as we get further information.

- there were no special reviews outside the normal working group
  process (MPLS-RT review, adoption poll, mailing list discussion
  and WGLC).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

- Loa Anderson is the Document Shepherd
- Deborah Brungard is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

- The document shepherd has reviewed the document basically at the
  steps in the working group process, when the documents that were
  merged were posted, when the documents were merged, before the WGAP
  and WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

- No such concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

- No such reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

- No such concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

- All the co-authors have stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- All the contributors has stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- There are 6 co-authors and 13 contributors, the process to get
  responses to the IPR poll were lengthy. When we sent the document
  to WGLC one of the contributors had not responded to the IPR poll.
  The working group was notified about this, but it generated no
  discussion, and during the WGLC we got the final response in.

- the high number of authors/contributors is becasue this is a merge
  of two documents, and both document contributed both authors and
  contributors, the number of authors has been decrease to an
  acceptable number (6), by moving former "authors" to
  "contributors". This has been done even though we know that among
  the listed contributors there are people that have independently
  contributed text. The process of reducing the number of authors
  has required quite a bit discussion, and the WG chairs and the
  WG very appreciate the spirit of cooperation that made this
  process possible.
 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

- There are two IPR disclosures against documents that were
  predecessors to the working group document, they are both pointing
  to the same US patent.

  The working group has been notified of the IPR disclosures, but no
  discussion toom place. The customary interpretation of this is is
  that the conditions listed in the IPR disclosures are acceptable to
  the working group.
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

- The support for this document is very strong. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

- No such threats

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

- The document passes ID nits clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

- No such formal reviews necessary

(13) Have all references within this document been identified as
either normative or informative?

- All references are correctly split into Normative and Informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

- All the normative references (with one exception) are to published
  standard track RFCs.

- The exception is ietf-spring-segment-routing-mpls, which has been
  submitted to the IESG for publication.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

- no downward references

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

- the publication of this document will not change the status of any
  existing RFC


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

- There are no request for IANA actions in this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

- No new regisgtries are specified in the document

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a forchecks or mal
language, such as XML code, BNF rules, MIB definitions, etc.

- No such automated checks or reviews are necessary.

The MPLS Working Group requests that

                            SR-MPLS over IP
                    draft-ietf-mpls-sr-over-ip

is published as an RFC on the standards track

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

- we request that the document is published as a Proposed Standard.
- the title page header says "Standards Track"
- PS is the proper type of RFC since the document specifies new
  protocol procedures for SR-MPLS capable LSRs.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

- SR-MPLS is a source routing paradigm for the MPLS data plane.
  SR-MPLS allows the sender of the packet to (partly or completely)
  specify the route the packet takes through an MPLS network, this is
  done by encapsulating the packet in a label stack.

- SR-MPLS may be used realize a source routing mechanism across MPLS,
  IPv4, and IPv6 data planes. While SR-MPLS works seamlessly over
  MPLS and SRv6 capable networks, it does not work over IPv4 networks
  without this mechanism. The MPLS label stack is used as a
  set of source routing instructions, being backward compatible with
  SR-MPLS.

- This document describes how SR-MPLS capable LSRs, non-SR MPLS
  capable LSRs and IP-only routers can seamlessly co-exist and
  interoperate through the use of SR-MPLS label stacks and IP
  encapsulation, such as MPLS-in-UDP as defined in RFC 7510.

Working Group Summary

  Was there anything in WG process that is worth noting? For
  example, was there controversy about particular points or
  were there decisions where the consensus was particularly
  rough?

- The working group process has been very smooth and straight
  forward. We have very good support for the document.

- Early there were two competing individual documents, and the
  discussion was quite heated. The WG chairs for both the SPRING and
  MPLS working groups early suggested to merge the documents. That
  this merge actually could take place is very much dependent on
  the strong leadership by Zhenbin (Robin) Li over the two author
  teams.

- Most of the discussion on which working group should progress the
  draft took place before making the draft a working group document.
  That discussion was whether the document should be progressed
  in SPRING or MPLS, since this builds on RFC 7510 (an MPLS RFC) and
  describes how the MPLS label stack is used as a set of source
  routing instructions, the discussion converged on progressing the
  document in the MPLS WG.

Document Quality

  Are there existing implementations of the protocol? Have a
  significant number of vendors indicated their plan to
  implement the specification? Are there any reviewers that
  merit special mention as having done a thorough review,
  e.g., one that resulted in important changes or a
  conclusion that the document had no substantive issues? If
  there was a MIB Doctor, Media Type or other expert review,
  what was its course (briefly)? In the case of a Media Type
  review, on what date was the request posted?

- we do not currently know for certain if there are implementations
  of this specification. An implementation poll has been sent to the
  MPLS working group, the shepherd write-up will be updated as soon
  as we get further information.

- there were no special reviews outside the normal working group
  process (MPLS-RT review, adoption poll, mailing list discussion
  and WGLC).

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

- Loa Anderson is the Document Shepherd
- Deborah Brungard is the Responsible Area Director

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

- The document shepherd has reviewed the document basically at the
  steps in the working group process, when the documents that were
  merged were posted, when the documents were merged, before the WGAP
  and WGLC.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

- No such concerns

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

- No such reviews needed.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

- No such concerns

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

- All the co-authors have stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- All the contributors has stated on the MPLS mailing list that they
  are unaware of any non-disclosed IPRs relating to this document.

- There are 6 co-authors and 13 contributors, the process to get
  responses to the IPR poll were lengthy. When we sent the document
  to WGLC one of the contributors had not responded to the IPR poll.
  The working group was notified about this, but it generated no
  discussion, and during the WGLC we got the final response in.

- the high number of authors/contributors is becasue this is a merge
  of two documents, and both document contributed both authors and
  contributors, the number of authors has been decrease to an
  acceptable number (6), by moving former "authors" to
  "contributors". This has been done even though we know that among
  the listed contributors there are people that have independently
  contributed text. The process of reducing the number of authors
  has required quite a bit discussion, and the WG chairs and the
  WG very appreciate the spirit of cooperation that made this
  process possible.
 

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

- There are two IPR disclosures against documents that were
  predecessors to the working group document, they are both pointing
  to the same US patent.

  The working group has been notified of the IPR disclosures, but no
  discussion toom place. The customary interpretation of this is is
  that the conditions listed in the IPR disclosures are acceptable to
  the working group.
 

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

- The support for this document is very strong. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

- No such threats

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

- The document passes ID nits clean

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

- No such formal reviews necessary

(13) Have all references within this document been identified as
either normative or informative?

- All references are correctly split into Normative and Informative

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

- All the normative references (with one exception) are to published
  standard track RFCs.

- The exception is ietf-spring-segment-routing-mpls, which has been
  submitted to the IESG for publication.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

- no downward references

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

- the publication of this document will not change the status of any
  existing RFC


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

- There are no request for IANA actions in this document

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

- No new regisgtries are specified in the document

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a forchecks or mal
language, such as XML code, BNF rules, MIB definitions, etc.

- No such automated checks or reviews are necessary.

Request for posting confirmation emailed to previous authors: Wim Henderickx , Zhenbin Li , Stewart Bryant , mpls-chairs@ietf.org, Adrian Farrel , Xiaohu Xu , Syed Hassan