Skip to main content

Segment Routing with the MPLS Data Plane
draft-ietf-spring-segment-routing-mpls-22

Revision differences

Document history

Date Rev. By Action
2019-11-12
22 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2019-08-27
22 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2019-08-26
22 Gunter Van de Velde Assignment of request for Last Call review by OPSDIR to Joel Jaeggli was marked no-response
2019-08-01
22 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2019-07-31
Jenny Bui Posted related IPR disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-spring-segment-routing-mpls
2019-05-30
22 (System) IANA Action state changed to No IANA Actions from In Progress
2019-05-28
22 (System) RFC Editor state changed to EDIT
2019-05-28
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2019-05-28
22 (System) Announcement was received by RFC Editor
2019-05-28
22 (System) IANA Action state changed to In Progress
2019-05-28
22 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2019-05-28
22 Cindy Morgan IESG has approved the document
2019-05-28
22 Cindy Morgan Closed "Approve" ballot
2019-05-28
22 Martin Vigoureux IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2019-05-28
22 Martin Vigoureux Ballot approval text was generated
2019-05-23
22 Alvaro Retana [Ballot Position Update] Position for Alvaro Retana has been changed to No Objection from Discuss
2019-05-01
22 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-22.txt
2019-05-01
22 (System) New version approved
2019-05-01
22 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2019-05-01
22 Ahmed Bashandy Uploaded new revision
2019-04-22
21 Benjamin Kaduk
[Ballot comment]
Thank you for addressing (most of) my Discuss points!
I leave it to the responsible AD to decide whether any action is needed …
[Ballot comment]
Thank you for addressing (most of) my Discuss points!
I leave it to the responsible AD to decide whether any action is needed
on the author count.

[original COMMENT section preserved below; thank you for addressing
the comments therein as well]

It seems that we're introducing something of a new concept in this
document of "routing instance" as something with a numerical identifier.
(That is, this does not appear in RFC 8402 or RFC 3031, in terms of
what references I might expect to be in scope.)  Am I just missing some
other reference where this is introduced?  If not, maybe it is worth
mentioning in a terminology section.

[I think some of these section-by-section notes were spotted already;
I didn't get a chance to deduplicate.]

Section 2

  In order to have a node segment to reach the node, a network operator
  SHOULD configure at least one node segment per routing instance,
  topology, algorithm. [...]

nit: maybe "per tuple of [...]"?

Section 2.2

  o  The label value MUST be unique within the router on which the MCC
      is running. i.e. the label MUST only be used to represent the SID
      and MUST NOT be used to represent more than one SID or for any
      other forwarding purpose on the router.

Maybe I'm misreading the intent, but "MUST be unique" seems like it's a
requirement from core MPLS and need not be restated.

Section 2.3

                                                              The rules
  applicable to the SRGB are also applicable to the SRLB, except rule
  that says that the SRGB MUST only be used to instantiate global SIDs
  into the MPLS forwarding plane. [...]

nit: "except the rule"

Section 2.4

I'd consider writing the algorithm in real code (python?) rather than
abstract pseudocode.  In some cases (though probably not here?)
pseudocode makes it easy to miss edge cases that need to be specified in
order for things to be interoperably implementable.

Section 2.5

  MPLS Architecture [RFC3031] defines Forwarding Equivalence Class
  (FEC) term as the set of packets with similar and / or identical
  characteristics which are forwarded the same way and are bound to the
  same MPLS incoming (local) label. In Segment-Routing MPLS, local
  label serves as the SID for given FEC.

nit: there's some missing (in)definite articles here; "The MPLS
Architecture", "the local label", "a given FEC".  (And it probably reads
better as "defines the term [FEC]" than putting "term" after the name of
the term.

  o  (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), where a
      topology identifies a set of links with metrics. For the purpose
      of incoming label collision resolution, the same Topology
      numerical value SHOULD be used on all routers to identify the same
      set of links with metrics. [...]

Is the IGP going to help me satisfy this SHOULD or is it more of a
pie-in-the-sky sort of thing?

Section 2.5.1

  This document defines the default tie breaking rules that SHOULD be
  implemented. An implementation MAY choose to support different tie-
  breaking rules and MAY use one of the these instead of the default
  tie-breaking rules. All routers in a routing domain SHOULD use the
  same tie-breaking rules to maximize forwarding consistency.

I didn't think through this hard enough to come up with a specific
scenario that would fail, but it seems like there could be bad failure
modes when forwarding consistency is not maintained.  That would perhaps
suggest a "MUST" requirement to use the same rules, and perhaps even
announcement of an identifier for what rules are in use, so that peers
can detect an inconsistency.

  The default FEC administrative distance order starting from the
  lowest value SHOULD be

I think it would be nice if we could get this to be an "is" rather than
a "SHOULD be", especially since at present we offer no guidance on
actually constructing the required 8-bit numerical values.

  The numerical sort across FECs SHOULD be performed as follows:

It seems like the first two top-level bullets here are not necessarily
part of the procedure itself, but rather some ancillary information
about how to compute values used as part of the procedure.  I don't know
if, editorially speaking, the presentation could be improved by
reframing how these are discussed.

      o All prefixes are represented by (128 + 8) bits.

            . A prefix is encoded in the most significant bits and the
              remaining bits are set to zero.

            . The prefix length is encoded before the prefix in a field
              of size 8 bits.

This description seems needlessly confusing.  Couldn't we write it as
(8+128) bits, and put the sub-bullet for the prefix length before the
other sub-bullet, so that they appear in the order the bits are encoded?

  o  Encode the remaining set of FECs as follows

      o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,
        Prefix, routing_instance_id, Topology, SR Algorithm,)

      o (next-hop, outgoing interface): (next-hop,
        outgoing_interface_id)

      o (number of adjacencies, list of next-hops in ascending
        numerical order, list of outgoing interface IDs in ascending
        numerical order). This encoding is used to encode a parallel
        adjacency [RFC8402]

      o (Endpoint, Color): (Endpoint_address, Color_id)

      o (IP address): This is the encoding for a mirror SID FEC. The IP
        address is encoded as described above in this section

I think this needs to say a little bit more about what is being
presented.  The part before the colon is what we're using to label a
category of FECs, and the part after the colon is how it is encoded?
There might be a more formal description language to describe the
encoding rules used, and also the (number of adjacencies, list of
next-hops) bullet point doesn't have a colon.

We also don't specify that big-endian (network byte order) is used.

  o  Select the FEC with the smallest numerical value

If I understand correctly, we are encoding these FECs to byte strings,
but different types of FEC get encoded as different length byte strings.
How do we then interpret these byte strings as numerical values?

Section 2.6

                                                    However to minimize
  the chance of misforwarding, a FEC that loses its incoming label to
  the tie-breaking rules specified in Section 2.5 MUST NOT be
  installed in FIB with an outgoing segment routing label based on the
  SID corresponding to the lost incoming label.

It's not entirely clear to me how actionable this requirement is.
That is, is the entity instaslling the FIB entry always going to know
that the outgoing label was "based on" the incoming (non-)label?

Section 2.7.1

