< draft-ietf-spring-segment-routing-mpls-11.txt   draft-ietf-spring-segment-routing-mpls-12.txt >
Network Working Group C. Filsfils, Ed. Network Working Group A. Bashandy, Ed.
Internet Draft S. Previdi, Ed. Internet Draft C. Filsfils, Ed.
Intended status: Standards Track A. Bashandy Intended status: Standards Track S. Previdi,
Expires: April 2018 Cisco Systems, Inc. Expires: August 2018 Cisco Systems, Inc.
B. Decraene B. Decraene
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
Google Google
October 27, 2017 February 23, 2018
Segment Routing with MPLS data plane Segment Routing with MPLS data plane
draft-ietf-spring-segment-routing-mpls-11 draft-ietf-spring-segment-routing-mpls-12
Abstract Abstract
Segment Routing (SR) leverages the source routing paradigm. A node Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through a controlled set of instructions, called steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. In the MPLS segments, by prepending the packet with an SR header. In the MPLS
dataplane, the SR header is instantiated through a label stack. This dataplane, the SR header is instantiated through a label stack. This
document specifies the forwarding behavior to allow instantiating SR document specifies the forwarding behavior to allow instantiating SR
over the MPLS dataplane. over the MPLS dataplane.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 27, 2009. This Internet-Draft will expire on August 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 33 skipping to change at page 2, line 33
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. MPLS Instantiation of Segment Routing..........................3 2. MPLS Instantiation of Segment Routing..........................3
2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix 2.1. Supporting Multiple Forwarding Behaviors for the Same Prefix
...............................................................4 ...............................................................4
2.2. SID Representation in the MPLS Forwarding Plane...........4 2.2. SID Representation in the MPLS Forwarding Plane...........4
2.3. Segment Routing Global Block and Local Block..............5 2.3. Segment Routing Global Block and Local Block..............5
2.4. Mapping a SID Index to an MPLS label......................6 2.4. Mapping a SID Index to an MPLS label......................6
2.5. PUSH, CONTINUE, and NEXT..................................6 2.5. Incoming Label Collision..................................6
2.5.1. PUSH.................................................6 2.5.1. Tie-breaking Rules...................................8
2.5.2. CONTINUE.............................................7 2.5.2. Redistribution between Routing Protocol Instances...11
2.5.3. NEXT.................................................7 2.5.2.1. Illustration...................................11
2.6. MPLS Label downloaded to FIB corresponding to Global and 2.6. Outgoing Label Collision.................................11
Local SIDs.....................................................7 2.7. PUSH, CONTINUE, and NEXT.................................12
2.7. Active Segment............................................7 2.7.1. PUSH................................................12
2.8. Forwarding behavior for Global SIDs.......................8 2.7.2. CONTINUE............................................12
2.8.1. Forwarding Behavior for PUSH and CONTINUE Operation for 2.7.3. NEXT................................................12
Global SIDs.................................................8 2.8. MPLS Label downloaded to FIB corresponding to Global and
2.8.2. Forwarding Behavior for NEXT Operation for Global SIDs9 Local SIDs....................................................13
2.9. Forwarding Behavior for Local SIDs.......................10 2.9. Active Segment...........................................13
2.9.1. Forwarding Behavior Corresponding to PUSH Operation on 2.10. Forwarding behavior for Global SIDs.....................13
Local SIDs.................................................10 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for
2.9.2. Forwarding Behavior Corresponding to CONTINUE Operation Global SIDs................................................13
for Local SIDs.............................................10 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs
2.9.3. Outgoing label for NEXT Operation for Local SIDs....11 ...........................................................15
3. IGP Segments Examples.........................................11 2.11. Forwarding Behavior for Local SIDs......................15
3.1. Example 1................................................12 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on
3.2. Example 2................................................13 Local SIDs.................................................15
3.3. Example 3................................................14 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation
3.4. Example 4................................................14 for Local SIDs.............................................16
3.5. Example 5................................................14 2.11.3. Outgoing label for NEXT Operation for Local SIDs...16
4. IANA Considerations...........................................15 3. IGP Segments Examples.........................................16
5. Manageability Considerations..................................15 3.1. Example 1................................................17
6. Security Considerations.......................................15 3.2. Example 2................................................18
7. Contributors..................................................15 3.3. Example 3................................................19
8. Acknowledgements..............................................16 3.4. Example 4................................................19
9. References....................................................16 3.5. Example 5................................................19
9.1. Normative References.....................................16 4. IANA Considerations...........................................20
9.2. Informative References...................................17 5. Manageability Considerations..................................20
6. Security Considerations.......................................20
7. Contributors..................................................20
8. Acknowledgements..............................................21
9. References....................................................21
9.1. Normative References.....................................21
9.2. Informative References...................................22
1. Introduction 1. Introduction
The Segment Routing architecture [I-D.ietf-spring-segment-routing] The Segment Routing architecture [I-D.ietf-spring-segment-routing]
can be directly applied to the MPLS architecture with no change in can be directly applied to the MPLS architecture with no change in
the MPLS forwarding plane. This document specifies the forwarding the MPLS forwarding plane. This document specifies the forwarding
plane behavior to allow Segment Routing to operate on top of the MPLS plane behavior to allow Segment Routing to operate on top of the MPLS
data plane. This document does not address the control plane data plane. This document does not address the control plane
behavior. Control plane behavior is specified in other documents such behavior. Control plane behavior is specified in other documents such
as [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf- as [I-D.ietf-isis-segment-routing-extensions], [I-D.ietf-ospf-
skipping to change at page 5, line 28 skipping to change at page 5, line 28
any reserved label value or range [reserved-MPLS], respectively. any reserved label value or range [reserved-MPLS], respectively.
2.3. Segment Routing Global Block and Local Block 2.3. Segment Routing Global Block and Local Block
The concepts of Segment Routing Global Block (SRGB) and global SID The concepts of Segment Routing Global Block (SRGB) and global SID
are explained in [I-D.ietf-spring-segment-routing]. In general, the are explained in [I-D.ietf-spring-segment-routing]. In general, the
SRGB need not be a contiguous range of labels. SRGB need not be a contiguous range of labels.
For the rest of this document, the SRGB is specified by the list of For the rest of this document, the SRGB is specified by the list of
MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)] MPLS Label ranges [Ll(1),Lh(1)], [Ll(2),Lh(2)],..., [Ll(k),Lh(k)]
where Ll(i) =< Lh(i) and the ranges do not overlap. where Ll(i) =< Lh(i).
The following rules apply to the list of MPLS ranges representing the The following rules apply to the list of MPLS ranges representing the
SRGB SRGB
o The list of label ranges MUST only be used to instantiate global o The list of ranges comprising the SRGB MUST NOT overlap.
SIDs into the MPLS forwarding plane
o Every range in the list of ranges specifying the SRGB MUST NOT o Every range in the list of ranges specifying the SRGB MUST NOT
cover or overlap with a reserved label value or range [reserved- cover or overlap with a reserved label value or range [reserved-
MPLS], respectively. MPLS], respectively.
o 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 is
completely ignored and the node is treated as if it does not have
an SRGB.
o The list of label ranges MUST only be used to instantiate global
SIDs into the MPLS forwarding plane
Local segments MAY be allocated from the Segment Routing Local Block Local segments MAY be allocated from the Segment Routing Local Block
(SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as (SRLB) [I-D.ietf-spring-segment-routing] or from any unused label as
long as it does not use a reserved label. The SRLB consists of the long as it does not use a reserved label. The SRLB consists of the
range of local labels reserved by the node for certain local range of local labels reserved by the node for certain local
segments. In a controller-driven network, some controllers or segments. In a controller-driven network, some controllers or
applications MAY use the control plane to discover the available set applications MAY use the control plane to discover the available set
of local SIDs on a particular router [I.D. filsfils-spring-segment- of local SIDs on a particular router [I.D. filsfils-spring-segment-
routing-policy]. Just like SRGB, the SRLB need not be a single routing-policy]. Just like SRGB, the SRLB need not be a single
contiguous range of label, except the SRGB MUST only be used to contiguous range of label, except the SRGB MUST only be used to
instantiate global SIDs into the MPLS forwarding plane. Hence it is instantiate global SIDs into the MPLS forwarding plane. Hence it is
specified the same way and follows the same rules SRGB is specified specified the same way and follows the same rules SRGB is specified
above in this sub-section. above in this sub-section.
2.4. Mapping a SID Index to an MPLS label 2.4. Mapping a SID Index to an MPLS label
This sub-section specifies how the MPLS label value is calculated This sub-section specifies how the MPLS label value is calculated
given the index of a SID. The value of the index is determined by an given the index of a SID. The value of the index is determined by an
MCC such as ISIS [I-D.ietf-isis-segment-routing-extensions] or OSPF MCC such as IS-IS [I-D.ietf-isis-segment-routing-extensions] or OSPF
[I-D.ietf-ospf-segment-routing-extensions]. This section only [I-D.ietf-ospf-segment-routing-extensions]. This section only
specifies how to map the index to an MPLS label. The calculated MPLS specifies how to map the index to an MPLS label. The calculated MPLS
label is downloaded to the FIB, sent out with a forwarded packet, or label is downloaded to the FIB, sent out with a forwarded packet, or
both. both.
Consider a SID represented by the index "I". Consider an SRGB as Consider a SID represented by the index "I". Consider an SRGB as
specified in Section 2.3. The total size of the SRGB, represented by specified in Section 2.3. The total size of the SRGB, represented by
the variable "Size", is calculated according to the formula: the variable "Size", is calculated according to the formula:
size = Lh(1)- Ll(1) + 1 + Ll(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1 size = Lh(1)- Ll(1) + 1 + Lh(2)- Ll(2) + 1 + ... + Lh(k)- Ll(k) + 1
The following rules MUST be applied by the MCC when calculating the The following rules MUST be applied by the MCC when calculating the
MPLS label value corresponding the SID index value "I". MPLS label value corresponding the SID index value "I".
o 0 =< I < size. If the index "I" does not satisfy the previous o 0 =< I < size. If the index "I" does not satisfy the previous
inequality, then the label cannot be calculated. inequality, then the label cannot be calculated.
o The label value corresponding to the SID index "I" is calculated o The label value corresponding to the SID index "I" is calculated
as follows as follows
o j = 1 , temp = 0 o j = 1 , temp = 0
o While temp < I o While temp + Lh(j)- Ll(j) < I
. temp = temp + Lh(j)- Ll(j) + 1 . temp = temp + Lh(j)- Ll(j) + 1
. j = j+1 . j = j+1
o label = I - temp + Ll(j) o label = I - temp + Ll(j)
2.5. PUSH, CONTINUE, and NEXT 2.5. Incoming Label Collision
MPLS Architecture [RFC3031] defines Forwarding Equivalence Class
(FEC) as the set of packets which are forwarded in the same manner
(e.g.,over the same path, with the same forwarding treatment) and are
bound to the same MPLS incoming (local) label. In Segment-Routing
MPLS, local label serves as the SID (possibly via an index
indirection) for given FEC.
We define Segment Routing (SR) FEC as one of the following [I-D.ietf-
spring-segment-routing]:
o (Prefix, Routing Instance, Topology, Algorithm), where a topology
is identified by a set of links with metrics. For the purpose of
incoming label collision resolution, the same numerical value
SHOULD be used on all routers to identify the same set of links
with metrics. For MCCs where the "Topology" and/or "Algorithm"
fields are not defined, the numerical value of zero MUST be used
for these two fields. For the purpose of incoming label collision
resolution, a routing instance is identified by a single incoming
label downloader to FIB. Two MCCs running on the same router are
considered different routing instances if the only way the two
instances can know about the other's incoming labels is through
redistribution. The numerical value used to identify a routing
instance MAY be derived from other configuration or MAY be
explicitly configured. If it is derived from other configuration,
then the same numerical value SHOULD be derived from the same
configuration as long as the configuration survives router reload.
If the derived numerical value varies for the same configuration,
then an implementation SHOULD make numerical value used to
identify a routing instance configurable.
o (next-hop, outgoing interface), where the outgoing interface is
physical or virtual.
o (Endpoint, Color) representing an SR policy [I.D. filsfils-spring-
segment-routing-policy]
This section covers handling the scenario where, because of an
error/misconfiguration, more than one SR FEC as defined in this
section, map to the same incoming MPLS label.
An incoming label collision occurs if the SIDs of the set of FECs
{FEC1, FEC2,..., FECk} maps to the same incoming SR MPLS label "L1".
The objective of the following steps is to deterministically install
in the MPLS Incoming Label MAP, also known as label FIB, a single FEC
with the incoming label "L1". Remaining FECs may be installed in the
IP FIB without incoming label.
The procedure in this section relies completely on the local FEC and
label database within a given router.
The collision resolution procedure is as follows
1. Given the SIDs of the set of FECs, {FEC1, FEC2,..., FECk} map to
the same MPLS label "L1".
2. Within an MCC, apply tie-breaking rules to select one FEC only and
assign the label to it. The losing FECs are handled as if no
labels are attached to them. The losing FECs with a non-zero algo
are not installed in FIB.
a. If the same set of FECs are attached to the same label "L1",
then the tie-breaking rules MUST always select the same FEC
irrespective of the order in which the FECs and the label "L1"
are received. In other words, the tie-breaking rule MUST be
deterministic. For example, a first-come-first-serve tie-
breaking is not allowed.
3. If there is still collision between the FECs belonging to
different MCCs, then re-apply the tie-breaking rules to the
remaining FECs to select one FEC only and assign the label to that
FEC
4. Install into the IP FIB the selected FEC and its incoming label in
the label FIB.
5. The remaining FECs with a zero algorithm 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.
2.5.1. Tie-breaking Rules
The default tie-breaking rules SHOULD be as follows:
1. if FECi has the lowest FEC administrative distance among the
competing FEC's as defined in this section below, filter away all
the competing FEC's with higher administrative distance.
2. if more than one competing FEC remains after step 1, sort them and
select the smallest numerical FEC value
These rules deterministically select the FEC to install in the MPLS
forwarding plane for the given incoming label.
This document defines the default tie breaking rules that SHOULD be
implemented. An implementation may choose to implement additional
tie-breaking rules. All routers in a routing domain SHOULD use the
same tie-breaking rules to maximize forwarding consistency.
Each FEC is assigned an administrative distance. The FEC
administrative distance is encoded as an 8-bit value. The lower the
value, the better the administrative distance.
The default FEC administrative distance order starting from the
lowest value SHOULD be
o Explicit SID assignment to a FEC that maps to a label outside the
SRGB irrespective of the owner MCC. An explicit SID assignment is
a static assignment of a label to a FEC such that the assignment
survives router reboot.
o An example of explicit SID allocation is static assignment of
a specific label to an adjacency SID.
o An implementation of explicit SID assignment MUST guarantee
collision freeness on the same router
o Dynamic SID assignment:
o For all FEC types except for SR policy, use the default
administrative distance depending on the implementation
o Binding SID [I-D.ietf-spring-segment-routing] assigned to SR
Policy
A user SHOULD ensure that the same administrative distance preference
is used on all routers to maximize forwarding consistency.
The numerical sort across FEC's SHOULD be performed as follows:
o Each FEC is assigned a FEC type encoded in 8 bits. The following
are the type code point for each SR FEC defined at the beginning
of this Section:
o 120: (Prefix, Routing Instance, Topology, Algorithm)
o 130: (next-hop, outgoing interface)
o 140: (Endpoint, Color) representing an SR policy
o The fields of each FEC are encoded as follows
o Routing Instance ID represented by 16 bits. For routing
instances that are identified by less than 16 bits, encode the
Instance ID in the least significant bits while the most
significant bits are set to zero
o Address Family represented by 8 bits, where IPv4 encoded as
100 and IPv6 is encoded as 110
o All addresses are represented in 128 bits as follows
. IPv6 address is encoded natively
. IPv4 address is encoded in the most significant bits and
the remaining bits are set to zero
o All prefixes are represented by 128.
. 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
o Topology ID is represented by 16 bits. For routing instances
that identify topologies using less than 16 bits, encode the
topology ID in the least significant bits while the most
significant bits are set to zero
o Algorithm is encoded in a 16 bits field.
o The Color ID is encoded using 16 bits
o Choose the set of FECs of the smallest FEC type code point
o Out of these FECs, choose the FECs with the smallest address
family code point
o Encode the remaining set of FECs as follows
o Prefix, Routing Instance, Topology, Algorithm: (Prefix Length,
Prefix, SR Algorithm, routing_instance_id, Topology)
o (next-hop, outgoing interface): (next-hop,
outgoing_interface_id)
o (Endpoint, Color): (Endpoint_address, Color_id)
o Select the FEC with the smallest numerical value
2.5.2. Redistribution between Routing Protocol Instances
The following rule SHOULD be applied when redistributing SIDs with
prefixes between routing protocol instances:
o If the receiving instance's SRGB is the same as the SRGB of origin
instance, THEN
o the index is redistributed with the route
o Else
o the index is not redistributed and if needed it is the duty of
the receiving instance to allocate a fresh index relative to
its own SRGB
It is outside the scope of this document to define local node
behaviors that would allow to map the original index into a new index
in the receiving instance via the addition of an offset or other
policy means.
2.5.2.1. Illustration
A----IS-IS----B---OSPF----C-1.1.1.1/32 (20001)
Consider the simple topology above.
o A and B are in the IS-IS domain with SRGB [16000-17000]
o B and C are in OSPF domain with SRGB [20000-21000]
o B redistributes 1.1.1.1/32 into IS-IS domain
o In that case A learns 1.1.1.1/32 as an IP leaf connected to B as
usual for IP prefix redistribution
o However, according to the redistribution rule above rule, B does
not advertise any index with 1.1.1.1/32 into IS-IS because the
SRGB is not the same.
2.6. Outgoing Label Collision
For the determination of the outgoing label to use, the ingress node
pushing new segments, and hence a stack of MPLS labels, MUST use, for
a given FEC, the same label that has been selected by the node
receiving the packet with that label exposed as top label. So in case
of incoming label collision on this receiving node, the ingress node
MUST resolve this collision using this same "Incoming Label Collision
resolution procedure", using the data of the receiving node.
In the general case, the ingress node may not have exactly have the
same data of the receiving node, so the result may be different. This
is under the responsibility of the network operator. But in typical
case, e.g. where a centralized node or a distributed link state IGP
is used, all nodes would have the same database. 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.
2.7. PUSH, CONTINUE, and NEXT
PUSH, NEXT, and CONTINUE are operations applied by the forwarding PUSH, NEXT, and CONTINUE are operations applied by the forwarding
plan. The specifications of these operations can be found in [I- plan. The specifications of these operations can be found in [I-
D.ietf-spring-segment-routing]. This sub-section specifies how to D.ietf-spring-segment-routing]. This sub-section specifies how to
implement each of these operations in the MPLS forwarding plane. implement each of these operations in the MPLS forwarding plane.
2.5.1. PUSH 2.7.1. PUSH
PUSH corresponds to pushing one or more labels on top of an incoming PUSH corresponds to pushing one or more labels on top of an incoming
packet then sending it out of a particular physical interface or packet then sending it out of a particular physical interface or
virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel virtual interface, such as UDP tunnel [RFC7510] or L2TPv3 tunnel
[RFC4817], towards a particular next-hop. Sections 2.10 and 2.11
[RFC4817], towards a particular next-hop. Sections 2.8 and 2.9.
specify additional details about forwarding behavior. specify additional details about forwarding behavior.
2.5.2. CONTINUE 2.7.2. CONTINUE
In the MPLS forwarding plane, the CONTINUE operation corresponds to In the MPLS forwarding plane, the CONTINUE operation corresponds to
swapping the incoming label with an outgoing label. The value of the swapping the incoming label with an outgoing label. The value of the
outgoing label is calculated as specified in Sections 2.8 and 2.9. outgoing label is calculated as specified in Sections 2.10 and 2.11.
2.5.3. NEXT 2.7.3. NEXT
In the MPLS forwarding plane, NEXT corresponds to popping the topmost In the MPLS forwarding plane, NEXT corresponds to popping the topmost
label. The action before and/or after the popping depends on the label. The action before and/or after the popping depends on the
instruction associated with the active SID on the received packet instruction associated with the active SID on the received packet
prior to the popping. For example suppose the active SID in the prior to the popping. For example suppose the active SID in the
received packet was an Adj-SID [I-D.ietf-spring-segment-routing], received packet was an Adj-SID [I-D.ietf-spring-segment-routing],
then on receiving the packet, the node applies NEXT operation, which then on receiving the packet, the node applies NEXT operation, which
corresponds to popping the top most label, and then sends the packet corresponds to popping the top most label, and then sends the packet
out of the physical or virtual interface (e.g. UDP tunnel [RFC7510] out of the physical or virtual interface (e.g. UDP tunnel [RFC7510]
or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the or L2TPv3 tunnel [RFC4817]) towards the next-hop corresponding to the
adj-SID. adj-SID.
2.6. MPLS Label downloaded to FIB corresponding to Global and Local SIDs 2.8. MPLS Label downloaded to FIB corresponding to Global and Local SIDs
The label corresponding to the global SID "Si" represented by the The label corresponding to the global SID "Si" represented by the
global index "I" downloaded to FIB is used to match packets whose global index "I" downloaded to FIB is used to match packets whose
active segment (and hence topmost label) is "Si". The value of this active segment (and hence topmost label) is "Si". The value of this
label is calculated as specified in Section 2.4. label is calculated as specified in Section 2.4.
For Local SIDs, the MCC is responsible for downloading the correct For Local SIDs, the MCC is responsible for downloading the correct
label value to FIB. For example, an IGP with SR extensions I-D.ietf- label value to FIB. For example, an IGP with SR extensions I-D.ietf-
isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing- isis-segment-routing-extensions, I-D.ietf-ospf-segment-routing-
extensions] allocates and downloads the MPLS label corresponding to extensions] allocates and downloads the MPLS label corresponding to
an IGP-adjacency-SID [I-D.ietf-spring-segment-routing]. an IGP-adjacency-SID [I-D.ietf-spring-segment-routing].
2.7. Active Segment 2.9. Active Segment
When instantiated in the MPLS domain, the active segment on a packet When instantiated in the MPLS domain, the active segment on a packet
corresponds to the topmost label on the packet that is calculated corresponds to the topmost label on the packet that is calculated
according to the procedure specified in Sections 2.8 and 2.9. When according to the procedure specified in Sections 2.10 and 2.11. When
arriving at a node, the topmost label corresponding to the active SID arriving at a node, the topmost label corresponding to the active SID
matches the MPLS label downloaded to FIB as specified in Section 2.6. matches the MPLS label downloaded to FIB as specified in Section 2.8.
2.8. Forwarding behavior for Global SIDs 2.10. Forwarding behavior for Global SIDs
This section specifies forwarding behavior, including the outgoing This section specifies forwarding behavior, including the outgoing
label(s) calculations corresponding to a global SID when applying label(s) calculations corresponding to a global SID when applying
PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane. PUSH, CONTINUE, and NEXT operations in the MPLS forwarding plane.
This document covers the calculation of outgoing label for the top This document covers the calculation of outgoing label for the top
label only. The case where outgoing label is not the top label and is label only. The case where outgoing label is not the top label and is
part of a stack of labels that instantiates a routing policy or a part of a stack of labels that instantiates a routing policy or a
traffic engineering tunnel is covered in other documents such as traffic engineering tunnel is covered in other documents such as
[I.D.filsfils-spring-segment-routing-policy]. [I.D.filsfils-spring-segment-routing-policy].
2.8.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global 2.10.1. Forwarding Behavior for PUSH and CONTINUE Operation for Global
SIDs SIDs
Suppose an MCC on a router "R0" determines that PUSH or CONTINUE Suppose an MCC on a router "R0" determines that PUSH or CONTINUE
operation is to be applied to an incoming packet whose active SID is operation is to be applied to an incoming packet whose active SID is
the global SID "Si" represented by the global index "I" and owned by the global SID "Si" represented by the global index "I" and owned by
the router Ri before sending the packet towards a neighbor "N" the router Ri before sending the packet towards a neighbor "N"
directly connected to "R0" through a physical or virtual interface directly connected to "R0" through a physical or virtual interface
such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817]. such as UDP tunnel [RFC7510] or L2TPv3 tunnel [RFC4817].
The method by which the MCC on router "R0" determines that PUSH or 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 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 scope of this document. An example of a method to determine the SID
"Si" for PUSH operation is the case where ISIS [I-D.ietf-isis- "Si" for PUSH operation is the case where IS-IS [I-D.ietf-isis-
segment-routing-extensions] receives the prefix-SID "Si" sub-TLV segment-routing-extensions] receives the prefix-SID "Si" sub-TLV
advertised with prefix "P/m" in TLV 135 and the destination address advertised with prefix "P/m" in TLV 135 and the destination address
of the incoming IPv4 packet is covered by the prefix "P/m". of the incoming IPv4 packet is covered by the prefix "P/m".
For CONTINUE operation, an example of a method to determine the SID For CONTINUE operation, an example of a method to determine the SID
"Si" is the case where ISIS [I-D.ietf-isis-segment-routing- "Si" is the case where IS-IS [I-D.ietf-isis-segment-routing-
extensions] receives the prefix-SID "Si" sub-TLV advertised with extensions] receives the prefix-SID "Si" sub-TLV advertised with
prefix "P" in TLV 135 and the top label of the incoming packet prefix "P" in TLV 135 and the top label of the incoming packet
matches the MPLS label in FIB corresponding to the SID "Si" on the matches the MPLS label in FIB corresponding to the SID "Si" on the
router "R0". router "R0".
The forwarding behavior for PUSH and CONTINUE corresponding to the The forwarding behavior for PUSH and CONTINUE corresponding to the
SID "Si" SID "Si"
o If the neighbor "N" does not support SR or "I" does not satisfy o If the neighbor "N" does not support SR or "I" does not satisfy
the inequality specified in Section 2.4 for the SRGB of the the inequality specified in Section 2.4 for the SRGB of the
skipping to change at page 9, line 28 skipping to change at page 15, line 4
any label to another next-hop. any label to another next-hop.
o Otherwise drop the packet. o Otherwise drop the packet.
o Else o Else
o Calculate the outgoing label as specified in Section 2.4 using o Calculate the outgoing label as specified in Section 2.4 using
the SRGB of the neighbor "N" the SRGB of the neighbor "N"
o If the operation is PUSH o If the operation is PUSH
. Push the calculated label according the MPLS label . Push the calculated label according the MPLS label
pushing rules specified in [RFC3032] pushing rules specified in [RFC3032]
o Else o Else
. swap the incoming label with the calculated label . swap the incoming label with the calculated label
according to the label swapping rules in [RFC3032] according to the label swapping rules in [RFC3032]
o Send the packet towards the neighbor "N" o Send the packet towards the neighbor "N"
2.8.2. Forwarding Behavior for NEXT Operation for Global SIDs 2.10.2. Forwarding Behavior for NEXT Operation for Global SIDs
As specified in Section 2.5.3 NEXT operation corresponds to popping As specified in Section 2.7.3 NEXT operation corresponds to popping
the top most label. The forwarding behavior is as follows the top most label. The forwarding behavior is as follows
o Pop the topmost label o Pop the topmost label
o Apply the instruction associated with the incoming label prior to o Apply the instruction associated with the incoming label prior to
popping popping
The action on the packet after popping the topmost label depends on The action on the packet after popping the topmost label depends on
the instruction associated with the incoming label as well as the the instruction associated with the incoming label as well as the
contents of the packet right underneath the top label that got contents of the packet right underneath the top label that got
popped. Examples of NEXT operation are described in Section 3. popped. Examples of NEXT operation are described in Section 3.
2.9. Forwarding Behavior for Local SIDs 2.11. Forwarding Behavior for Local SIDs
This section specifies the forwarding behavior for local SIDs when SR This section specifies the forwarding behavior for local SIDs when SR
is instantiated over the MPLS forwarding plane. is instantiated over the MPLS forwarding plane.
2.9.1. Forwarding Behavior Corresponding to PUSH Operation on Local SIDs 2.11.1. Forwarding Behavior Corresponding to PUSH Operation on Local
SIDs
Suppose an MCC on a router "R0" determines that PUSH operation is to Suppose an MCC on a router "R0" determines that PUSH operation is to
be applied to an incoming packet using the local SID "Si" before be applied to an incoming packet using the local SID "Si" before
sending the packet towards a neighbor "N" directly connected to R0 sending the packet towards a neighbor "N" directly connected to R0
through a physical or virtual interface such as UDP tunnel [RFC7510] through a physical or virtual interface such as UDP tunnel [RFC7510]
or L2TPv3 tunnel [RFC4817]. or L2TPv3 tunnel [RFC4817].
An example of such local SID is an IGP-Adj-SID allocated and An example of such local SID is an IGP-Adj-SID allocated and
advertised by ISIS [I-D.ietf-isis-segment-routing-extensions]. The advertised by IS-IS [I-D.ietf-isis-segment-routing-extensions]. The
method by which the MCC on "R0" determines that PUSH operation is to method by which the MCC on "R0" determines that PUSH operation is to
be applied to the incoming packet is beyond the scope of this be applied to the incoming packet is beyond the scope of this
document. An example of such method is backup path used to protect document. An example of such method is backup path used to protect
against a failure using Ti-LFA [I.D.bashandy-rtgwg-segment-routing- against a failure using Ti-LFA [I.D.bashandy-rtgwg-segment-routing-
ti-lfa]. ti-lfa].
As mentioned in [I-D.ietf-spring-segment-routing], a local SID is As mentioned in [I-D.ietf-spring-segment-routing], a local SID is
specified by an MPLS label. Hence the PUSH operation for a local SID specified by an MPLS label. Hence the PUSH operation for a local SID
is identical to label push operation [RFC3032] using any MPLS label. is identical to label push operation [RFC3032] using any MPLS label.
The forwarding action after pushing the MPLS label corresponding to The forwarding action after pushing the MPLS label corresponding to
the local SID is also determined by the MCC. For example, if the PUSH the local SID is also determined by the MCC. For example, if the PUSH
operation was done to forward a packet over a backup path calculated operation was done to forward a packet over a backup path calculated
using Ti-LFA, then the forwarding action may be sending the packet to using Ti-LFA, then the forwarding action may be sending the packet to
a certain neighbor that will in turn continue to forward the packet a certain neighbor that will in turn continue to forward the packet
along the backup path along the backup path
2.9.2. Forwarding Behavior Corresponding to CONTINUE Operation for Local 2.11.2. Forwarding Behavior Corresponding to CONTINUE Operation for
SIDs Local SIDs
A local SID on a router "R0" corresponds to a local label such as an A local SID on a router "R0" corresponds to a local label such as an
IGP adj-SID. In such scenario, the outgoing label towards a next-hop IGP adj-SID. In such scenario, the outgoing label towards a next-hop
"N" is determined by the MCC running on the router "R0"and the "N" is determined by the MCC running on the router "R0"and the
forwarding behavior for CONTINUE operation is identical to swap forwarding behavior for CONTINUE operation is identical to swap
operation [RFC3032] on an MPLS label. operation [RFC3032] on an MPLS label.
2.9.3. Outgoing label for NEXT Operation for Local SIDs 2.11.3. Outgoing label for NEXT Operation for Local SIDs
NEXT operation for Local SIDs is identical to NEXT operation for NEXT operation for Local SIDs is identical to NEXT operation for
global SIDs specified in Section 2.8.2. global SIDs specified in Section 2.10.2.
3. IGP Segments Examples 3. IGP Segments Examples
Consider the network diagram of Figure 1 and the IP address and IGP Consider the network diagram of Figure 1 and the IP address and IGP
Segment allocation of Figure 2. Assume that the network is running Segment allocation of Figure 2. Assume that the network is running
ISIS with SR extensions [I-D.ietf-isis-segment-routing-extensions]. IS-IS with SR extensions [I-D.ietf-isis-segment-routing-extensions].
The following examples can be constructed. The following examples can be constructed.
+--------+ +--------+
/ \ / \
R0-----R1-----R2----------R3-----R8 R0-----R1-----R2----------R3-----R8
| \ / | | \ / |
| +--R4--+ | | +--R4--+ |
| | | |
+-----R5-----+ +-----R5-----+
skipping to change at page 12, line 47 skipping to change at page 17, line 47
Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1 Suppose R1 wants to send an IPv4 packet P1 to R8. In this case, R1
needs to apply PUSH operation to the IPv4 packet. needs to apply PUSH operation to the IPv4 packet.
Remember that the SID index "8" is a global IGP segment attached to Remember that the SID index "8" is a global IGP segment attached to
the IP prefix 192.0.2.8/32. Its semantic is global within the IGP the IP prefix 192.0.2.8/32. Its semantic is global within the IGP
domain: any router forwards a packet received with active segment 8 domain: any router forwards a packet received with active segment 8
to the next-hop along the ECMP-aware shortest-path to the related to the next-hop along the ECMP-aware shortest-path to the related
prefix. prefix.
R2 is the next-hop along the shortest path towards R8. By applying R2 is the next-hop along the shortest path towards R8. By applying
the steps in Section 2.6 the local label downloaded to R1's FIB the steps in Section 2.8 the local label downloaded to R1's FIB
corresponding to the global SID index 8 is 1008 because the SRGB of corresponding to the global SID index 8 is 1008 because the SRGB of
R2 is [1000,5000] as shown in Figure 2. R2 is [1000,5000] as shown in Figure 2.
Because the packet is IPv4, R1 applies the PUSH operation using the Because the packet is IPv4, R1 applies the PUSH operation using the
label value 1008 as specified in 2.8.1. The resulting MPLS header label value 1008 as specified in 2.10.1. The resulting MPLS header
will have the "S" bit [RFC3032] set because it is followed directly will have the "S" bit [RFC3032] set because it is followed directly
by an IPv4 packet. by an IPv4 packet.
The packet arrives at router R2. Because the top label 1008 The packet arrives at router R2. Because the top label 1008
corresponds to the IGP SID "8", which is the prefix-SID attached to corresponds to the IGP SID "8", which is the prefix-SID attached to
the prefix 192.0.2.8/32 owned by the R8, then the instruction the prefix 192.0.2.8/32 owned by the R8, then the instruction
associated with the SID is "forward the packet using all ECMP/UCMP associated with the SID is "forward the packet using all ECMP/UCMP
interfaces and all ECMP/UCMP next-hop(s) along the shortest path interfaces and all ECMP/UCMP next-hop(s) along the shortest path
towards R8". Because R2 is not the penultimate hop, R2 applies the 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 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 two links connected to R3 with top label 1008 as specified in Section
2.8.1. 2.10.1.
R3 receives the packet with top label 1008. Because the top label R3 receives the packet with top label 1008. Because the top label
1008 corresponds to the IGP SID "8", which is the prefix-SID attached 1008 corresponds to the IGP SID "8", which is the prefix-SID attached
to the prefix 192.0.2.8/32 owned by the R8, then the instruction to the prefix 192.0.2.8/32 owned by the R8, then the instruction
associated with the SID is "send the packet using all ECMP interfaces associated with the SID is "send the packet using all ECMP interfaces
and all next-hop(s) along the shortest path towards R8". Because R3 and all next-hop(s) along the shortest path towards R8". Because R3
is the penultimate hop, R3 applies NEXT operation then sends the is the penultimate hop, R3 applies NEXT operation then sends the
packet to R8. The NEXT operation results in popping the outer label packet to R8. The NEXT operation results in popping the outer label
and sending the packet as a pure IPv4 packet to R8. The and sending the packet as a pure IPv4 packet to R8. The
In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP- In conclusion, the path followed by P1 is R1-R2--R3-R8. The ECMP-
awareness ensures that the traffic be load-shared between any ECMP awareness ensures that the traffic be load-shared between any ECMP
path, in this case the two north and south links between R2 and R3. path, in this case the two north and south links between R2 and R3.
3.2. Example 2 3.2. Example 2
Suppose the right most router R0 wants to send a packet P2 to R8 over Suppose the right most router R0 wants to send a packet P2 to R8 over
the path <R2, (north link between R2 and R3)>. In that case, the the path <R2, (north link between R2 and R3)>. In that case, the
router R0 needs to use the SID list <2, 9001, 8>. Using the router R0 needs to use the SID list <2, 9001, 8>. Using the
calculation techniques specified in Section 2.8 and 2.9 the calculation techniques specified in Section 2.10 and 2.11 the
resulting label stack starting from the topmost label is <1002, 9001, resulting label stack starting from the topmost label is <1002, 9001,
1008>. 1008>.
The MPLS label 1002 is the MPLS instantiation of the global IGP The MPLS label 1002 is the MPLS instantiation of the global IGP
segment index 2 attached to the IP prefix 192.0.2.2/32. Its semantic segment index 2 attached to the IP prefix 192.0.2.2/32. Its semantic
is global within the IGP domain: any router forwards a packet is global within the IGP domain: any router forwards a packet
received with active segment 1002 to the next-hop along the shortest- received with active segment 1002 to the next-hop along the shortest-
path to the related prefix. path to the related prefix.
The MPLS label 9001 is a local IGP segment attached by node R2 to its The MPLS label 9001 is a local IGP segment attached by node R2 to its
skipping to change at page 14, line 41 skipping to change at page 19, line 41
packet received with active segment 1004 to the next-hop along the packet received with active segment 1004 to the next-hop along the
shortest-path to the related prefix. shortest-path to the related prefix.
In conclusion, the path followed by P4 is R0-R1-R2-R4-R3-R8. In conclusion, the path followed by P4 is R0-R1-R2-R4-R3-R8.
3.5. Example 5 3.5. Example 5
R0 may send a packet P5 to R8 while avoiding the links between R2 and R0 may send a packet P5 to R8 while avoiding the links between R2 and
R3 and still benefiting from all the remaining shortest paths (via R4 R3 and still benefiting from all the remaining shortest paths (via R4
and R5) by pushing the SID list <1009, 8> which corresponds to the and R5) by pushing the SID list <1009, 8> which corresponds to the
label stack <2009, 1008> using the steps specified in Sections 2.8 label stack <2009, 1008> using the steps specified in Sections 2.10
and 2.9. and 2.11.
1009 is a global anycast-SID [I-D.ietf-spring-segment-routing] 1009 is a global anycast-SID [I-D.ietf-spring-segment-routing]
attached to the anycast IP prefix 198.51.100.9/32. Its semantic is attached to the anycast IP prefix 198.51.100.9/32. Its semantic is
global within the IGP domain: any router forwards a packet received global within the IGP domain: any router forwards a packet received
with top label 2009 (corresponding to the active segment 1009) to the with top label 2009 (corresponding to the active segment 1009) to the
next-hop along the shortest-path to the related prefix. next-hop along the shortest-path to the related prefix.
In conclusion, the path followed by P5 is either R0-R1-R2-R4-R3-R8 or In conclusion, the path followed by P5 is either R0-R1-R2-R4-R3-R8 or
R0-R1-R2-R5-R3-R8. R0-R1-R2-R5-R3-R8.
skipping to change at page 17, line 19 skipping to change at page 22, line 19
[reserved-MPLS] "Special-Purpose Multiprotocol Label Switching (MPLS) [reserved-MPLS] "Special-Purpose Multiprotocol Label Switching (MPLS)
Label Values", <https://www.iana.org/assignments/mpls- Label Values", <https://www.iana.org/assignments/mpls-
label-value> label-value>
9.2. Informative References 9.2. Informative References
[I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C., [I-D.ietf-isis-segment-routing-extensions] Previdi, S., Filsfils, C.,
Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and Bashandy, A., Gredler, H., Litkowski, S., Decraene, B., and
j. jefftant@gmail.com, "IS-IS Extensions for Segment j. jefftant@gmail.com, "IS-IS Extensions for Segment
Routing", draft-ietf-isis- segment-routing-extensions-13 Routing", draft-ietf-isis-segment-routing-extensions-13
(work in progress), June 2017. (work in progress), June 2017.
[I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P., [I-D.ietf-ospf-ospfv3-segment-routing-extensions] Psenak, P.,
Previdi, S., Filsfils, C., Gredler, H., Shakir, R., Previdi, S., Filsfils, C., Gredler, H., Shakir, R.,
Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for Henderickx, W., and J. Tantsura, "OSPFv3 Extensions for
Segment Routing", draft-ietf-ospf-ospfv3- segment-routing- Segment Routing", draft-ietf-ospf-ospfv3- segment-routing-
extensions-09 (work in progress), March 2017. extensions-09 (work in progress), March 2017.
[I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S., [I-D.ietf-ospf-segment-routing-extensions] Psenak, P., Previdi, S.,
Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and Filsfils, C., Gredler, H., Shakir, R., Henderickx, W., and
skipping to change at page 19, line 6 skipping to change at page 24, line 6
te-policy-00 (work in progress), July 2017 te-policy-00 (work in progress), July 2017
[I.D. filsfils-spring-segment-routing-policy] Filsfils, C., [I.D. filsfils-spring-segment-routing-policy] Filsfils, C.,
Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D., Sivabalan, S., Raza, K., Liste, J. , Clad, F., Voyer, D.,
Lin, S., Bogdanov, A., Horneffer, M., Steinberg, D., Lin, S., Bogdanov, A., Horneffer, M., Steinberg, D.,
Decraene, B. , Litkowski, S., " Segment Routing Policy for Decraene, B. , Litkowski, S., " Segment Routing Policy for
Traffic Engineering", draft-filsfils-spring-segment- Traffic Engineering", draft-filsfils-spring-segment-
routing-policy-01 (work in progress), July 2017 routing-policy-01 (work in progress), July 2017
Authors' Addresses Authors' Addresses
Ahmed Bashandy
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: bashandy@cisco.com
Clarence Filsfils (editor) Clarence Filsfils (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Brussels Brussels
BE BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
Stefano Previdi (editor) Stefano Previdi (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Italy Italy
Email: stefano@previdi.net Email: stefano@previdi.net
Ahmed Bashandy
Cisco Systems, Inc.
170, West Tasman Drive
San Jose, CA 95134
US
Email: bashandy@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
FR FR
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.com
Rob Shakir Rob Shakir
Google Google
US
Email: robjs@google.com Email: robjs@google.com
 End of changes. 45 change blocks. 
91 lines changed or deleted 356 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/