Setting TTL and TC improperly can have security considerations.
This document does not discuss those, nor does RFC 8402 (the only
reference listed from this document's security considerations).

Section 4

"OAM" is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and would
typically qualify for expansion on first usage.

Section 5

[see also comment on Section 2.7.1]

Should we mention that different routers can get different results from
the tie-breaking rules in case of skew in IGP convergence?

Appendix A.1

  The packet arrives at router R2. Because the top label 1008
  corresponds to the IGP SID "8", which is the prefix-SID attached to
  the prefix 192.0.2.8/32 owned by the node R8, then the instruction
  associated with the SID is "forward the packet using all ECMP/UCMP
  interfaces and all ECMP/UCMP next-hop(s) along the shortest/useable
  path(s) towards R8". Because R2 is not the penultimate hop, R2
  applies the CONTINUE operation to the packet and sends it to R3 using
  one of the two links connected to R3 with top label 1008 as specified
  in Section 2.10.1.

"one of the two links" seems inconsistent with the claimed "using all
ECMP/UCMP interfaces and all ECMP/UCMP next-hop(s)".

                                                            Because R3
  is the penultimate hop, we assume that R3 performs penumtimate hop
  popping, which corresponds to the NEXT operation, then sends the
  packet to R8. [...]

This chain of causality doesn't follow.  We assume that R3 performs PHP
-- the fact that in this flow R3 is the penultimate hope does not factor
into that assumption.

Appendix A.2.5

  Since both FECs are from the same MCC, they have the same default
  admin distance. So we compare FEC type code-point. FEC1 has FEC type
  code-point=120, while FEC2 has FEC type code-point=130. Therefore,
  FEC1 wins.

nit: It feels a little strange to call these code-points when there's no
registry and they're locally assigned per site policy.

Appendix A.2.6

  FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
  from the same MCC, they have the same default admin distance. So we
  compare FEC type code-point. Both FECs have FEC type code-point=120.
  So we compare address family. Since IPv4 is preferred over IPv6, FEC1
  wins.

side note: It's a little surprising that "IPv4 is preferred over IPv6"
did not get any objections at IETF LC.  (Example 13 has the same
property.)
2019-04-22
21 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2019-04-17
21 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-21.txt
2019-04-17
21 (System) New version approved
2019-04-17
21 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2019-04-17
21 Ahmed Bashandy Uploaded new revision
2019-04-17
20 (System) Sub state has been changed to AD Followup from Revised ID Needed
2019-04-17
20 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-04-17
20 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-20.txt
2019-04-17
20 (System) New version approved
2019-04-17
20 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2019-04-17
20 Ahmed Bashandy Uploaded new revision
2019-04-11
19 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2019-04-11
19 Cindy Morgan Changed consensus to Yes from Unknown
2019-04-10
19 Suresh Krishnan
[Ballot comment]
* Section 2

"including for TI-LFA".

Add a reference to draft-bashandy-rtgwg-segment-routing-ti-lfa at first use?

* Section 2.4

Calling "temp" something more descriptive would …
[Ballot comment]
* Section 2

"including for TI-LFA".

Add a reference to draft-bashandy-rtgwg-segment-routing-ti-lfa at first use?

* Section 2.4

Calling "temp" something more descriptive would have been helpful (say base_index).

* Section 2.5.1.

"Address Family represented by 8 bits, where IPv4 encoded as 100 and IPv6 is encoded as 110."

Suggest rewording to say IPv4 is represented by the value 4 and IPv6 is represented by the value 6 (unless you actually meant to use the decimal values 100 and 110, in which case ignore this comment).
2019-04-10
19 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2019-04-10
19 Adam Roach
[Ballot comment]



§2.1:

>  The MCC in the network downloads
>  different MPLS labels/SIDs to the FIB for different forwarding
>  behaviors

Please expand "FIB" …
[Ballot comment]



§2.1:

>  The MCC in the network downloads
>  different MPLS labels/SIDs to the FIB for different forwarding
>  behaviors

Please expand "FIB" on first use.
2019-04-10
19 Adam Roach [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach
2019-04-10
19 Benjamin Kaduk
[Ballot discuss]
(pro forma) Six authors is more than five, which per RFC 7322 may require
discussion.

I have a few questions about whether we …
[Ballot discuss]
(pro forma) Six authors is more than five, which per RFC 7322 may require
discussion.

I have a few questions about whether we need to have more stringent or
more specific requirements listed.

In Section 2:

  An implementation SHOULD check that an IGP node-SID is not associated
  with a prefix that is owned by more than one router within the same
  routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
  another one if available, and SHOULD log an error.

While it's not entirely clear to me that we need to mandate checking
(the "SHOULD check"), I have a hard time understanding why we would
allow a known-bad SID to be used ("SHOULD NOT use this Node-SID").
Shouldn't that be a "MUST NOT", since using it could break the SR
abstraction?

In Section 2.5:

  5. The remaining FECs with the default algorithm (see the
      specification of prefix-SID algorithm [RFC8402]) are installed in
      the FIB natively, such as pure IP entries in case of Prefix FEC,
      without any incoming labels corresponding to their SIDs. The
      remaining FECs with a non-zero algorithm are not installed in the
      FIB.

I didn't really find where in RFC 8402 we assigned numerical values to
the prefix-SID algorithms, such that "non-zero algorithm" was
well-defined.  Should I be looking somewhere else for this?

In Section 2.5.1: I left several notes in the COMMENT section, but I
think I can summarize the point to "it seems like we are defining a
mapping from attributes of a given FEC/description to a byte string and
applying an ordering to that byte string.  But we don't fully specify
how all the bits are encoded in that byte string, and it looks like we
can end up with byte strings of a different length, so the comparison
rule is not necessarily clear in that case."  This seems fairly related
to Alvaro's point (2).

In Appendix A.1

      | Local IGP SID allocated dynamically by R2                |
      |                    for its "north" adjacency to R3: 9001 |
      |                    for its "north" adjacency to R3: 9003 |
      |                    for its "south" adjacency to R3: 9002 |
      |                    for its "south" adjacency to R3: 9003 |

9003 is duplicated for different adjacencies?  Isn't that a strongly
disrecommended scenario?
2019-04-10
19 Benjamin Kaduk
[Ballot comment]
It seems that we're introducing something of a new concept in this
document of "routing instance" as something with a numerical identifier.
(That …
[Ballot comment]
It seems that we're introducing something of a new concept in this
document of "routing instance" as something with a numerical identifier.
(That is, this does not appear in RFC 8402 or RFC 3031, in terms of
what references I might expect to be in scope.)  Am I just missing some
other reference where this is introduced?  If not, maybe it is worth
mentioning in a terminology section.

[I think some of these section-by-section notes were spotted already;
I didn't get a chance to deduplicate.]

Section 2

  In order to have a node segment to reach the node, a network operator
  SHOULD configure at least one node segment per routing instance,
  topology, algorithm. [...]

nit: maybe "per tuple of [...]"?

Section 2.2

  o  The label value MUST be unique within the router on which the MCC
      is running. i.e. the label MUST only be used to represent the SID
      and MUST NOT be used to represent more than one SID or for any
      other forwarding purpose on the router.

Maybe I'm misreading the intent, but "MUST be unique" seems like it's a
requirement from core MPLS and need not be restated.

Section 2.3

                                                              The rules
  applicable to the SRGB are also applicable to the SRLB, except rule
  that says that the SRGB MUST only be used to instantiate global SIDs
  into the MPLS forwarding plane. [...]

nit: "except the rule"

Section 2.4

I'd consider writing the algorithm in real code (python?) rather than
abstract pseudocode.  In some cases (though probably not here?)
pseudocode makes it easy to miss edge cases that need to be specified in
order for things to be interoperably implementable.

Section 2.5

  MPLS Architecture [RFC3031] defines Forwarding Equivalence Class
  (FEC) term as the set of packets with similar and / or identical
  characteristics which are forwarded the same way and are bound to the
  same MPLS incoming (local) label. In Segment-Routing MPLS, local
  label serves as the SID for given FEC.

nit: there's some missing (in)definite articles here; "The MPLS
Architecture", "the local label", "a given FEC".  (And it probably reads
better as "defines the term [FEC]" than putting "term" after the name of
the term.

  o  (Prefix, Routing Instance, Topology, Algorithm [RFC8402]), where a
      topology identifies a set of links with metrics. For the purpose
      of incoming label collision resolution, the same Topology
      numerical value SHOULD be used on all routers to identify the same
      set of links with metrics. [...]

Is the IGP going to help me satisfy this SHOULD or is it more of a
pie-in-the-sky sort of thing?

Section 2.5.1

  This document defines the default tie breaking rules that SHOULD be
  implemented. An implementation MAY choose to support different tie-
  breaking rules and MAY use one of the these instead of the default
  tie-breaking rules. All routers in a routing domain SHOULD use the
  same tie-breaking rules to maximize forwarding consistency.

I didn't think through this hard enough to come up with a specific
scenario that would fail, but it seems like there could be bad failure
modes when forwarding consistency is not maintained.  That would perhaps
suggest a "MUST" requirement to use the same rules, and perhaps even
announcement of an identifier for what rules are in use, so that peers
can detect an inconsistency.

  The default FEC administrative distance order starting from the
  lowest value SHOULD be

I think it would be nice if we could get this to be an "is" rather than
a "SHOULD be", especially since at present we offer no guidance on
actually constructing the required 8-bit numerical values.

  The numerical sort across FECs SHOULD be performed as follows:

It seems like the first two top-level bullets here are not necessarily
part of the procedure itself, but rather some ancillary information
about how to compute values used as part of the procedure.  I don't know
if, editorially speaking, the presentation could be improved by
reframing how these are discussed.

      o All prefixes are represented by (128 + 8) bits.

            . A prefix is encoded in the most significant bits and the
              remaining bits are set to zero.

            . The prefix length is encoded before the prefix in a field
              of size 8 bits.

This description seems needlessly confusing.  Couldn't we write it as
(8+128) bits, and put the sub-bullet for the prefix length before the
other sub-bullet, so that they appear in the order the bits are encoded?

  o  Encode the remaining set of FECs as follows

      o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,
        Prefix, routing_instance_id, Topology, SR Algorithm,)

      o (next-hop, outgoing interface): (next-hop,
        outgoing_interface_id)

      o (number of adjacencies, list of next-hops in ascending
        numerical order, list of outgoing interface IDs in ascending
        numerical order). This encoding is used to encode a parallel
        adjacency [RFC8402]

      o (Endpoint, Color): (Endpoint_address, Color_id)

      o (IP address): This is the encoding for a mirror SID FEC. The IP
        address is encoded as described above in this section

I think this needs to say a little bit more about what is being
presented.  The part before the colon is what we're using to label a
category of FECs, and the part after the colon is how it is encoded?
There might be a more formal description language to describe the
encoding rules used, and also the (number of adjacencies, list of
next-hops) bullet point doesn't have a colon.

We also don't specify that big-endian (network byte order) is used.

  o  Select the FEC with the smallest numerical value

If I understand correctly, we are encoding these FECs to byte strings,
but different types of FEC get encoded as different length byte strings.
How do we then interpret these byte strings as numerical values?

Section 2.6

                                                    However to minimize
  the chance of misforwarding, a FEC that loses its incoming label to
  the tie-breaking rules specified in Section 2.5 MUST NOT be
  installed in FIB with an outgoing segment routing label based on the
  SID corresponding to the lost incoming label.

It's not entirely clear to me how actionable this requirement is.
That is, is the entity instaslling the FIB entry always going to know
that the outgoing label was "based on" the incoming (non-)label?

Section 2.7.1

Setting TTL and TC improperly can have security considerations.
This document does not discuss those, nor does RFC 8402 (the only
reference listed from this document's security considerations).

Section 4

"OAM" is not listed as "well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt and would
typically qualify for expansion on first usage.

Section 5

[see also comment on Section 2.7.1]

Should we mention that different routers can get different results from
the tie-breaking rules in case of skew in IGP convergence?

Appendix A.1

  The packet arrives at router R2. Because the top label 1008
  corresponds to the IGP SID "8", which is the prefix-SID attached to
  the prefix 192.0.2.8/32 owned by the node R8, then the instruction
  associated with the SID is "forward the packet using all ECMP/UCMP
  interfaces and all ECMP/UCMP next-hop(s) along the shortest/useable
  path(s) towards R8". Because R2 is not the penultimate hop, R2
  applies the CONTINUE operation to the packet and sends it to R3 using
  one of the two links connected to R3 with top label 1008 as specified
  in Section 2.10.1.

"one of the two links" seems inconsistent with the claimed "using all
ECMP/UCMP interfaces and all ECMP/UCMP next-hop(s)".

                                                            Because R3
  is the penultimate hop, we assume that R3 performs penumtimate hop
  popping, which corresponds to the NEXT operation, then sends the
  packet to R8. [...]

This chain of causality doesn't follow.  We assume that R3 performs PHP
-- the fact that in this flow R3 is the penultimate hope does not factor
into that assumption.

Appendix A.2.5

  Since both FECs are from the same MCC, they have the same default
  admin distance. So we compare FEC type code-point. FEC1 has FEC type
  code-point=120, while FEC2 has FEC type code-point=130. Therefore,
  FEC1 wins.

nit: It feels a little strange to call these code-points when there's no
registry and they're locally assigned per site policy.

Appendix A.2.6

  FEC1 and FEC2 both use dynamic SID assignment. Since both FECs are
  from the same MCC, they have the same default admin distance. So we
  compare FEC type code-point. Both FECs have FEC type code-point=120.
  So we compare address family. Since IPv4 is preferred over IPv6, FEC1
  wins.

side note: It's a little surprising that "IPv4 is preferred over IPv6"
did not get any objections at IETF LC.  (Example 13 has the same
property.)
2019-04-10
19 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2019-04-10
19 Warren Kumari
[Ballot comment]
Thank you for a well written / easy to understand document.

I have a few suggestions / nits. Please note: If the WG …
[Ballot comment]
Thank you for a well written / easy to understand document.

I have a few suggestions / nits. Please note: If the WG has already discussed these, and come to other decisions, I'm fine with that...

1:  "In order to have a node segment to reach the node, a network operator SHOULD configure at least one node segment per routing instance, topology, algorithm. "
Perhaps: "segment per (routing instance, topology, algorithm)." (or "set of ..", or "combination of..." or something - not quite sure how best to word, but this seems slightly confusing).

2:  "If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules, then this SRGB MUST be completely ignored by all routers in the routing domain and the node MUST be treated as if it does not have an SRGB."
Shouldn't this be logged somewhere?

" The rules applicable to the SRGB are also applicable to the SRLB, except rule that says that the SRGB MUST only be used to instantiate global SIDs  into the MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB and/or SRLB is a matter of future study"
3: I think there is a missing word(s) between 'except rule' - perhaps "for the"?
4: Missing period.

5: "For the purpose of incoming label collision resolution, a routing instance is identified by a single incoming label downloader to FIB." - is downloader the right word here?

6: "If the derived numerical value varies for the same configuration, then an implementation SHOULD make numerical value used to identify a routing instance configurable."
This is a philosophical point, but it seems like I might always want to be able to configure this -- perhaps just "Implementations SHOULD make...? "

7: "This document defines the default tie breaking rules that SHOULD be implemented. An implementation MAY choose to support different tie-breaking rules and MAY use one of the these instead of the default tie-breaking rules. All routers in a routing domain SHOULD use the same tie-breaking rules to maximize forwarding consistency."
Is there any reason not to require that all implementations implement these rules (mandatory to implement)? I don't want to end up in a situation where I buy boxes from Vendor X, and then cannot add Vendor Y, because they don't share a set of rules.

8:  "R2 is the next-hop along the shortest path towards R8. By applying the steps in Section 2.8 the outgoing label downloaded to R1’s FIB corresponding to the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown in Figure 2." - I was initially confused by the [1000,5000] as it isn't represented like this in the figure. Perhaps change either this text, or the text in the figure?
2019-04-10
19 Warren Kumari Ballot comment text updated for Warren Kumari
2019-04-10
19 Warren Kumari
[Ballot comment]
Thank you for a well written / easy to understand document.

I have a few nits to point out / suggest. Please note: …
[Ballot comment]
Thank you for a well written / easy to understand document.

I have a few nits to point out / suggest. Please note: If the WG has already discussed these, and come to other decisions, I'm fine with that...

1:  "In order to have a node segment to reach the node, a network operator SHOULD configure at least one node segment per routing instance, topology, algorithm. "
Perhaps: "segment per (routing instance, topology, algorithm)." (or "set of ..", or "combination of..." or something - not quite sure how best to word, but this seems slightly confusing).

2:  "If the SRGB of a node does not conform to the structure specified in this section or to the previous two rules, then this SRGB MUST be completely ignored by all routers in the routing domain and the node MUST be treated as if it does not have an SRGB."
Shouldn't this be logged somewhere?

" The rules applicable to the SRGB are also applicable to the SRLB, except rule that says that the SRGB MUST only be used to instantiate global SIDs  into the MPLS forwarding plane. The recommended, minimum, or maximum size of the SRGB and/or SRLB is a matter of future study"
3: I think there is a missing word(s) between 'except rule' - perhaps "for the"?
4: Missing period.

5: "For the purpose of incoming label collision resolution, a routing instance is identified by a single incoming label downloader to FIB." - is downloader the right word here?

6: "If the derived numerical value varies for the same configuration, then an implementation SHOULD make numerical value used to identify a routing instance configurable."
This is a philosophical point, but it seems like I might always want to be able to configure this -- perhaps just "Implementations SHOULD make...? "

7: "This document defines the default tie breaking rules that SHOULD be implemented. An implementation MAY choose to support different tie-breaking rules and MAY use one of the these instead of the default tie-breaking rules. All routers in a routing domain SHOULD use the same tie-breaking rules to maximize forwarding consistency."
Is there any reason not to require that all implementations implement these rules (mandatory to implement)? I don't want to end up in a situation where I buy boxes from Vendor X, and then cannot add Vendor Y, because they don't share a set of rules.

8:  "R2 is the next-hop along the shortest path towards R8. By applying the steps in Section 2.8 the outgoing label downloaded to R1’s FIB corresponding to the global SID index 8 is 1008 because the SRGB of R2 is [1000,5000] as shown in Figure 2." - I was initially confused by the [1000,5000] as it isn't represented like this in the figure. Perhaps change either this text, or the text in the figure?
2019-04-10
19 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2019-04-10
19 Alvaro Retana
[Ballot discuss]
(1) This first point is a cross-document DISCUSS.  In short, the assumptions in this document about what an MCC is responsible for are …
[Ballot discuss]
(1) This first point is a cross-document DISCUSS.  In short, the assumptions in this document about what an MCC is responsible for are not in line with the corresponding IGP drafts for OSPF [1][2] and IS-IS [3].  This misalignment must be resolved before any of these documents are published.

[Note: I'll start a thread with the corresponding WGS, Authors, Shepherds, Chairs and ADs.  Let's please discuss this point there.]

This document uses the following definition in §2: "We call "MPLS Control Plane Client (MCC)" any control plane entity installing forwarding entries in the MPLS data plane.  IGPs with SR extensions...are examples of MCCs." 

The focus of the IGP drafts is on the transport of the SR information, and not on other functions (see below).  Which component is responsible for what is the point that needs clarification -- either in this document, the IGP drafts, or both.

These are some specific cases:

(1.1) §2.4 (Mapping a SID Index to an MPLS label): "The following rules MUST be applied by the MCC when calculating the MPLS label value corresponding the SID index value "I"."  There's nothing in the IGP extension documents that point at this set of rules, and only a passing reference in the OSPF documents about outgoing labels. 

(1.2) §2.5 (Incoming Label Collision) also assumes more functions from an MCC than what the IGP documents do.  For example: "Within an MCC, apply tie-breaking rules to select one FEC only and assign the label to it."

(1.3) §2.8 also expects work by the IGPs: "the MCC is responsible for downloading the correct label value to FIB"...in this case not just calculating the label, but installing it in the FIB.

(1.4) §2.10.1: "The method by which the MCC on router "R0" determines that PUSH or CONTINUE operation must be applied using the SID "Si" is beyond the scope of this document. An example of a method to determine the SID "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-segment-routing-extensions]..." Note that the IS-IS draft (or the OSPF ones, for that matter) don't talk about how to determine the operation -- if that is out of scope of this document, then where is it specified?

(1.5) From §2:

  An implementation SHOULD check that an IGP node-SID is not associated
  with a prefix that is owned by more than one router within the same
  routing domain. If so, it SHOULD NOT use this Node-SID, MAY use
  another one if available, and SHOULD log an error.

rfc8402 reads (§3.2): "An IGP Node-SID MUST NOT be associated with a prefix that is owned by more than one router within the same routing domain."  The text above is not in line with that (MUST NOT vs SHOULD).  Also, how can "SHOULD check" be Normatively enforced? 

Both sentences above seem to be trying to specify a behavior for the IGPs. 

[1] https://tools.ietf.org/html/draft-ietf-ospf-segment-routing-extensions
[2] https://tools.ietf.org/html/draft-ietf-ospf-ospfv3-segment-routing-extensions
[3] https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions 


(2) §2.5.1: According to §2.5, a "tie-breaking rule MUST be deterministic".  However, the specification of the default rules are not: the first step uses the administrative distance, but the specification says that "the FEC types are ordered using the default administrative distance ordering defined by the implementation"...and later that the "user SHOULD ensure that the same administrative distance preference is used on all routers".  The combination of different implementations and the lack of an absolute requirement to ensure consistency can easily be non-deterministic. 

This point is related to the text in §2.6 which talks about how "the ingress node MUST resolve" collisions the same way.  Because of the lack of an absolute requirement for consistency, this "MUST" doesn't guarantee the same result.

Also related is this text in §2.5.1: "All routers in a routing domain SHOULD use the same tie-breaking rules to maximize forwarding consistency."  When would all routers not use the same rules?  It seems to me that forwarding consistency is very important and would want to be maximized all the time.  IOW, why not use MUST?

I'm making this point a DISCUSS item because it is directly related to the ability of multiple implementations to interoperate.
2019-04-10
19 Alvaro Retana
[Ballot comment]
(1) §2.2: "A global segment MUST be a label, or an index which may be mapped to an MPLS label within the Segment …
[Ballot comment]
(1) §2.2: "A global segment MUST be a label, or an index which may be mapped to an MPLS label within the Segment Routing Global Block (SRGB)..."  I don't think this sentence fragment is clear: the intent is surely to say that the global segment MUST be mapped within the SRGB (and not that it "MUST be a label"), right?  Suggestion: s/A global segment MUST be a label, or an index which may be mapped/A global segment is a label, or an index which MUST be mapped

(2) §2.5: "Suppose an anycast prefix...the advertisement of the prefix-SID by some, but not all, of advertising nodes SHOULD NOT be treated as a label collision."  I'm not sure how the receiver knows if the SID was advertised "by some, but not all"...or even if the prefix is being used as anycast.  Given the Normative language, please explain.  IOW, please clarify the difference between a duplicate prefix-SID and an anycast prefix.  The use of "SHOULD NOT" above seems to imply that there are cases when the situation should be treated as a label collision...what are those cases?

(3) §2.5: "The remaining FECs with the default algorithm...are installed in the FIB...without any incoming labels..."  What will these entries be used for?  Given that we're talking about an MPLS network, there may be no traffic that matches the FEC (the traffic should be labeled)...if that is the case, then why install in the FIB at all?  OTOH, if there is a possibility that unlabeled traffic is received, then this entry (meant for a different purpose) could be used...also not an ideal situation.

§2.6 makes the case that in order "to minimize the chance of misforwarding, a FEC that loses its incoming label...MUST NOT be installed in FIB".  This inconsistency adds strength to my questions above.

(4) §2.5.1: "if more than one competing FEC remains after step 1, select the smallest numerical FEC value"  What value?  Are you referring to the FEC type (introduced later in this section)?  If so, please be explicit and consistent.

(5) §2.5.2.1: The illustration seems incomplete as the rules in §2.5.2 say that
"the receiving instance MUST compute its local label", but in this case "B decides not to advertise any index".  The second part of the example (in §2.5.2.2) seems to complete the scenario.  It seems confusing to me that the first part shows an incomplete case...or am I misinterpreting the rules?

(6) §2.7: "PUSH, NEXT, and CONTINUE...The specifications of these operations can be found in [RFC8402]. This sub-section specifies how to implement each of these operations in the MPLS forwarding plane."  It seems contradictory that the specification is in two places...  In any case, I think that this section is unnecessary as it doesn't seem to add anything from what rfc8402 already explains.

(7) Nits...

s/flooding mechanisms of link state IGPs fits/flooding mechanisms of link state IGPs fit

s/to have a node segment to reach the node/to have a node segment reach the node

s/per routing instance, topology, algorithm/per routing instance, topology, or algorithm

s/except rule/except the rule

s/local label serves/a local label serves

s/subTLVs/sub-TLVs

s/Remaining FECs/The remaining FECs

s/installed in FIB/installed in the FIB

s/lowest value SHOULD be/lowest value SHOULD be:

s/SR Algorithm,)/SR Algorithm)
2019-04-10
19 Alvaro Retana [Ballot Position Update] New position, Discuss, has been recorded for Alvaro Retana
2019-04-10
19 Roman Danyliw
[Ballot comment]
(1) Section 1.  Shouldn’t RFC8402 be “[RFC8402]”?

(2) Section 1.  First use of the acronym, but above there was no “Segment …
[Ballot comment]
(1) Section 1.  Shouldn’t RFC8402 be “[RFC8402]”?

(2) Section 1.  First use of the acronym, but above there was no “Segment Routing (SR)”.

(3) Section 2.1.  Editorial.  s/,…,etc/, etc./

(4) Section 2.4.  The variable name in the text is “Size” and “size” in the equation.  They should be consistent.

(5) Section 2.4.  Per Step #5 of the collision resolution procedure, could you please clarify what is a “non-zero algorithm”?

(6) Section 2.5.1.  Could you please clarify what “better administrative distance means”.  Per the tie-breaking rules above, I assume you mean it is a lower administrative distance.

(7) Section 2.5.1, for the sub-bullets under “The fields of each FEC are encoded as follows”, consider adding periods to the first two bullets:

s/significant bits are set to zero/ significant bits are set to zero./

s/the numerical value for IPv6/the numerical value for IPv6./

(8) The Security Considerations references [RFC8402] to lay out the assumed trust model and a few of the possible implications (malicious looping, evasion of access control, hiding of the source of DoS attacks) if this model is violated.  I concur on the language in the reference.  I believe there are a few more things to explicitly point out:

** Per the implications, routing traffic through an observation point controlled by the attacker is another key privacy and integrity concern.

** Per the already stated implication, “malicious loop” feels too soft as the overall availability of the network can be affected (e.g., loops, slowing traffic down).

FWIW, I’m not raising this to a DISCUSS because there is no normative language to address these issues, only additional proposed cautionary language of the threat.
2019-04-10
19 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2019-04-10
19 Deborah Brungard
[Ballot comment]
Noting Mirja's comment asking why is this not Informational, I agree with the current track "PS" as it defines
(using RFC2119 keywords) SR-MPLS …
[Ballot comment]
Noting Mirja's comment asking why is this not Informational, I agree with the current track "PS" as it defines
(using RFC2119 keywords) SR-MPLS procedures for an MPLS dataplane.

Section 2
(my previous Discuss point)
- 1.    The text in Section 1 states “An implementation SHOULD
check that an IGP node-SID is not associated with a prefix that is owned by more than one router
within the same routing domain. If so, it SHOULD NOT use this Node-SID, MAY use another one if
available, and SHOULD log an error”.

Sasha suggested MAY/s/SHOULD or MUST,  saying MUST aligns with Section 3.2/RFC8402, which uses
the wording "MUST NOT" be used by another router.

While the document was changed to "SHOULD",  my point was that I agreed with Sasha on this,
to align with RFC8402, it needs to be a "MUST".

Though reading later in RFC8402's Section 9 Manageability Considerations, I see it uses a "SHOULD".
So I'll defer to the authors/working group on their preference.

On my previous Discuss, I asked how does an implementation "check"?
In RFC8402's Manageability Considerations, it says "In addition to the allocation policy/tooling that the
operator will have in place, an implementation SHOULD protect the network in case of conflict detection
by providing a deterministic resolution approach." So while I prefer RFC8402's more explicit operational
guidance vs. "check", I'll defer to the authors. My concern is not so much for MPLS operators, this is nothing
new, but to say something more accurate than "check" in an RFC.

Nit (overall)
I was surprised/disappointed there was no alignment on terminology with RFC8402. For example, RFC8402
defines terms for SR MPLS, e.g. SR-MPLS, but this document doesn't use any of RFC8402's defined MPLS terms.

Suggestion at minimum a fix for the Abstract:
Segment Routing (SR) leverages the source routing paradigm.
/s/
Segment Routing (SR) leverages the source routing paradigm as defined in [RFC8402].
And:
This document specifies the forwarding behavior to allow instantiating SR over the
MPLS dataplane.
/s/
This document specifies the forwarding behavior to allow instantiating SR over the
MPLS dataplane (SR-MPLS).

Nit: Section 2
I had difficulty parsing the first bullet:
From a control plane perspective, [RFC3031] does not mandate a single signaling protocol.  Segment Routing makes
use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding
mechanisms of link state IGPs fits very well with label stacking on ingress. Future control layer protocol and/or
policy/configuration can be used to specify the label stack.
/suggest/
From a control plane perspective, [RFC3031] does not mandate a single control protocol or use of a control protocol.
Segment Routing makes use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions].
Future control layer protocols are not precluded and/or management policy/configuration can be used to specify the label stack.
2019-04-10
19 Deborah Brungard [Ballot Position Update] Position for Deborah Brungard has been changed to No Objection from Discuss
2019-04-10
19 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2019-04-10
19 Éric Vyncke
[Ballot comment]
It is time to publish this one.

Nits
----

In section 2, "The flooding mechanisms of link state IGPs fits very well with …
[Ballot comment]
It is time to publish this one.

Nits
----

In section 2, "The flooding mechanisms of link state IGPs fits very well with label stacking on ingress" while I do not disagree with the statement, it is somehow out of the blue: either explain shortly why or delete the sentence if so obvious. Note: or even keep it like it is now.

Section 2.5.1, binary numbers 100 and 110 should probably explicitly qualified as binary representations.

Some typos in name or spacing in sections 6 and 7
2019-04-10
19 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2019-04-09
19 Deborah Brungard
[Ballot discuss]
I didn't see a fix/response to one of Sasha's identified items in his RTG Dir review:

- 1.    The text in Section …
[Ballot discuss]
I didn't see a fix/response to one of Sasha's identified items in his RTG Dir review:

- 1.    The text in Section 1 states “An implementation MAY
check that an IGP node-SID is not associated with a prefix that is owned by more than one router
within the same routing domain, If so, it SHOULD NOT use this Node-SID, MAY use another one if
available, and SHOULD log an error”.

Sasha suggested MAY/s/SHOULD or MUST,  saying this aligns with Section 3.2/RFC8402, which uses
the wording "MUST NOT" be used by another router.

I agree with Sasha, to align, it would be a "MUST", so why the softer requirement? Also, how does an
implementation "check"? Wouldn't it be simply "An implementation MUST ensure that an.."?
Or the operator (NMS) needs to ensure (e.g. RFC8402 says typically allocated by policy of the operator)?
2019-04-09
19 Deborah Brungard
[Ballot comment]
Noting Mirja's comment asking why is this not Informational, I agree with the current track as "PS" as it does define
(using RFC2119 …
[Ballot comment]
Noting Mirja's comment asking why is this not Informational, I agree with the current track as "PS" as it does define
(using RFC2119 keywords) procedures (labels).

Nit: Section 2
I had difficulty parsing the first bullet:
From a control plane perspective, [RFC3031] does not mandate a single signaling protocol.  Segment Routing makes
use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding
mechanisms of link state IGPs fits very well with label stacking on ingress. Future control layer protocol and/or
policy/configuration can be used to specify the label stack.
/suggest/
From a control plane perspective, [RFC3031] does not mandate a single control protocol or use of a control protocol.
Segment Routing makes use of various control plane protocols such as link state IGPs [I-D.ietf-isis-segment-routing-extensions],
[I-D.ietf-ospf-segment-routing-extensions] and [I-D.ietf-ospf-ospfv3-segment-routing-extensions]. The flooding
mechanisms of link state IGPs fits very well with label stacking on ingress. Future control layer protocols are not precluded
and/or management policy/configuration can be used to specify the label stack.
2019-04-09
19 Deborah Brungard [Ballot Position Update] New position, Discuss, has been recorded for Deborah Brungard
2019-04-09
19 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2019-04-09
19 Ignas Bagdonas [Ballot comment]
Thank you for this work, the industry needs it.

A nit: sA.2.2: s/sid/SID
2019-04-09
19 Ignas Bagdonas [Ballot Position Update] New position, Yes, has been recorded for Ignas Bagdonas
2019-04-05
19 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2019-04-05
19 Mirja Kühlewind [Ballot comment]
Given this document does not introduce any change in the MPLS data plane, I think it could also be published as informational.
2019-04-05
19 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2019-04-04
19 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2019-04-04
19 Amy Vezza Placed on agenda for telechat - 2019-04-11
2019-04-04
19 Martin Vigoureux IESG state changed to IESG Evaluation from Waiting for Writeup
2019-04-04
19 Martin Vigoureux Ballot has been issued
2019-04-04
19 Martin Vigoureux [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux
2019-04-04
19 Martin Vigoureux Created "Approve" ballot
2019-04-04
19 Martin Vigoureux Ballot writeup was changed
2019-03-28
19 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2019-03-28
19 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-19.txt
2019-03-28
19 (System) New version approved
2019-03-28
19 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2019-03-28
19 Ahmed Bashandy Uploaded new revision
2019-03-11
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2019-03-11
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Joel Jaeggli
2019-03-10
18 Min Ye Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein.
2019-03-07
18 Francis Dupont Request for Last Call review by GENART Completed: Ready. Reviewer: Francis Dupont.
2019-03-07
18 (System) IESG state changed to Waiting for Writeup from In Last Call
2019-03-04
18 Scott Bradner Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected
2019-03-04
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-03-04
18 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2019-02-28
18 Linda Dunbar Request for Last Call review by SECDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list.
2019-02-28
18 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2019-02-28
18 Amanda Baber
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-spring-segment-routing-mpls-18, which is currently in Last Call, and has the following comments:

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

The IANA Functions Operator has reviewed draft-ietf-spring-segment-routing-mpls-18, 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
2019-02-27
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-02-27
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Linda Dunbar
2019-02-27
18 Tero Kivinen Assignment of request for Last Call review by SECDIR to Roman Danyliw was rejected
2019-02-27
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Roman Danyliw
2019-02-27
18 Tero Kivinen Request for Last Call review by SECDIR is assigned to Roman Danyliw
2019-02-21
18 Min Ye Request for Last Call review by RTGDIR is assigned to Sasha Vainshtein
2019-02-21
18 Min Ye Request for Last Call review by RTGDIR is assigned to Sasha Vainshtein
2019-02-21
18 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2019-02-21
18 Jean Mahoney Request for Last Call review by GENART is assigned to Francis Dupont
2019-02-21
18 Cindy Morgan IANA Review state changed to IANA - Review Needed
2019-02-21
18 Cindy Morgan
The following Last Call announcement was sent out (ends 2019-03-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org, spring-chairs@ietf.org, Shraddha Hegde , …
The following Last Call announcement was sent out (ends 2019-03-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-spring-segment-routing-mpls@ietf.org, spring@ietf.org, spring-chairs@ietf.org, Shraddha Hegde , shraddha@juniper.net, martin.vigoureux@nokia.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Segment Routing with MPLS data plane) to Proposed Standard


The IESG has received a request from the Source Packet Routing in Networking
WG (spring) to consider the following document: - 'Segment Routing with MPLS
data plane'
  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-03-07. 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


  Segment Routing (SR) leverages the source routing paradigm.  A node
  steers a packet through a controlled set of instructions, called
  segments, by prepending the packet with an SR header.  In the MPLS
  dataplane, the SR header is instantiated through a label stack. This
  document specifies the forwarding behavior to allow instantiating SR
  over the MPLS dataplane.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-spring-segment-routing-mpls/ballot/

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

  https://datatracker.ietf.org/ipr/2880/
  https://datatracker.ietf.org/ipr/2453/
  https://datatracker.ietf.org/ipr/2454/





2019-02-21
18 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2019-02-21
18 Martin Vigoureux Last call was requested
2019-02-21
18 Martin Vigoureux Ballot approval text was generated
2019-02-21
18 Martin Vigoureux Ballot writeup was generated
2019-02-21
18 Martin Vigoureux IESG state changed to Last Call Requested from AD Evaluation
2019-02-21
18 Martin Vigoureux Last call announcement was generated
2019-02-21
18 Martin Vigoureux Requested Last Call review by RTGDIR
2018-12-19
18 Martin Vigoureux IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-12-10
18 Bruno Decraene IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-12-09
18 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-18.txt
2018-12-09
18 (System) New version approved
2018-12-09
18 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-12-09
18 Ahmed Bashandy Uploaded new revision
2018-12-03
17 Bruno Decraene Additional one week WGLC on the changes since the last call on version -13
https://mailarchive.ietf.org/arch/msg/spring/KqfmBDrOqcyDApwWLWcKv1-lQtk
2018-12-03
17 Bruno Decraene IETF WG state changed to In WG Last Call from Waiting for WG Chair Go-Ahead
2018-12-03
17 Martin Vigoureux IESG state changed to AD Evaluation from AD is watching
2018-12-03
17 Martin Vigoureux
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

Proposed Standard is requested. This is in the Document header.
This is appropriate because this Document specifies the generic functions of the architecture,
when applied to MPLS, even if no change is made to the MPLS data plane.

(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

  Segment Routing (SR) leverages the source routing paradigm.  A node
  steers a packet through a controlled set of instructions, called
  segments, by prepending the packet with an SR header.  In the MPLS
  dataplane, the SR header is instantiated through a label stack.  A
  segment can represent any instruction, topological or service-based.
  Additional segments can be defined in the future.  SR allows to
  enforce a flow through any topological path and/or service chain
  while maintaining per-flow state only at the ingress node to the SR
  domain.
  Segment Routing can be directly applied to the MPLS architecture with
  no change in the forwarding plane.  This drafts describes how Segment
  Routing operates on top of the MPLS data plane.

Working Group Summary

  There is consensus amongst the Working Group to progress this Document towards becoming a Proposed Standard RFC

Document Quality

  The Document is quite well written and has undergone editing work to become more focused on its key aspect.
  Several implementations of Segment Routing exist.

Personnel

  Shraddha Hegde is the Document Shepherd
  Martin Vigoureux 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 done a full review of the Document following up the reviews which were made as part of the WG LC.
There was active WG involvement in the review of the document which resulted in an appendix with clear examples. 

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

no concern.

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

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

(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 authors have confirmed that.

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

3 IPR disclosures exist against this Document. No specific opinion was expressed with regard to these disclosures.

(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 Working Group consensus is solid.

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

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

IDnits is clean (except for the absence of IPv6 addresses in the illustration examples)

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

no formal review criteria applies to this Document.

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

Yes

(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 Normative references are standards.

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

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

This Document will not change the status of any pre-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).

This Document makes no request to IANA.

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

not applicable.

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

not applicable.
2018-12-03
17 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-17.txt
2018-12-03
17 (System) New version approved
2018-12-03
17 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-12-03
17 Ahmed Bashandy Uploaded new revision
2018-11-21
16 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-16.txt
2018-11-21
16 (System) New version approved
2018-11-21
16 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-11-21
16 Ahmed Bashandy Uploaded new revision
2018-10-30
15 Bruno Decraene Tag Revised I-D Needed - Issue raised by WGLC cleared.
2018-10-22
15 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-15.txt
2018-10-22
15 (System) New version approved
2018-10-22
15 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-10-22
15 Ahmed Bashandy Uploaded new revision
2018-10-16
14 Bruno Decraene https://mailarchive.ietf.org/arch/msg/spring/qgdxW_PzpT3JyZKzq9slGopBpbI
2018-10-16
14 Bruno Decraene IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2018-07-09
14 Bruno Decraene Tag Revised I-D Needed - Issue raised by WGLC set.
2018-06-11
14 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-14.txt
2018-06-11
14 (System) New version approved
2018-06-11
14 (System) Request for posting confirmation emailed to previous authors: Bruno Decraene , Ahmed Bashandy , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-06-11
14 Ahmed Bashandy Uploaded new revision
2018-06-10
13 Min Ye Request for Early review by RTGDIR Completed: Has Issues. Reviewer: Sasha Vainshtein.
2018-05-24
13 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Sasha Vainshtein
2018-05-24
13 Jonathan Hardwick Request for Early review by RTGDIR is assigned to Sasha Vainshtein
2018-05-24
13 Bruno Decraene Requested Early review by RTGDIR
2018-05-24
13 Bruno Decraene WGLC: https://mailarchive.ietf.org/arch/msg/spring/o40neewPwG_I9LscowkCv0x3bZU

IPR Call: https://mailarchive.ietf.org/arch/msg/spring/8AAPP4CZwf3HCI6R-M8pUWd5yc4
2018-05-24
13 Bruno Decraene Tag Revised I-D Needed - Issue raised by AD cleared.
2018-05-24
13 Bruno Decraene IETF WG state changed to In WG Last Call from WG Document
2018-04-02
13 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-13.txt
2018-04-02
13 (System) New version approved
2018-04-02
13 (System)
Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Stefano Previdi , Rob Shakir , …
Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-04-02
13 Ahmed Bashandy Uploaded new revision
2018-03-23
12 Alvaro Retana Notification list changed to Shraddha Hegde <shraddha@juniper.net> from aretana.ietf@gmail.com, Shraddha Hegde <shraddha@juniper.net>
2018-03-23
12 Alvaro Retana Shepherding AD changed to Martin Vigoureux
2018-03-09
12 Bruno Decraene Notification list changed to aretana.ietf@gmail.com, Shraddha Hegde <shraddha@juniper.net> from aretana.ietf@gmail.com
2018-03-09
12 Bruno Decraene Document shepherd changed to Shraddha Hegde
2018-03-08
12 Bruno Decraene Added to session: IETF-101: spring  Fri-1150
2018-02-23
12 Alvaro Retana
https://mailarchive.ietf.org/arch/msg/spring/qJ2lacniDYJhAUrsbLC202K2sTo/?qid=9b2b2b994dbf4e1c7ab0057be183f890

I still haven’t seen a satisfactory reply to my AD Review of this document
[1].  The latest version doubled (!) the size of the …
https://mailarchive.ietf.org/arch/msg/spring/qJ2lacniDYJhAUrsbLC202K2sTo/?qid=9b2b2b994dbf4e1c7ab0057be183f890

I still haven’t seen a satisfactory reply to my AD Review of this document
[1].  The latest version doubled (!) the size of the document (between
versions -10 and -12)[2] without proper justification, or (more
importantly!) discussion on the list.

I am returning the document to the WG for proper discussion of the proposed
changes.

[1] https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=630f4b40ce9622377f9d39fe84fdab1a

[2] https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-segment-routing-mpls-10&url2=draft-ietf-spring-segment-routing-mpls-12
2018-02-23
12 Alvaro Retana Tag Revised I-D Needed - Issue raised by AD set.
2018-02-23
12 Alvaro Retana IETF WG state changed to WG Document from Submitted to IESG for Publication
2018-02-23
12 Alvaro Retana
https://mailarchive.ietf.org/arch/msg/spring/qJ2lacniDYJhAUrsbLC202K2sTo/?qid=9b2b2b994dbf4e1c7ab0057be183f890

I still haven’t seen a satisfactory reply to my AD Review of this document
[1].  The latest version doubled (!) the size of the …
https://mailarchive.ietf.org/arch/msg/spring/qJ2lacniDYJhAUrsbLC202K2sTo/?qid=9b2b2b994dbf4e1c7ab0057be183f890

I still haven’t seen a satisfactory reply to my AD Review of this document
[1].  The latest version doubled (!) the size of the document (between
versions -10 and -12)[2] without proper justification, or (more
importantly!) discussion on the list.

I am returning the document to the WG for proper discussion of the proposed
changes.

[1] https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=630f4b40ce9622377f9d39fe84fdab1a

[2] https://www.ietf.org/rfcdiff?url1=draft-ietf-spring-segment-routing-mpls-10&url2=draft-ietf-spring-segment-routing-mpls-12
2018-02-23
12 Alvaro Retana IESG state changed to AD is watching from AD Evaluation::AD Followup
2018-02-23
12 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-02-23
12 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-12.txt
2018-02-23
12 (System) New version approved
2018-02-23
12 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2018-02-23
12 Ahmed Bashandy Uploaded new revision
2017-12-01
11 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2017-11-06
11 Bruno Decraene Added to session: IETF-100: spring  Wed-1520
2017-11-01
11 Alvaro Retana Notification list changed to aretana.ietf@gmail.com
2017-10-30
11 (System) Sub state has been changed to AD Followup from Revised ID Needed
2017-10-30
11 Ahmed Bashandy New version available: draft-ietf-spring-segment-routing-mpls-11.txt
2017-10-30
11 (System) New version approved
2017-10-30
11 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2017-10-30
11 Ahmed Bashandy Uploaded new revision
2017-08-23
10 Alvaro Retana == AD Review of draft-ietf-spring-segment-routing-mpls-10 ==

https://mailarchive.ietf.org/arch/msg/spring/97KtDebyroHfuNvllpNVb0s66H8/?qid=ea9e640a7e47f57075cdb277170c33a0
2017-08-23
10 Alvaro Retana IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2017-08-10
10 Alvaro Retana IESG state changed to AD Evaluation from Publication Requested
2017-06-22
10 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-10.txt
2017-06-22
10 (System) New version approved
2017-06-22
10 (System) Request for posting confirmation emailed to previous authors: Ahmed Bashandy , Bruno Decraene , Clarence Filsfils , Stefano Previdi , Rob Shakir , Stephane Litkowski
2017-06-22
10 Stefano Previdi Uploaded new revision
2017-06-20
09 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-09.txt
2017-06-20
09 (System) New version approved
2017-06-20
09 (System)
Request for posting confirmation emailed to previous authors: Stefano Previdi , Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Rob Shakir , …
Request for posting confirmation emailed to previous authors: Stefano Previdi , Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Clarence Filsfils , Rob Shakir , Stephane Litkowski
2017-06-20
09 Stefano Previdi Uploaded new revision
2017-03-13
08 Martin Vigoureux
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

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

Proposed Standard is requested. This is in the Document header.
This is appropriate because this Document specifies the generic functions of the architecture, when applied to MPLS, even if no change is made to the MPLS data plane.

(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

  Segment Routing (SR) leverages the source routing paradigm.  A node
  steers a packet through a controlled set of instructions, called
  segments, by prepending the packet with an SR header.  In the MPLS
  dataplane, the SR header is instantiated through a label stack.  A
  segment can represent any instruction, topological or service-based.
  Additional segments can be defined in the future.  SR allows to
  enforce a flow through any topological path and/or service chain
  while maintaining per-flow state only at the ingress node to the SR
  domain.
  Segment Routing can be directly applied to the MPLS architecture with
  no change in the forwarding plane.  This drafts describes how Segment
  Routing operates on top of the MPLS data plane.

Working Group Summary

  There is consensus amongst the Working Group to progress this Document towards becoming a Proposed Standard RFC

Document Quality

  The Document is quite well written and has undergone editing work to become more focused on its key aspect.
  Several implementations of Segment Routing exist.

Personnel

  Martin Vigoureux is the Document Shepherd
  Alvaro Retana 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 done a full review of the Document following up the reviews which were made as part of the WG LC.
This led to an important rework of the Document, triming it to the essential elements which needed to be highlighted. 

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

no concern.

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

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

(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 authors have confirmed that.

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

3 IPR disclosures exist against this Document. No specific opinion was expressed with regard to these disclosures.

(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 Working Group consensus is solid.

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

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

IDnits is clean (except for the absence of IPv6 addresses in the illustration examples)

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

no formal review criteria applies to this Document.

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

Yes

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

One Normative Reference is still an Internet-Draft but is already in the hands of IESG for advancement as a Proposed Standard RFC.

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

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

This Document will not change the status of any pre-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).

This Document makes no request to IANA.

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

not applicable.

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

not applicable.
2017-03-13
08 Martin Vigoureux Responsible AD changed to Alvaro Retana
2017-03-13
08 Martin Vigoureux IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2017-03-13
08 Martin Vigoureux IESG state changed to Publication Requested
2017-03-13
08 Martin Vigoureux IESG process started in state Publication Requested
2017-03-10
08 Martin Vigoureux Changed document writeup
2017-03-10
08 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-08.txt
2017-03-10
08 (System) New version approved
2017-03-10
08 (System)
Request for posting confirmation emailed to previous authors: Stefano Previdi , Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Edward Crabbe , " jefftant@gmail.com" …
Request for posting confirmation emailed to previous authors: Stefano Previdi , Ahmed Bashandy , Bruno Decraene , spring-chairs@ietf.org, Edward Crabbe , " jefftant@gmail.com" , Clarence Filsfils , Martin Horneffer , Rob Shakir , Stephane Litkowski
2017-03-10
08 Stefano Previdi Uploaded new revision
2017-02-14
07 Martin Vigoureux IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2017-02-07
07 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-07.txt
2017-02-07
07 (System) New version approved
2017-02-07
07 (System)
Request for posting confirmation emailed to previous authors: "Martin Horneffer" , spring-chairs@ietf.org, "Stephane Litkowski" , "Clarence Filsfils" , "Bruno Decraene" , "Edward Crabbe" , …
Request for posting confirmation emailed to previous authors: "Martin Horneffer" , spring-chairs@ietf.org, "Stephane Litkowski" , "Clarence Filsfils" , "Bruno Decraene" , "Edward Crabbe" , "Stefano Previdi" , " jefftant@gmail.com" , "Rob Shakir" , "Ahmed Bashandy"
2017-02-07
07 Stefano Previdi Uploaded new revision
2017-02-06
06 Martin Vigoureux IETF WG state changed to In WG Last Call from WG Document
2017-01-27
06 Martin Vigoureux Notification list changed to none from "Martin Vigoureux" <martin.vigoureux@nokia.com>
2017-01-06
06 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-06.txt
2017-01-06
06 (System) New version approved
2017-01-06
06 (System)
Request for posting confirmation emailed to previous authors: "Martin Horneffer" , spring-chairs@ietf.org, "Stephane Litkowski" , "Clarence Filsfils" , "Bruno Decraene" , "Edward Crabbe" , …
Request for posting confirmation emailed to previous authors: "Martin Horneffer" , spring-chairs@ietf.org, "Stephane Litkowski" , "Clarence Filsfils" , "Bruno Decraene" , "Edward Crabbe" , "Stefano Previdi" , " jefftant@gmail.com" , "Rob Shakir" , "Ahmed Bashandy"
2017-01-06
06 Stefano Previdi Uploaded new revision
2016-09-23
Jasmine Magallanes Posted related IPR disclosure: Cisco's Statement about IPR related to draft-ietf-spring-segment-routing-mpls
2016-09-09
05 Martin Vigoureux Notification list changed to "Martin Vigoureux" <martin.vigoureux@nokia.com>
2016-09-09
05 Martin Vigoureux Document shepherd changed to Martin Vigoureux
2016-07-12
05 Bruno Decraene Added to session: IETF-96: spring  Mon-1800
2016-07-06
05 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-05.txt
2016-03-18
04 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-04.txt
2016-02-01
03 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-03.txt
2015-10-17
02 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-02.txt
2015-05-29
01 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-01.txt
2014-12-02
00 Alvaro Retana Intended Status changed to Proposed Standard from None
2014-12-02
00 Alvaro Retana This document now replaces draft-filsfils-spring-segment-routing-mpls instead of None
2014-12-02
00 Stefano Previdi New version available: draft-ietf-spring-segment-routing-mpls-00.txt