< draft-ietf-mpls-spring-entropy-label-06.txt | draft-ietf-mpls-spring-entropy-label-07.txt > | |||
---|---|---|---|---|
Network Working Group S. Kini | Network Working Group S. Kini | |||
Internet-Draft | Internet-Draft | |||
Intended status: Informational K. Kompella | Intended status: Informational K. Kompella | |||
Expires: November 4, 2017 Juniper | Expires: April 9, 2018 Juniper | |||
S. Sivabalan | S. Sivabalan | |||
Cisco | Cisco | |||
S. Litkowski | S. Litkowski | |||
Orange | Orange | |||
R. Shakir | R. Shakir | |||
J. Tantsura | J. Tantsura | |||
May 3, 2017 | October 6, 2017 | |||
Entropy label for SPRING tunnels | Entropy label for SPRING tunnels | |||
draft-ietf-mpls-spring-entropy-label-06 | draft-ietf-mpls-spring-entropy-label-07 | |||
Abstract | Abstract | |||
Source routed tunnels with label stacking is a technique that can be | Segment Routing (SR) leverages the source routing paradigm. A node | |||
leveraged to steer a packet through a controlled set of segments. | steers a packet through an ordered list of instructions, called | |||
This can be applied to the Multi Protocol Label Switching (MPLS) data | segments. Segment Routing can be applied to the Multi Protocol Label | |||
plane. Entropy label (EL) is a technique used in MPLS to improve | Switching (MPLS) data plane. Entropy label (EL) is a technique used | |||
load-balancing. This document examines and describes how ELs are to | in MPLS to improve load-balancing. This document examines and | |||
be applied to source routed tunnels with label stacks. | describes how ELs are to be applied to Segment Routing when applied | |||
to the MPLS dataplane. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 https://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 November 4, 2017. | This Internet-Draft will expire on April 9, 2018. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2017 IETF Trust and the persons identified as the | Copyright (c) 2017 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 | (https://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 | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 | 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 4 | |||
3. Use-case requiring multipath load-balancing . . . . . . . . . 4 | 3. Use-case requiring multipath load-balancing . . . . . . . . . 4 | |||
4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 5 | 4. Entropy Readable Label Depth . . . . . . . . . . . . . . . . 5 | |||
5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7 | 5. Maximum SID Depth . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. LSP stitching using the binding SID . . . . . . . . . . . . . 8 | 6. LSP stitching using the binding SID . . . . . . . . . . . . . 8 | |||
7. Insertion of entropy labels for SPRING path . . . . . . . . . 10 | 7. Insertion of entropy labels for SPRING path . . . . . . . . . 10 | |||
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 | 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
7.1.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 11 | 7.1.1. Example 1 where the ingress node has a sufficient MSD 11 | |||
7.1.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 12 | 7.1.2. Example 2 where the ingress node has not a sufficient | |||
MSD . . . . . . . . . . . . . . . . . . . . . . . . . 12 | ||||
7.2. Considerations for the placement of entropy labels . . . 12 | 7.2. Considerations for the placement of entropy labels . . . 12 | |||
7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 13 | 7.2.1. ERLD value . . . . . . . . . . . . . . . . . . . . . 13 | |||
7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14 | 7.2.2. Segment type . . . . . . . . . . . . . . . . . . . . 14 | |||
7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 14 | 7.2.2.1. Node-SID . . . . . . . . . . . . . . . . . . . . 14 | |||
7.2.2.2. Adjacency-SID representing an ECMP bundle . . . . 14 | 7.2.2.2. Adjacency-set SID . . . . . . . . . . . . . . . . 15 | |||
7.2.2.3. Adjacency-SID representing a single IP link . . . 15 | 7.2.2.3. Adjacency-SID representing a single IP link . . . 15 | |||
7.2.2.4. Adjacency-SID representing a single link within | 7.2.2.4. Adjacency-SID representing a single link within a | |||
an L2 bundle . . . . . . . . . . . . . . . . . . 15 | L2 bundle . . . . . . . . . . . . . . . . . . . . 15 | |||
7.2.2.5. Adjacency-SID representing an L2 bundle . . . . . 15 | 7.2.2.5. Adjacency-SID representing a L2 bundle . . . . . 15 | |||
7.2.3. Maximizing number of LSRs that will load-balance . . 15 | 7.2.3. Maximizing number of LSRs that will load-balance . . 15 | |||
7.2.4. Preference for a part of the path . . . . . . . . . . 16 | 7.2.4. Preference for a part of the path . . . . . . . . . . 16 | |||
7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 16 | 7.2.5. Combining criteria . . . . . . . . . . . . . . . . . 16 | |||
8. A simple algorithm example . . . . . . . . . . . . . . . . . 16 | 8. A simple example algorithm . . . . . . . . . . . . . . . . . 16 | |||
9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 | 9. Deployment Considerations . . . . . . . . . . . . . . . . . . 17 | |||
10. Options considered . . . . . . . . . . . . . . . . . . . . . 18 | 10. Options considered . . . . . . . . . . . . . . . . . . . . . 18 | |||
10.1. Single EL at the bottom of the stack of tunnels . . . . 18 | 10.1. Single EL at the bottom of the stack . . . . . . . . . . 18 | |||
10.2. An EL per tunnel in the stack . . . . . . . . . . . . . 18 | 10.2. An EL per segment in the stack . . . . . . . . . . . . . 18 | |||
10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19 | 10.3. A re-usable EL for a stack of tunnels . . . . . . . . . 19 | |||
10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 20 | 10.4. EL at top of stack . . . . . . . . . . . . . . . . . . . 19 | |||
10.5. ELs at readable label stack depths . . . . . . . . . . . 20 | 10.5. ELs at readable label stack depths . . . . . . . . . . . 20 | |||
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 | |||
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 | 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 | |||
14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 | |||
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
15.1. Normative References . . . . . . . . . . . . . . . . . . 21 | 15.1. Normative References . . . . . . . . . . . . . . . . . . 21 | |||
15.2. Informative References . . . . . . . . . . . . . . . . . 22 | 15.2. Informative References . . . . . . . . . . . . . . . . . 22 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
1. Introduction | 1. Introduction | |||
The source routed tunnels with label stacking paradigm is leveraged | Segment Routing [I-D.ietf-spring-segment-routing] is based on source | |||
by techniques such as Segment Routing (SR) | routed tunnels to steer a packet along a particular path. This path | |||
[I-D.ietf-spring-segment-routing] to steer a packet through a set of | is encoded as an ordered list of segments. When applied to the MPLS | |||
segments. This can be directly applied to the MPLS data plane, but | dataplane [I-D.ietf-spring-segment-routing-mpls], each segment is an | |||
it has implications on the label stack depth. | LSP with an associated MPLS label value. Hence, label stacking is | |||
used to represent the ordered list of segments and the label stack | ||||
associated with an SR tunnel can be seen as nested LSPs (LSP | ||||
hierarchy) in the MPLS architecture. | ||||
Clarifying statements on label stack depth have been provided in | Using label stacking to encode the list of segment has implications | |||
[RFC7325] but the RFC does not address the case of source routed | on the label stack depth. | |||
stacked MPLS tunnels as described in | ||||
[I-D.ietf-spring-segment-routing] where deeper label stacks are more | ||||
prevalent. | ||||
Entropy label (EL) [RFC6790] is a technique used in the MPLS data | Entropy label (EL) [RFC6790] is a technique used in the MPLS data | |||
plane to provide entropy for load-balancing. When using LSP | plane to provide entropy for load-balancing. When using LSP | |||
hierarchies, there are implications on how [RFC6790] should be | hierarchies, there are implications on how [RFC6790] should be | |||
applied. The current document addresses the case where the hierarchy | applied. The current document addresses the case where a hierarchy | |||
is created at a single LSR as required by source routed tunnels with | is created at a single LSR as required by Segment Routing. | |||
label stacks. | ||||
A use-case requiring load-balancing with source routed tunnels with | A use-case requiring load-balancing with SR is given in Section 3. A | |||
label stacks is given in Section 3. A recommended solution is | recommended solution is described in Section 7 keeping in | |||
described in Section 7 keeping in consideration the limitations of | consideration the limitations of implementations when applying | |||
implementations when applying [RFC6790] to deeper label stacks. | [RFC6790] to deeper label stacks. Options that were considered to | |||
Options that were considered to arrive at the recommended solution | arrive at the recommended solution are documented for historical | |||
are documented for historical purposes in Section 10. | purposes in Section 10. | |||
1.1. Requirements Language | 1.1. Requirements Language | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
Although this document is not a protocol specification, the use of | Although this document is not a protocol specification, the use of | |||
this language clarifies the instructions to protocol designers | this language clarifies the instructions to protocol designers | |||
producing solutions that satisfy the requirements set out in this | producing solutions that satisfy the requirements set out in this | |||
skipping to change at page 4, line 43 ¶ | skipping to change at page 4, line 50 ¶ | |||
| S |-----| P1 |------------| P2 |--+ +--| D | | | S |-----| P1 |------------| P2 |--+ +--| D | | |||
| | | | | |--+ +--| | | | | | | | |--+ +--| | | |||
+-----+ +-----+ +-----+ | +----+ | +-----+ | +-----+ +-----+ +-----+ | +----+ | +-----+ | |||
+--| P5 |--+ | +--| P5 |--+ | |||
+----+ | +----+ | |||
S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, | S=Source LSR, D=Destination LSR, P1,P2,P3,P4,P5=Transit LSRs, | |||
L1,L2,L3,L4=Links | L1,L2,L3,L4=Links | |||
Figure 1: Traffic engineering use-case | Figure 1: Traffic engineering use-case | |||
Traffic-engineering (TE) is one of the applications of MPLS and is | Traffic-engineering is one of the applications of MPLS and is also a | |||
also a requirement for source routed tunnels with label stacks | requirement for source routed tunnels with label stacks [RFC7855]. | |||
[RFC7855]. Consider the topology shown in Figure 1. The LSR S | ||||
requires data to be sent to LSR D along a traffic-engineered path | Consider the topology shown in Figure 1. The LSR S requires data to | |||
that goes over the link L1. Good load-balancing is also required | be sent to LSR D along a traffic-engineered path that goes over the | |||
across equal cost paths (including parallel links). To engineer | link L1. Good load-balancing is also required across equal cost | |||
traffic along a path that takes link L1, the label stack that LSR S | paths (including parallel links). To engineer traffic along a path | |||
creates consists of a label to the node SID of LSR P3, stacked over | that takes link L1, the label stack that LSR S creates consists of a | |||
the label for the adjacency SID of link L1 and that in turn is | label to the node SID of LSR P3, stacked over the label for the | |||
stacked over the label to the node SID of LSR D. For simplicity lets | adjacency SID of link L1 and that in turn is stacked over the label | |||
assume that all LSRs use the same label space (SRGB) for source | to the node SID of LSR D. For simplicity lets assume that all LSRs | |||
routed label stacks. Let L_N-Px denote the label to be used to reach | use the same label space (SRGB) for source routed label stacks. Let | |||
the node SID of LSR Px. Let L_A-Ln denote the label used for the | L_N-Px denote the label to be used to reach the node SID of LSR Px. | |||
adjacency SID for link Ln. The LSR S must use the label stack <L_N- | Let L_A-Ln denote the label used for the adjacency SID for link Ln. | |||
P3, L_A-L1, L_N-D> for traffic-engineering. However to achieve good | The LSR S must use the label stack <L_N-P3, L_A-L1, L_N-D> for | |||
load-balancing over the equal cost paths P2-P4-D, P2-P5-D and the | traffic-engineering. However to achieve good load-balancing over the | |||
parallel links L3, L4, a mechanism such as Entropy labels [RFC6790] | equal cost paths P2-P4-D, P2-P5-D and the parallel links L3, L4, a | |||
should be adapted for source routed label stacks. Indeed, the SPRING | mechanism such as Entropy labels [RFC6790] should be adapted for | |||
architecture with the MPLS dataplane uses nested MPLS LSPs composing | source routed label stacks. Indeed, the SPRING architecture with the | |||
the source routed label stacks. As each MPLS node may have | MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]) uses nested | |||
limitations in the number of labels it can push when it is ingress or | MPLS LSPs composing the source routed label stacks. As each MPLS | |||
inspect when doing load-balancing, an entropy label insertion | node may have limitations in the number of labels it can push when it | |||
strategy becomes important to keep the benefit of the load-balancing. | is ingress or inspect when doing load-balancing, an entropy label | |||
Multiple ways to apply entropy labels were considered and are | insertion strategy becomes important to keep the benefit of the load- | |||
documented in Section 10 along with their trade-offs. A recommended | balancing. Multiple ways to apply entropy labels were considered and | |||
solution is described in Section 7. | are documented in Section 10 along with their trade-offs. A | |||
recommended solution is described in Section 7. | ||||
4. Entropy Readable Label Depth | 4. Entropy Readable Label Depth | |||
The Entropy Readable Label Depth (ERLD) is defined as the number of | The Entropy Readable Label Depth (ERLD) is defined as the number of | |||
labels a router can both: | labels a router can both: | |||
a. Read in an MPLS packet received on its incoming interface(s) | a. Read in an MPLS packet received on its incoming interface(s) | |||
(starting from the top of the stack). | (starting from the top of the stack). | |||
b. Use in its load-balancing function. | b. Use in its load-balancing function. | |||
skipping to change at page 6, line 25 ¶ | skipping to change at page 6, line 25 ¶ | |||
| EL | | ELI | | Label 30 | | Label 30 | | Label 30 | | | EL | | ELI | | Label 30 | | Label 30 | | Label 30 | | |||
+----------+ +----------+ +----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ +----------+ +----------+ | |||
| ELI | | Label 20 | | Label 20 | | Label 20 | | Label 20 | | | ELI | | Label 20 | | Label 20 | | Label 20 | | Label 20 | | |||
+----------+ +----------+ +----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ +----------+ +----------+ | |||
| Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | | Label 16 | P1 | |||
+----------+ +----------+ +----------+ +----------+ +----------+ | +----------+ +----------+ +----------+ +----------+ +----------+ | |||
Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 | Packet 1 Packet 2 Packet 3 Packet 4 Packet 5 | |||
Figure 2: Label stacks with ELI/EL | Figure 2: Label stacks with ELI/EL | |||
In the figure below, we consider the displayed packets received on a | In the figure 2, we consider the displayed packets received on a | |||
router interface. We consider also a single ERLD value for the | router interface. We consider also a single ERLD value for the | |||
router. | router. | |||
o If the router has an ERLD of 3, it will be able to load-balance | o If the router has an ERLD of 3, it will be able to load-balance | |||
Packet 1 displayed in Figure 2 using the EL as part of the load- | Packet 1 displayed in Figure 2 using the EL as part of the load- | |||
balancing keys. The ERLD value of 3 means that the router can | balancing keys. The ERLD value of 3 means that the router can | |||
read and take into account the entropy label for load-balancing if | read and take into account the entropy label for load-balancing if | |||
it is placed between position 1 (top) and position 3. | it is placed between position 1 (top) and position 3. | |||
o If the router has an ERLD of 5, it will be able to load-balance | o If the router has an ERLD of 5, it will be able to load-balance | |||
skipping to change at page 7, line 6 ¶ | skipping to change at page 7, line 6 ¶ | |||
load-balancing keys. | load-balancing keys. | |||
To allow an efficient load-balancing based on entropy labels, a | To allow an efficient load-balancing based on entropy labels, a | |||
router running SPRING SHOULD advertise its ERLD (or ERLDs), so all | router running SPRING SHOULD advertise its ERLD (or ERLDs), so all | |||
the other SPRING routers in the network are aware of its capability. | the other SPRING routers in the network are aware of its capability. | |||
How this advertisement is done is outside the scope of this document. | How this advertisement is done is outside the scope of this document. | |||
To advertise an ERLD value, a SPRING router: | To advertise an ERLD value, a SPRING router: | |||
o MUST be entropy label capable and, as a consequence, MUST apply | o MUST be entropy label capable and, as a consequence, MUST apply | |||
all the procedures defined in [RFC6790]. | the dataplane procedures defined in [RFC6790]. | |||
o MUST be able to read an ELI/EL which is located within its ERLD | o MUST be able to read an ELI/EL which is located within its ERLD | |||
value. | value. | |||
o MUST take into account this EL in its load-balancing function. | o MUST take into account this EL in its load-balancing function. | |||
5. Maximum SID Depth | 5. Maximum SID Depth | |||
The Maximum SID Depth defines the maximum number of labels that a | The Maximum SID Depth defines the maximum number of labels that a | |||
particular node can impose on a packet. This includes any kind of | particular node can impose on a packet. This includes any kind of | |||
skipping to change at page 7, line 50 ¶ | skipping to change at page 7, line 50 ¶ | |||
/ \ | / \ | |||
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 | PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 | |||
| \ | | | \ | | |||
----> P10 \ | | ----> P10 \ | | |||
IP Pkt | \ | | IP Pkt | \ | | |||
P11 --- P12 --- P13 | P11 --- P12 --- P13 | |||
100 10000 | 100 10000 | |||
Figure 3 | Figure 3 | |||
In the Figure 3, an IP packet comes in the MPLS network at PE1. All | In the figure 3, an IP packet comes in the MPLS network at PE1. All | |||
metrics are considered equal to 1 except P12-P13 which is 10000 and | metrics are considered equal to 1 except P12-P13 which is 10000 and | |||
P11-P12 which is 100. PE1 wants to steer the traffic using a SPRING | P11-P12 which is 100. PE1 wants to steer the traffic using a SPRING | |||
path to PE2 along | path to PE2 along | |||
PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. By using | PE1->P1->P7->P8->P9->P4->P5->P10->P11->P12->P13->PE2. By using | |||
Adjacency SIDs only, PE1 will be required to push (as an I-LSR) 10 | adjacency SIDs only, PE1 (acting as an I-LSR) will be required to | |||
labels on the IP packet received and so requires an MSD of 10. If | push 10 labels on the IP packet received and thus requires an MSD of | |||
the IP packet should be carried over an MPLS service like a regular | 10. If the IP packet should be carried over an MPLS service like a | |||
layer 3 VPN, an additional service label will be imposed, requiring | regular layer 3 VPN, an additional service label should be imposed, | |||
an MSD of 11 for PE1. In addition, if PE1 wants to insert an ELI/EL | requiring an MSD of 11 for PE1. In addition, if PE1 wants to insert | |||
for load-balancing purpose, PE1 will need to push 13 labels on the IP | an ELI/EL for load-balancing purpose, PE1 will need to push 13 labels | |||
packet requiring an MSD of 13. | on the IP packet requiring an MSD of 13. | |||
In the SPRING architecture, Node SIDs or Binding SIDs can be used to | In the SPRING architecture, Node SIDs or Binding SIDs can be used to | |||
reduce the label stack size. As an example, to steer the traffic on | reduce the label stack size. As an example, to steer the traffic on | |||
the same path as before, PE1 may be able to use the following label | the same path as before, PE1 may be able to use the following label | |||
stack: <Node_P9, Node_P5, Binding_P5, Node_PE2>. In this example we | stack: <Node_P9, Node_P5, Binding_P5, Node_PE2>. In this example we | |||
consider a combination of Node SIDs and a Binding SID advertised by | consider a combination of Node SIDs and a Binding SID advertised by | |||
P5 that will stitch the traffic along the path P10->P11->P12->P13. | P5 that will stitch the traffic along the path P10->P11->P12->P13. | |||
The instruction associated with the binding SID at P5 is thus to swap | The instruction associated with the binding SID at P5 is thus to swap | |||
Binding_P5 to Adj_P12-P13 and then push <Adj_P11-P12, Node_P11>. P5 | Binding_P5 to Adj_P12-P13 and then push <Adj_P11-P12, Node_P11>. P5 | |||
acts as a stitching node that pushes additional labels on an existing | acts as a stitching node that pushes additional labels on an existing | |||
label stack, P5's MSD needs also to be taken into account and may | label stack, P5's MSD needs also to be taken into account and may | |||
limit the number of labels that could be imposed. | limit the number of labels that could be imposed. | |||
6. LSP stitching using the binding SID | 6. LSP stitching using the binding SID | |||
The binding SID allows binding a segment identifier to an existing | The binding SID allows binding a segment identifier to an existing | |||
LSP. As examples, the binding SID can represent an RSVP-TE tunnel, | LSP. As examples, the binding SID can represent an RSVP-TE tunnel, | |||
an LDP path (through the mapping server advertisement), a SPRING | an LDP path (through the mapping server advertisement), or a SPRING | |||
path... Each LSP associated with a binding SID has its own entropy | path. Each LSP associated with a binding SID has its own entropy | |||
label capability. | label capability. | |||
In the figure 3, if we consider that: | In the figure 3, we consider that: | |||
o P6, PE2, P10, P11, P12 are pure LDP routers. | o P6, PE2, P10, P11, P12, P13 are pure LDP routers. | |||
o PE1, P1, P2, P3, P4, P7, P8, P9 are pure SPRING routers. | o PE1, P1, P2, P3, P4, P7, P8, P9 are pure SPRING routers. | |||
o P5 is running SPRING and LDP. | o P5 is running SPRING and LDP. | |||
o P5 acts as a mapping server (MS) and advertises Prefix SIDs for | o P5 acts as a mapping server and advertises Prefix SIDs for the LDP | |||
the LDP FECs: an index value of 20 is used for PE2. | FECs: an index value of 20 is used for PE2. | |||
o All SPRING routers use an SRGB of [1000, 1999]. | o All SPRING routers use an SRGB of [1000, 1999]. | |||
o P6 advertises label 20 for the PE2 FEC. | o P6 advertises label 20 for the PE2 FEC. | |||
o Traffic from PE1 to PE2 uses the shortest path. | o Traffic from PE1 to PE2 uses the shortest path. | |||
PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2 | PE1 ----- P1 -- P2 -- P3 -- P4 ---- P5 --- P6 --- PE2 | |||
--> +----+ +----+ +----+ +----+ | --> +----+ +----+ +----+ +----+ | |||
IP Pkt | IP | | IP | | IP | | IP | | IP Pkt | IP | | IP | | IP | | IP | | |||
+----+ +----+ +----+ +----+ | +----+ +----+ +----+ +----+ | |||
|1020| |1020| | 20 | | |1020| |1020| | 20 | | |||
+----+ +----+ +----+ | +----+ +----+ +----+ | |||
SPRING LDP | SPRING LDP | |||
In term of packet forwarding, by learning the MS advertisement from | In term of packet forwarding, by learning the mapping-server | |||
PE5, PE1 imposes a label 1020 to an IP packet destinated to PE2. | advertisement from PE5, PE1 imposes a label 1020 to an IP packet | |||
SPRING routers along the shortest path to PE2 will switch the traffic | destinated to PE2. SPRING routers along the shortest path to PE2 | |||
until it reaches P5 which will perform the LSP stitching. P5 will | will switch the traffic until it reaches P5 which will perform the | |||
swap the SPRING label 1020 to the LDP label 20 advertised by the | LSP stitching. P5 will swap the SPRING label 1020 to the LDP label | |||
nexthop P6. P6 will then forward the packet using the LDP label | 20 advertised by the nexthop P6. P6 will then forward the packet | |||
towards PE2. | using the LDP label towards PE2. | |||
PE1 cannot push an ELI/EL for the binding SID without knowing that | PE1 cannot push an ELI/EL for the binding SID without knowing that | |||
the tail-end of the LSP associated with the binding (PE2) is entropy | the tail-end of the LSP associated with the binding (PE2) is entropy | |||
label capable. | label capable. | |||
To accomodate the mix of signalling protocols involved during the | To accomodate the mix of signalling protocols involved during the | |||
stitching, the entropy label capability SHOULD be propagated between | stitching, the entropy label capability SHOULD be propagated between | |||
the signalling protocols. Each binding SID SHOULD have its own | the signalling protocols. Each binding SID SHOULD have its own | |||
entropy label capability that MUST be inherited from the entropy | entropy label capability that MUST be inherited from the entropy | |||
label capability of the associated LSP. If the router advertising | label capability of the associated LSP. If the router advertising | |||
skipping to change at page 10, line 9 ¶ | skipping to change at page 10, line 9 ¶ | |||
The proposed solution only works if the SPRING router advertising the | The proposed solution only works if the SPRING router advertising the | |||
binding SID is also performing the dataplane LSP stitching. In our | binding SID is also performing the dataplane LSP stitching. In our | |||
example, if the mapping server function is hosted on P8 instead of | example, if the mapping server function is hosted on P8 instead of | |||
P5, P8 does not know about the ELC state of PE2's LDP FEC. As a | P5, P8 does not know about the ELC state of PE2's LDP FEC. As a | |||
consequence, it does not set the ELC for the associated binding SID. | consequence, it does not set the ELC for the associated binding SID. | |||
7. Insertion of entropy labels for SPRING path | 7. Insertion of entropy labels for SPRING path | |||
7.1. Overview | 7.1. Overview | |||
The solution described in this section follows [RFC6790]. Within a | The solution described in this section follows the dataplane | |||
SPRING path, a node may be ingress, egress, transit (regarding the | processing defined in [RFC6790]. Within a SPRING path, a node may be | |||
entropy label processing described in [RFC6790]), or it can be any | ingress, egress, transit (regarding the entropy label processing | |||
combination of those. For example: | described in [RFC6790]), or it can be any combination of those. For | |||
example: | ||||
o The ingress node of a SPRING domain may be an ingress node from an | o The ingress node of a SPRING domain may be an ingress node from an | |||
entropy label perspective. | entropy label perspective. | |||
o Any LSR terminating a segment of the SPRING path is an egress node | o Any LSR terminating a segment of the SPRING path is an egress node | |||
(because it terminates the segment) but may also be a transit node | (because it terminates the segment) but may also be a transit node | |||
if the SPRING path is not terminated because there is a subsequent | if the SPRING path is not terminated because there is a subsequent | |||
SPRING MPLS label in the stack. | SPRING MPLS label in the stack. | |||
o Any LSR processing a binding SID may be a transit node and an | o Any LSR processing a binding SID may be a transit node and an | |||
ingress node (because it may push additional labels when | ingress node (because it may push additional labels when | |||
processing the binding SID). | processing the binding SID). | |||
As described earlier, an LSR may have a limitation, ERLD, on the | As described earlier, an LSR may have a limitation, ERLD, on the | |||
depth of the label stack that it can read and process in order to do | depth of the label stack that it can read and process in order to do | |||
multipath load-balancing based on entropy labels. | multipath load-balancing based on entropy labels. | |||
If an EL does not occur within the ERLD of an LSR in the label stack | If an EL does not occur within the ERLD of an LSR in the label stack | |||
of an MPLS packet that it receives, then it would lead to poor load- | of an MPLS packet that it receives, then it would lead to poor load- | |||
balancing at that LSR. Hence an ELI/EL pair MUST be within the ERLD | balancing at that LSR. Hence an ELI/EL pair must be within the ERLD | |||
of the LSR in order for the LSR to use the EL during load-balancing. | of the LSR in order for the LSR to use the EL during load-balancing. | |||
Adding a single ELI/EL pair for the entire SPRING path may lead also | Adding a single ELI/EL pair for the entire SPRING path may lead also | |||
to poor load-balancing as well because the EL/ELI may not occur | to poor load-balancing as well because the EL/ELI may not occur | |||
within the ERLD of some LSR on the path (if too deep) or may not be | within the ERLD of some LSR on the path (if too deep) or may not be | |||
present in the stack when it reaches some LSRs if it is too shallow. | present in the stack when it reaches some LSRs if it is too shallow. | |||
In order for the EL to occur within the ERLD of LSRs along the path | In order for the EL to occur within the ERLD of LSRs along the path | |||
corresponding to a SPRING label stack, multiple <ELI, EL> pairs MAY | corresponding to a SPRING label stack, multiple <ELI, EL> pairs MAY | |||
be inserted in this label stack. | be inserted in this label stack. | |||
The insertion of the ELI/EL SHOULD occur only with a SPRING label | The insertion of the ELI/EL SHOULD occur only with a SPRING label | |||
advertised by an LSR that advertised an ERLD (the LSR is entropy | advertised by an LSR that advertised an ERLD (the LSR is entropy | |||
label capable) or with a SPRING label associated with a binding SID | label capable) or with a SPRING label associated with a binding SID | |||
that has the ELC set. | that has the ELC set. | |||
The ELs among multiple <ELI, EL> pairs inserted in the stack MAY be | The ELs among multiple <ELI, EL> pairs inserted in the stack MAY be | |||
the same or different. The LSR that inserts <ELI, EL> pairs MAY have | the same or different. The LSR that inserts <ELI, EL> pairs MAY have | |||
limitations on the number of such pairs that it can insert and also | limitations on the number of such pairs that it can insert and also | |||
the depth at which it can insert them. If due to limitations, the | the depth at which it can insert them. If, due to limitations, the | |||
inserted ELs are at positions such that an LSR along the path | inserted ELs are at positions such that an LSR along the path | |||
receives an MPLS packet without an EL in the label stack within that | receives an MPLS packet without an EL in the label stack within that | |||
LSR's ERLD, then the load-balancing performed by that LSR would be | LSR's ERLD, then the load-balancing performed by that LSR would be | |||
poor. An implementation MAY consider multiple criteria when | poor. An implementation MAY consider multiple criteria when | |||
inserting <ELI, EL> pairs. | inserting <ELI, EL> pairs. | |||
7.1.1. Example 1 | 7.1.1. Example 1 where the ingress node has a sufficient MSD | |||
ECMP LAG LAG | ECMP LAG LAG | |||
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 | PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- PE2 | |||
Figure 4 | Figure 4 | |||
In the Figure 4, PE1 wants to forward some MPLS VPN traffic over an | In the figure 4, PE1 wants to forward some MPLS VPN traffic over an | |||
explicit path to PE2 resulting in the following label stack to be | explicit path to PE2 resulting in the following label stack to be | |||
pushed onto the received IP header: {VPN_label, Adj_P6PE2, Adj_P5P6, | pushed onto the received IP header: <Adj_P1P2, Adj_set_P2P3, | |||
Adj_P4P5, Adj_P3P4, Adj_Bundle_P2P3, Adj_P1P2}. PE1 is limited to | Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_P6PE2, VPN_label>. PE1 is limited | |||
push a maximum of 11 labels (MSD=11). P2, P3 and P6 have an ERLD of | to push a maximum of 11 labels (MSD=11). P2, P3 and P6 have an ERLD | |||
3 while others have an ERLD of 10. | of 3 while others have an ERLD of 10. | |||
PE1 can only add two ELI/EL pairs in the label stack due to its MSD | PE1 can only add two ELI/EL pairs in the label stack due to its MSD | |||
limitation. It should insert them strategically to benefit load- | limitation. It should insert them strategically to benefit load- | |||
balancing along the longest part of the path. | balancing along the longest part of the path. | |||
PE1 may take into account multiple parameters when inserting ELs, as | PE1 may take into account multiple parameters when inserting ELs, as | |||
examples: | examples: | |||
o The ERLD value advertised by transit nodes. | o The ERLD value advertised by transit nodes. | |||
o The requirement of load-balancing for a particular label value. | o The requirement of load-balancing for a particular label value. | |||
o Any service provider preference: favor beginning of the path or | o Any service provider preference: favor beginning of the path or | |||
end of the path. | end of the path. | |||
In the Figure 4, a good strategy may be to use the following stack | In the figure 4, a good strategy may be to use the following stack | |||
{VPN_label, ELI2,EL2, Adj_P6PE2, Adj_P5P6, Adj_P4P5, Adj_P3P4, ELI1, | <Adj_P1P2, Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, | |||
EL1, Adj_Bundle_P2P3, Adj_P1P2}. The original stack requests P2 to | Adj_P6PE2, VPN_label>. The original stack requests P2 to forward | |||
forward based on a bundle Adjacency segment that will require load- | based on a L3 adjacency set that will require load-balancing. | |||
balancing. Therefore it is important to ensure that P2 can load- | Therefore it is important to ensure that P2 can load-balance | |||
balance correctly. As P2 has a limited ERLD of 3, ELI/EL must be | correctly. As P2 has a limited ERLD of 3, ELI/EL must be inserted | |||
inserted just next to the label that P2 will use to forward. On the | just next to the label that P2 will use to forward. On the path to | |||
path to PE2, P3 has also a limited ERLD, but P3 will forward based on | PE2, P3 has also a limited ERLD, but P3 will forward based on a basic | |||
a basic adjacency segment that may require no load-balancing. | adjacency segment that may require no load-balancing. Therefore it | |||
Therefore it does not seem important to ensure that P3 can do load- | does not seem important to ensure that P3 can do load-balancing | |||
balancing despite of its limited ERLD. The next nodes along the | despite of its limited ERLD. The next nodes along the forwarding | |||
forwarding path have a high ERLD that does not cause any issue, | path have a high ERLD that does not cause any issue, except P6, | |||
except P6, moreover P6 is using some LAGs to PE2 and so is expected | moreover P6 is using some LAGs to PE2 and so is expected to load- | |||
to load-balance. It becomes important to insert a new ELI/EL just | balance. It becomes important to insert a new ELI/EL just next to P6 | |||
next to P6 forwarding label. | forwarding label. | |||
In the case above, the ingress node had enough label push capacity to | In the case above, the ingress node had enough label push capacity to | |||
ensure end-to-end load-balancing taking into the path attributes. | ensure end-to-end load-balancing taking into the path attributes. | |||
There might be some cases, where the ingress node may not have the | There might be some cases, where the ingress node may not have the | |||
necessary label imposition capacity. | necessary label imposition capacity. | |||
7.1.2. Example 2 | 7.1.2. Example 2 where the ingress node has not a sufficient MSD | |||
ECMP LAG ECMP ECMP | ECMP LAG ECMP ECMP | |||
PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2 | PE1 --- P1 --- P2 --- P3 --- P4 --- P5 --- P6 --- P7 --- P8 --- PE2 | |||
Figure 5 | Figure 5 | |||
In the Figure 5, PE1 wants to forward MPLS VPN traffic over an | In the figure 5, PE1 wants to forward MPLS VPN traffic over an | |||
explicit path to PE2 resulting in the following label stack to be | explicit path to PE2 resulting in the following label stack to be | |||
pushed onto the IP header: {VPN_label, Adj_Bundle_P8PE2, Adj_P7P8, | pushed onto the IP header: <Adj_P1P2, Adj_set_P2P3, Adj_P3P4, | |||
Adj_Bundle_P6P7, Adj_P5P6, Adj_P4P5, Adj_P3P4, Adj_Bundle_P2P3, | Adj_P4P5, Adj_P5P6, Adj_set_P6P7, Adj_P7P8; Adj_set_P8PE2, | |||
Adj_P1P2}. PE1 is limited to push a maximum of 11 labels, P2, P3 and | VPN_label>. PE1 is limited to push a maximum of 11 labels, P2, P3 | |||
P6 have an ERLD of 3 while others have an ERLD of 15. | and P6 have an ERLD of 3 while others have an ERLD of 15. | |||
Using a similar strategy as the previous case may lead to a dilemma, | Using a similar strategy as the previous case may lead to a dilemma, | |||
as PE1 can only push a single ELI/EL while we may need a minimum of | as PE1 can only push a single ELI/EL while we may need a minimum of | |||
three to load-balance the end-to-end path. An optimized stack that | three to load-balance the end-to-end path. An optimized stack that | |||
would enable end-to-end load-balancing may be: {VPN_label, ELI3, EL3, | would enable end-to-end load-balancing may be: <Adj_P1P2, | |||
Adj_Bundle_P8PE2, Adj_P7P8, ELI2, EL2, Adj_Bundle_P6P7, Adj_P5P6, | Adj_set_P2P3, ELI1, EL1, Adj_P3P4, Adj_P4P5, Adj_P5P6, Adj_set_P6P7, | |||
Adj_P4P5, Adj_P3P4, ELI1, EL1, Adj_Bundle_P2P3, Adj_P1P2}. | ELI2, EL2, Adj_P7P8; Adj_set_P8PE2, ELI3, EL3, VPN_label>. | |||
A decision needs to be taken to favor some part of the path for load- | A decision needs to be taken to favor some part of the path for load- | |||
balancing considering that load-balancing may not work on the other | balancing considering that load-balancing may not work on the other | |||
part. A service provider may decide to place the ELI/EL after the P6 | part. A service provider may decide to place the ELI/EL after the P6 | |||
forwarding label as it will allow P4 and P6 to load-balance. Placing | forwarding label as it will allow P4 and P6 to load-balance. Placing | |||
the ELI/EL at bottom of the stack is also a possibility enabling | the ELI/EL at bottom of the stack is also a possibility enabling | |||
load-balancing for P4 and P8. | load-balancing for P4 and P8. | |||
7.2. Considerations for the placement of entropy labels | 7.2. Considerations for the placement of entropy labels | |||
skipping to change at page 13, line 9 ¶ | skipping to change at page 13, line 12 ¶ | |||
limited is not an easy decision and multiple criteria may be taken | limited is not an easy decision and multiple criteria may be taken | |||
into account. | into account. | |||
This section describes some considerations that could be taken into | This section describes some considerations that could be taken into | |||
account when placing ELI/ELs. This list of criteria is not | account when placing ELI/ELs. This list of criteria is not | |||
considered as exhaustive and an implementation MAY take into account | considered as exhaustive and an implementation MAY take into account | |||
additional criteria or tie-breakers that are not documented here. | additional criteria or tie-breakers that are not documented here. | |||
An implementation SHOULD try to maximize the load-balancing where | An implementation SHOULD try to maximize the load-balancing where | |||
multiple ECMP paths are available and minimize the number of EL/ELIs | multiple ECMP paths are available and minimize the number of EL/ELIs | |||
that need to be inserted. In case of trade-off, an implementation | that need to be inserted. In case of a trade-off, an implementation | |||
MAY provide flexibility to the operator to select the criteria to be | MAY provide flexibility to the operator to select the criteria to be | |||
considered when placing EL/ELIs or the sub-objective for which to | considered when placing EL/ELIs or the sub-objective for which to | |||
optimize. | optimize. | |||
PE1 -- P1 -- P2 -- P3 -- P4 -- P5 -- ... -- P8 -- P9 -- PE2 | 2 2 | |||
PE1 -- P1 -- P2 --P3 --- P4 --- P5 -- ... -- P8 -- P9 -- PE2 | ||||
| | | | | | |||
P3'--- P4'--- P5' | P3'--- P4'--- P5' | |||
Figure 6 | Figure 6 | |||
The figure above will be used as reference in the following | The figure above will be used as reference in the following | |||
subsections. | subsections. All metrics are equal to 1, except P3-P4 and P4-P5 | |||
which have a metric 2. | ||||
7.2.1. ERLD value | 7.2.1. ERLD value | |||
As mentioned in Section 7.1, the ERLD value is an important parameter | As mentioned in Section 7.1, the ERLD value is an important parameter | |||
to consider when inserting ELI/EL as if an ELI/EL does not fall | to consider when inserting ELI/EL. If an ELI/EL does not fall within | |||
within the ERLD of a node on the path, the node will not be able to | the ERLD of a node on the path, the node will not be able to load- | |||
load-balance the traffic efficiently. | balance the traffic efficiently. | |||
The ERLD value can be advertised via protocols and those extensions | The ERLD value can be advertised via protocols and those extensions | |||
are described in separate documents [I-D.ietf-isis-mpls-elc] and | are described in separate documents [I-D.ietf-isis-mpls-elc] and | |||
[I-D.ietf-ospf-mpls-elc]. | [I-D.ietf-ospf-mpls-elc]. | |||
Let's consider a path from PE1 to PE2 using the following stack | Let's consider a path from PE1 to PE2 using the following stack | |||
pushed by PE1: {Service_label, Adj_PE2P9, Node_P9, Adj_P1P2}. | pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>. | |||
Using the ERLD as an input parameter may help to minimize the number | Using the ERLD as an input parameter may help to minimize the number | |||
of required ELI/EL pairs to be inserted. An ERLD value must be | of required ELI/EL pairs to be inserted. An ERLD value must be | |||
retrieved for each SPRING label in the label stack. | retrieved for each SPRING label in the label stack. | |||
For a label bound to an adjacency segment, the ERLD is the ERLD of | For a label bound to an adjacency segment, the ERLD is the ERLD of | |||
the node that advertised the adjacency segment. In the example | the node that advertised the adjacency segment. In the example | |||
above, the ERLD associated with Adj_P1P2 would be the ERLD of router | above, the ERLD associated with Adj_P1P2 would be the ERLD of router | |||
P1 as P1 will perform the forwarding based on the Adj_P1P2 label. | P1 as P1 will perform the forwarding based on the Adj_P1P2 label. | |||
For a label bound to a node segment, multiple strategies MAY be | For a label bound to a node segment, multiple strategies MAY be | |||
implemented. An implementation may try to evaluate the minimum ERLD | implemented. An implementation may try to evaluate the minimum ERLD | |||
value along the node segment path. If an implementation cannot find | value along the node segment path. If an implementation cannot find | |||
the minimum ERLD along the path of the segment, it can use the ERLD | the minimum ERLD along the path of the segment, it can use the ERLD | |||
of the starting node instead. In the example above, if the | of the starting node instead. In the example above, if the | |||
implementation supports computation of minimum ERLD along the path, | implementation supports computation of minimum ERLD along the path, | |||
the ERLD associated to label Node_P9 would be the minimum ERLD | the ERLD associated with label Node_P9 would be the minimum ERLD | |||
between nodes {P2,P3,P4 ..., P8}. If an implementation does not | between nodes {P2,P3,P4 ..., P8}. If an implementation does not | |||
support the computation of minimum ERLD, it should consider the ERLD | support the computation of minimum ERLD, it should consider the ERLD | |||
of P2 (starting node that will forward based on the Node_P9 label). | of P2 (starting node that will forward based on the Node_P9 label). | |||
For a label bound to a binding segment, if the binding segment | For a label bound to a binding segment, if the binding segment | |||
describes a path, an implementation may also try to evaluate the | describes a path, an implementation may also try to evaluate the | |||
minimum ERLD along this path. If the implementation cannot find the | minimum ERLD along this path. If the implementation cannot find the | |||
minimum ERLD along the path of the segment, it can use the ERLD of | minimum ERLD along the path of the segment, it can use the ERLD of | |||
the starting node instead. | the starting node instead. | |||
skipping to change at page 14, line 27 ¶ | skipping to change at page 14, line 31 ¶ | |||
Depending of the type of segment a particular label is bound to, an | Depending of the type of segment a particular label is bound to, an | |||
implementation may deduce that this particular label will be subject | implementation may deduce that this particular label will be subject | |||
to load-balancing on the path. | to load-balancing on the path. | |||
7.2.2.1. Node-SID | 7.2.2.1. Node-SID | |||
An MPLS label bound to a Node-SID represents a path that may cross | An MPLS label bound to a Node-SID represents a path that may cross | |||
multiple hops. Load-balancing may be needed on the node starting | multiple hops. Load-balancing may be needed on the node starting | |||
this path but also on any node along the path. | this path but also on any node along the path. | |||
Let's consider a path from PE1 to PE2 using the following stack | In the figure 6, let's consider a path from PE1 to PE2 using the | |||
pushed by PE1: {Service_label, Adj_PE2P9, Node_P9, Adj_P1P2}. | following stack pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, | |||
Service_label>. | ||||
If, for example, PE1 is limited to pushing 6 labels, it can add a | If, for example, PE1 is limited to push 6 labels, it can add a single | |||
single ELI/EL within the label stack. An operator may want to favor | ELI/EL within the label stack. An operator may want to favor a | |||
a placement that would allow load-balancing along the Node-SID path. | placement that would allow load-balancing along the Node-SID path. | |||
In the figure above, P3 which is along the Node-SID path requires | In the figure above, P3 which is along the Node-SID path requires | |||
load-balancing on two equal-cost paths. | load-balancing on two equal-cost paths. | |||
An implementation may try to evaluate if load-balancing is really | An implementation may try to evaluate if load-balancing is really | |||
required within a node segment path. This could be done by running | required within a node segment path. This could be done by running | |||
an additional SPT computation and analysis of the node segment path | an additional SPT computation and analysis of the node segment path | |||
to prevent a node segment that does not really require load-balancing | to prevent a node segment that does not really require load-balancing | |||
from being preferred when placing EL/ELIs. Such inspection may be | from being preferred when placing EL/ELIs. Such inspection may be | |||
time consuming for implementations and without a 100% guarantee, as a | time consuming for implementations and without a 100% guarantee, as a | |||
node segment path may use LAG that could be invisible from the IP | node segment path may use LAG that could be invisible from the IP | |||
topology. A simpler approach would be to consider that a label bound | topology. A simpler approach would be to consider that a label bound | |||
to a Node-SID will be subject to load-balancing and requires an EL/ | to a Node-SID will be subject to load-balancing and requires an EL/ | |||
ELI. | ELI. | |||
7.2.2.2. Adjacency-SID representing an ECMP bundle | 7.2.2.2. Adjacency-set SID | |||
When an adjacency segment representing an ECMP bundle is used within | An adjacency-set is an adjacency SID that refers to a set of | |||
a label stack, an implementation can deduce that load-balancing is | adjacencies. When an adjacency-set segment is used within a label | |||
expected at the node that advertised this adjacency segment. An | stack, an implementation can deduce that load-balancing is expected | |||
at the node that advertised this adjacency segment. An | ||||
implementation could then favor this particular label value when | implementation could then favor this particular label value when | |||
placing ELI/ELs. | placing ELI/ELs. | |||
7.2.2.3. Adjacency-SID representing a single IP link | 7.2.2.3. Adjacency-SID representing a single IP link | |||
When an adjacency segment representing a single IP link is used | When an adjacency segment representing a single IP link is used | |||
within a label stack, an implementation can deduce that load- | within a label stack, an implementation can deduce that load- | |||
balancing may not be expected at the node that advertised this | balancing may not be expected at the node that advertised this | |||
adjacency segment. | adjacency segment. | |||
The implementation could then decide to place ELI/ELs to favor other | The implementation could then decide to place ELI/ELs to favor other | |||
LSRs than the one advertising this adjacency segment. | LSRs than the one advertising this adjacency segment. | |||
Readers should note that an adjacency segment representing a single | Readers should note that an adjacency segment representing a single | |||
IP link may require load-balancing. This is the case when a LAG (L2 | IP link may require load-balancing. This is the case when a LAG (L2 | |||
bundle) is implemented between two IP nodes and the L2 bundle SR | bundle) is implemented between two IP nodes and the L2 bundle SR | |||
extensions [I-D.ietf-isis-l2bundles] are not implemented. In such | extensions [I-D.ietf-isis-l2bundles] are not implemented. In such a | |||
case, it may be interesting to keep the possibility to insert an EL/ | case, it may be useful to insert an EL/ELI in a readable position for | |||
ELI in a readable position for the LSR advertising the label | the LSR advertising the label associated with the adjacency segment. | |||
associated with the adjacency segment. | ||||
7.2.2.4. Adjacency-SID representing a single link within an L2 bundle | 7.2.2.4. Adjacency-SID representing a single link within a L2 bundle | |||
When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, | When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, | |||
adjacency segments may be advertised for each member of the bundle. | adjacency segments may be advertised for each member of the bundle. | |||
In this case, an implementation can deduce that load-balancing is not | In this case, an implementation can deduce that load-balancing is not | |||
expected on the LSR advertising this segment and could then decide to | expected on the LSR advertising this segment and could then decide to | |||
place ELI/ELs to favor other LSRs than the one advertising this | place ELI/ELs to favor other LSRs than the one advertising this | |||
adjacency segment. | adjacency segment. | |||
7.2.2.5. Adjacency-SID representing an L2 bundle | 7.2.2.5. Adjacency-SID representing a L2 bundle | |||
When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, an | When L2 bundle SR extensions [I-D.ietf-isis-l2bundles] are used, an | |||
adjacency segment may be advertised to represent the bundle. In this | adjacency segment may be advertised to represent the bundle. In this | |||
case, an implementation can deduce that load-balancing is expected on | case, an implementation can deduce that load-balancing is expected on | |||
the LSR advertising this segment and could then decide to place ELI/ | the LSR advertising this segment and could then decide to place ELI/ | |||
ELs to favor this LSR. | ELs to favor this LSR. | |||
7.2.3. Maximizing number of LSRs that will load-balance | 7.2.3. Maximizing number of LSRs that will load-balance | |||
When placing ELI/ELs, an implementation may try to maximize the | When placing ELI/ELs, an implementation may try to maximize the | |||
number of LSRs that both need to load-balance (i.e., have ECMP paths) | number of LSRs that both need to load-balance (i.e., have ECMP paths) | |||
and that will be able to perform load-balancing (i.e., the EL label | and that will be able to perform load-balancing (i.e., the EL label | |||
is within their ERLD). | is within their ERLD). | |||
Let's consider a path from PE1 to PE2 using the following stack | Let's consider a path from PE1 to PE2 using the following stack | |||
pushed by PE1: {Service_label, Adj_PE2P9, Node_P9, Adj_P1P2}. All | pushed by PE1: <Adj_P1P2, Node_P9, Adj_P9PE2, Service_label>. All | |||
routers have an ERLD of 10, expect P1 and P2 which have an ERLD of 4. | routers have an ERLD of 10, expect P1 and P2 which have an ERLD of 4. | |||
PE1 is able to push 6 labels, so only a single ELI/EL can be added. | PE1 is able to push 6 labels, so only a single ELI/EL can be added. | |||
In the example above, adding ELI/EL next to Adj_P1P2 will only allow | In the example above, adding ELI/EL next to Adj_P1P2 will only allow | |||
load-balancing at P1 while inserting it next to Adj_PE2P9, will allow | load-balancing at P1 while inserting it next to Adj_PE2P9, will allow | |||
load-balancing at P2,P3 ... P9 and maximizing the number of LSRs that | load-balancing at P2,P3 ... P9 and maximizing the number of LSRs that | |||
could perform load-balancing. | could perform load-balancing. | |||
7.2.4. Preference for a part of the path | 7.2.4. Preference for a part of the path | |||
An implementation may propose to favor a part of the end-to-end path | An implementation may propose to favor a part of the end-to-end path | |||
when the number of EL/ELI that can be pushed is not enough to cover | when the number of EL/ELI that can be pushed is not enough to cover | |||
the entire path. As example, a service provider may want to favor | the entire path. As example, a service provider may want to favor | |||
load-balancing at the beginning of the path or at the end of path, so | load-balancing at the beginning of the path or at the end of path, so | |||
the implementation should prefer putting the ELI/ELs near the top or | the implementation should prefer putting the ELI/ELs near the top or | |||
near of the bottom of the stack. | near of the bottom of the stack. | |||
7.2.5. Combining criteria | 7.2.5. Combining criteria | |||
An implementation can combine multiple criteria to determine the best | An implementation can combine multiple criteria to determine the best | |||
EL/ELIs placement. But combining too much criteria may lead to | EL/ELIs placement. However, combining too many criteria may lead to | |||
implementation complexity and high control plane resource | implementation complexity and high resource consumption. Each time | |||
consumption. Each time the network topology changes, a new | the network topology changes, a new evaluation of the EL/ELI | |||
evaluation of the EL/ELI placement will be necessary for each | placement will be necessary for each impacted LSPs. | |||
impacted LSPs. | ||||
8. A simple algorithm example | 8. A simple example algorithm | |||
A simple implementation can only take into account ERLD when placing | A simple implementation might take into account ERLD when placing | |||
ELI/EL while keep minimizing the number of EL/ELIs inserted and | ELI/EL while trying to minimize the number of EL/ELIs inserted and | |||
maximizing the number of LSRs that can load-balance. | trying to maximize the number of LSRs that can load-balance. | |||
The algorithm example is based on the following considerations: | The example algorithm is based on the following considerations: | |||
o An LSR that is limited in the number of <ELI, EL> pairs that it | o An LSR that is limited in the number of <ELI, EL> pairs that it | |||
can insert SHOULD insert such pairs deeper in the stack. | can insert SHOULD insert such pairs deeper in the stack. | |||
o An LSR should try to insert <ELI, EL> pairs at positions so that | o An LSR should try to insert <ELI, EL> pairs at positions so that | |||
for the maximum number of transit LSRs, the EL occurs within the | for the maximum number of transit LSRs, the EL occurs within the | |||
ERLD of those LSRs. | ERLD of those LSRs. | |||
o An LSR should try to insert the minimum number of such pairs while | o An LSR should try to insert the minimum number of such pairs while | |||
trying to satisfy the above criteria. | trying to satisfy the above criteria. | |||
The pseudocode of the example is shown below. | The pseudocode of the example algorithm is shown below. | |||
Initialize the current EL insertion point to the | Initialize the current EL insertion point to the | |||
bottommost label in the stack that is EL-capable | bottommost label in the stack that is EL-capable | |||
while (local-node can push more <ELI,EL> pairs OR | while (local-node can push more <ELI,EL> pairs OR | |||
insertion point is not above label stack) { | insertion point is not above label stack) { | |||
insert an <ELI,EL> pair below current insertion point | insert an <ELI,EL> pair below current insertion point | |||
move new insertion point up from current insertion point until | move new insertion point up from current insertion point until | |||
((last inserted EL is below the ERLD) AND (ERLD > 2) | ((last inserted EL is below the ERLD) AND (ERLD > 2) | |||
AND | AND | |||
(new insertion point is EL-capable)) | (new insertion point is EL-capable)) | |||
set current insertion point to new insertion point | set current insertion point to new insertion point | |||
} | } | |||
Figure 7: Example algorithm to insert <ELI, EL> pairs in a label | Figure 7: Example algorithm to insert <ELI, EL> pairs in a label | |||
stack | stack | |||
When this algorithm is applied to the example described in Section 3, | When this algorithm is applied to the example described in Section 3, | |||
it will result in ELs being inserted in two positions, one below the | it will result in ELs being inserted in two positions, one below the | |||
label L_N-D and another below L_N-P3. Thus the resulting label stack | label L_N-D and another below L_N-P3. Thus the resulting label stack | |||
would be {L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL} | would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL> | |||
9. Deployment Considerations | 9. Deployment Considerations | |||
As long as LSR node dataplane capabilities with be limited (number of | As long as LSR node dataplane capabilities are limited (number of | |||
labels that can be pushed, or number of labels that can be | labels that can be pushed, or number of labels that can be | |||
inspected), hop-by-hop load-balancing of SPRING encapsulated flows | inspected), hop-by-hop load-balancing of SPRING encapsulated flows | |||
will require trade-offs. | will require trade-offs. | |||
Entropy label is still a good and usable solution as it allows load- | Entropy label is still a good and usable solution as it allows load- | |||
balancing without having to perform a deep packet inspection on each | balancing without having to perform a deep packet inspection on each | |||
LSR: it does not seem reasonable to have an LSR inspecting UDP ports | LSR: it does not seem reasonable to have an LSR inspecting UDP ports | |||
within a GRE tunnel carried over a 15 label SPRING tunnel. | within a GRE tunnel carried over a 15 label SPRING tunnel. | |||
Due to the limited capacity of reading a deep stack of MPLS labels, | Due to the limited capacity of reading a deep stack of MPLS labels, | |||
skipping to change at page 18, line 6 ¶ | skipping to change at page 18, line 6 ¶ | |||
Placement strategies of EL/ELIs are required to find the best trade- | Placement strategies of EL/ELIs are required to find the best trade- | |||
off. Multiple criteria may be taken into account and some level of | off. Multiple criteria may be taken into account and some level of | |||
customization (by the user) may be required to accommodate the | customization (by the user) may be required to accommodate the | |||
different deployments. Analyzing the path of each destination to | different deployments. Analyzing the path of each destination to | |||
determine the best EL/ELI placement may be time consuming for the | determine the best EL/ELI placement may be time consuming for the | |||
control plane, we encourage implementations to find the best trade- | control plane, we encourage implementations to find the best trade- | |||
off between simplicity, resource consumption, and load-balancing | off between simplicity, resource consumption, and load-balancing | |||
efficiency. | efficiency. | |||
In future, hardware and software capacity may increase dataplane | In future, hardware and software capacity may increase dataplane | |||
capabilities and may be remove some of these limits, increasing load- | capabilities and may be remove some of these limitations, increasing | |||
balancing capability using entropy labels. | load-balancing capability using entropy labels. | |||
10. Options considered | 10. Options considered | |||
Different options that were considered to arrive at the recommended | Different options that were considered to arrive at the recommended | |||
solution are documented in this section. | solution are documented in this section. | |||
10.1. Single EL at the bottom of the stack of tunnels | These options are detailled here only for historical purposes. | |||
10.1. Single EL at the bottom of the stack | ||||
In this option, a single EL is used for the entire label stack. The | In this option, a single EL is used for the entire label stack. The | |||
source LSR S encodes the entropy label (EL) at the bottom of the | source LSR S encodes the entropy label at the bottom of the label | |||
label stack. In the example described in Section 3, it will result | stack. In the example described in Section 3, it will result in the | |||
in the label stack at LSR S to look like {L_N-P3, L_A-L1, L_N-D, ELI, | label stack at LSR S to look like <L_N-P3, L_A-L1, L_N-D, ELI, EL> | |||
EL} {remaining packet header}. Note that the notation in [RFC6790] | <remaining packet header>. Note that the notation in [RFC6790] is | |||
is used to describe the label stack. An issue with this approach is | used to describe the label stack. An issue with this approach is | |||
that as the label stack grows due an increase in the number of SIDs, | that as the label stack grows due an increase in the number of SIDs, | |||
the EL goes correspondingly deeper in the label stack. Hence, | the EL goes correspondingly deeper in the label stack. Hence, | |||
transit LSRs have to access a larger number of bytes in the packet | transit LSRs have to access a larger number of bytes in the packet | |||
header when making forwarding decisions. In the example described in | header when making forwarding decisions. In the example described in | |||
Section 3, the LSR P1 would load-balance traffic poorly on the | Section 3, if we consider that the LSR P1 has an ERLD of 3, P1 would | |||
parallel links L3 and L4 since the EL is below the ERLD of the packet | load-balance traffic poorly on the parallel links L3 and L4 since the | |||
received by P1. A load-balanced network design using this approach | EL is below the ERLD of P1. A load-balanced network design using | |||
must ensure that all intermediate LSRs have the capability to | this approach must ensure that all intermediate LSRs have the | |||
traverse the maximum label stack depth as required for the | capability to read the maximum label stack depth as required for the | |||
application that uses source routed stacking. | application that uses source routed stacking. | |||
In the case where the hardware is capable of pushing a single <ELI, | ||||
EL> pair at any depth, this option is the same as the recommended | ||||
solution in Section 7. | ||||
This option was rejected since there exist a number of hardware | This option was rejected since there exist a number of hardware | |||
implementations which have a low maximum readable label depth. | implementations which have a low maximum readable label depth. | |||
Choosing this option can lead to a loss of load-balancing using EL in | Choosing this option can lead to a loss of load-balancing using EL in | |||
a significant part of the network when that is a critical requirement | a significant part of the network when that is a critical requirement | |||
in a service-provider network. | in a service-provider network. | |||
10.2. An EL per tunnel in the stack | 10.2. An EL per segment in the stack | |||
In this option, each tunnel in the stack can be given its own EL. | ||||
The source LSR pushes an <ELI, EL> before pushing a tunnel label when | ||||
load-balancing is required to direct traffic on that tunnel. In the | ||||
example described in Section 3, the source LSR S encoded label stack | ||||
would be {L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, EL} where all the ELs | ||||
can be the same. Accessing the EL at an intermediate LSR is | ||||
independent of the depth of the label stack and hence independent of | ||||
the specific application that uses source routed tunnels with label | ||||
stacking. A drawback is that the depth of the label stack grows | ||||
significantly, almost 3 times as the number of labels in the label | ||||
stack. The network design should ensure that source LSRs have the | ||||
capability to push such a deep label stack. Also, the bandwidth | ||||
overhead and potential MTU issues of deep label stacks should be | ||||
considered in the network design. | ||||
In the case where the RLD is the minimum value (3) for all LSRs, all | In this option, each segment/label in the stack can be given its own | |||
LSRs are EL capable and the LSR that is inserting <ELI, EL> pairs has | EL. When load-balancing is required to direct traffic on a segment, | |||
no limit on how many it can insert then this option is the same as | the source LSR pushes an <ELI, EL> before pushing the label | |||
the recommended solution in Section 7. | associated to this segment . In the example described in Section 3, | |||
the source LSR S encoded label stack would be <L_N-P3, ELI, EL, L_A- | ||||
L1, L_N-D, ELI, EL> where all the ELs can be the same. Accessing the | ||||
EL at an intermediate LSR is independent of the depth of the label | ||||
stack and hence independent of the specific application that uses | ||||
source routed tunnels with label stacking. A drawback is that the | ||||
depth of the label stack grows significantly, almost 3 times as the | ||||
number of labels in the label stack. The network design should | ||||
ensure that source LSRs have the capability to push such a deep label | ||||
stack. Also, the bandwidth overhead and potential MTU issues of deep | ||||
label stacks should be considered in the network design. | ||||
This option was rejected due to the existence of hardware | This option was rejected due to the existence of hardware | |||
implementations that can push a limited number of labels on the label | implementations that can push a limited number of labels on the label | |||
stack. Choosing this option would result in a hardware requirement | stack. Choosing this option would result in a hardware requirement | |||
to push two additional labels per tunnel label. Hence it would | to push two additional labels per tunnel label. Hence it would | |||
restrict the number of tunnels that can be stacked in a LSP and hence | restrict the number of tunnels that can be stacked in a LSP and hence | |||
constrain the types of LSPs that can be created. This was considered | constrain the types of LSPs that can be created. This was considered | |||
unacceptable. | unacceptable. | |||
10.3. A re-usable EL for a stack of tunnels | 10.3. A re-usable EL for a stack of tunnels | |||
skipping to change at page 19, line 38 ¶ | skipping to change at page 19, line 31 ¶ | |||
the EL from the outer tunnel when that tunnel is terminated and re- | the EL from the outer tunnel when that tunnel is terminated and re- | |||
inserting it below the next inner tunnel label during the label swap | inserting it below the next inner tunnel label during the label swap | |||
operation. The LSR that stacks tunnels should insert an EL below the | operation. The LSR that stacks tunnels should insert an EL below the | |||
outermost tunnel. It should not insert ELs for any inner tunnels. | outermost tunnel. It should not insert ELs for any inner tunnels. | |||
Also, the penultimate hop LSR of a segment must not pop the ELI and | Also, the penultimate hop LSR of a segment must not pop the ELI and | |||
EL even though they are exposed as the top labels since the | EL even though they are exposed as the top labels since the | |||
terminating LSR of that segment would re-use the EL for the next | terminating LSR of that segment would re-use the EL for the next | |||
segment. | segment. | |||
In Section 3 above, the source LSR S encoded label stack would be | In Section 3 above, the source LSR S encoded label stack would be | |||
{L_N-P3, ELI, EL, L_A-L1, L_N-D}. At P1, the outgoing label stack | <L_N-P3, ELI, EL, L_A-L1, L_N-D>. At P1, the outgoing label stack | |||
would be {L_N-P3, ELI, EL, L_A-L1, L_N-D} after it has load-balanced | would be <L_N-P3, ELI, EL, L_A-L1, L_N-D> after it has load-balanced | |||
to one of the links L3 or L4. At P3 the outgoing label stack would | to one of the links L3 or L4. At P3 the outgoing label stack would | |||
be {L_N-D, ELI, EL}. At P2, the outgoing label stack would be {L_N- | be <L_N-D, ELI, EL>. At P2, the outgoing label stack would be <L_N- | |||
D, ELI, EL} and it would load-balance to one of the nexthop LSRs P4 | D, ELI, EL> and it would load-balance to one of the nexthop LSRs P4 | |||
or P5. Accessing the EL at an intermediate LSR (e.g., P1) is | or P5. Accessing the EL at an intermediate LSR (e.g., P1) is | |||
independent of the depth of the label stack and hence independent of | independent of the depth of the label stack and hence independent of | |||
the specific use-case to which the label stack is applied. | the specific use-case to which the label stack is applied. | |||
This option was rejected due to the significant change in label swap | This option was rejected due to the significant change in label swap | |||
operations that would be required for existing hardware. | operations that would be required for existing hardware. | |||
10.4. EL at top of stack | 10.4. EL at top of stack | |||
A slight variant of the re-usable EL option is to keep the EL at the | A slight variant of the re-usable EL option is to keep the EL at the | |||
skipping to change at page 20, line 33 ¶ | skipping to change at page 20, line 23 ¶ | |||
may have to insert multiple ELs in the label stack at different | may have to insert multiple ELs in the label stack at different | |||
depths for this to work since intermediate LSRs may have differing | depths for this to work since intermediate LSRs may have differing | |||
capabilities in accessing the depth of a label stack. The label | capabilities in accessing the depth of a label stack. The label | |||
stack depth access value of intermediate LSRs must be known to create | stack depth access value of intermediate LSRs must be known to create | |||
such a label stack. How this value is determined is outside the | such a label stack. How this value is determined is outside the | |||
scope of this document. This value can be advertised using a | scope of this document. This value can be advertised using a | |||
protocol such as an IGP. | protocol such as an IGP. | |||
Applying this method to the example in Section 3 above, if LSR P1 | Applying this method to the example in Section 3 above, if LSR P1 | |||
needs to have the EL within a depth of 4, then the source LSR S | needs to have the EL within a depth of 4, then the source LSR S | |||
encoded label stack would be {L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, | encoded label stack would be <L_N-P3, ELI, EL, L_A-L1, L_N-D, ELI, | |||
EL} where all the ELs would typically have the same value. | EL> where all the ELs would typically have the same value. | |||
In the case where the RLD has different values along the path and the | In the case where the ERLD has different values along the path and | |||
LSR that is inserting <ELI, EL> pairs has no limit on how many pairs | the LSR that is inserting <ELI, EL> pairs has no limit on how many | |||
it can insert, and it knows the appropriate positions in the stack | pairs it can insert, and it knows the appropriate positions in the | |||
where they should be inserted, this option is the same as the | stack where they should be inserted, this option is the same as the | |||
recommended solution in Section 7. | recommended solution in Section 7. | |||
Note that a refinement of this solution which balances the number of | Note that a refinement of this solution which balances the number of | |||
pushed labels against the desired entropy is the solution described | pushed labels against the desired entropy is the solution described | |||
in Section 7. | in Section 7. | |||
11. Acknowledgements | 11. Acknowledgements | |||
The authors would like to thank John Drake, Loa Andersson, Curtis | The authors would like to thank John Drake, Loa Andersson, Curtis | |||
Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, | Villamizar, Greg Mirsky, Markus Jork, Kamran Raza, Carlos Pignataro, | |||
Bruno Decraene and Nobo Akiya for their review comments and | Bruno Decraene, Chris Bowers and Nobo Akiya for their review comments | |||
suggestions. | and suggestions. | |||
12. Contributors | 12. Contributors | |||
Xiaohu Xu | Xiaohu Xu | |||
Huawei | Huawei | |||
Email: xuxiaohu@huawei.com | Email: xuxiaohu@huawei.com | |||
Wim Hendrickx | Wim Hendrickx | |||
Nokia | Nokia | |||
Email: wim.henderickx@nokia.com | Email: wim.henderickx@nokia.com | |||
skipping to change at page 21, line 44 ¶ | skipping to change at page 21, line 41 ¶ | |||
This document does not introduce any new security considerations | This document does not introduce any new security considerations | |||
beyond those already listed in [RFC6790]. | beyond those already listed in [RFC6790]. | |||
15. References | 15. References | |||
15.1. Normative References | 15.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and | |||
L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | L. Yong, "The Use of Entropy Labels in MPLS Forwarding", | |||
RFC 6790, DOI 10.17487/RFC6790, November 2012, | RFC 6790, DOI 10.17487/RFC6790, November 2012, | |||
<http://www.rfc-editor.org/info/rfc6790>. | <https://www.rfc-editor.org/info/rfc6790>. | |||
[RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., | [RFC7855] Previdi, S., Ed., Filsfils, C., Ed., Decraene, B., | |||
Litkowski, S., Horneffer, M., and R. Shakir, "Source | Litkowski, S., Horneffer, M., and R. Shakir, "Source | |||
Packet Routing in Networking (SPRING) Problem Statement | Packet Routing in Networking (SPRING) Problem Statement | |||
and Requirements", RFC 7855, DOI 10.17487/RFC7855, May | and Requirements", RFC 7855, DOI 10.17487/RFC7855, May | |||
2016, <http://www.rfc-editor.org/info/rfc7855>. | 2016, <https://www.rfc-editor.org/info/rfc7855>. | |||
[I-D.ietf-spring-segment-routing] | ||||
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | ||||
and R. Shakir, "Segment Routing Architecture", draft-ietf- | ||||
spring-segment-routing-12 (work in progress), June 2017. | ||||
[I-D.ietf-spring-segment-routing-mpls] | ||||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | ||||
Litkowski, S., and R. Shakir, "Segment Routing with MPLS | ||||
data plane", draft-ietf-spring-segment-routing-mpls-10 | ||||
(work in progress), June 2017. | ||||
15.2. Informative References | 15.2. Informative References | |||
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | |||
Hierarchy with Generalized Multi-Protocol Label Switching | Hierarchy with Generalized Multi-Protocol Label Switching | |||
(GMPLS) Traffic Engineering (TE)", RFC 4206, | (GMPLS) Traffic Engineering (TE)", RFC 4206, | |||
DOI 10.17487/RFC4206, October 2005, | DOI 10.17487/RFC4206, October 2005, | |||
<http://www.rfc-editor.org/info/rfc4206>. | <https://www.rfc-editor.org/info/rfc4206>. | |||
[RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., | [RFC7325] Villamizar, C., Ed., Kompella, K., Amante, S., Malis, A., | |||
and C. Pignataro, "MPLS Forwarding Compliance and | and C. Pignataro, "MPLS Forwarding Compliance and | |||
Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, | Performance Requirements", RFC 7325, DOI 10.17487/RFC7325, | |||
August 2014, <http://www.rfc-editor.org/info/rfc7325>. | August 2014, <https://www.rfc-editor.org/info/rfc7325>. | |||
[I-D.ietf-spring-segment-routing] | ||||
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., | ||||
and R. Shakir, "Segment Routing Architecture", draft-ietf- | ||||
spring-segment-routing-11 (work in progress), February | ||||
2017. | ||||
[I-D.ietf-isis-mpls-elc] | [I-D.ietf-isis-mpls-elc] | |||
Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | |||
Litkowski, "Signaling Entropy Label Capability Using IS- | Litkowski, "Signaling Entropy Label Capability Using IS- | |||
IS", draft-ietf-isis-mpls-elc-02 (work in progress), | IS", draft-ietf-isis-mpls-elc-02 (work in progress), | |||
October 2016. | October 2016. | |||
[I-D.ietf-ospf-mpls-elc] | [I-D.ietf-ospf-mpls-elc] | |||
Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. | |||
Litkowski, "Signaling Entropy Label Capability Using | Litkowski, "Signaling Entropy Label Capability Using | |||
OSPF", draft-ietf-ospf-mpls-elc-04 (work in progress), | OSPF", draft-ietf-ospf-mpls-elc-04 (work in progress), | |||
November 2016. | November 2016. | |||
[I-D.ietf-isis-l2bundles] | [I-D.ietf-isis-l2bundles] | |||
Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and | Ginsberg, L., Bashandy, A., Filsfils, C., Nanduri, M., and | |||
E. Aries, "Advertising L2 Bundle Member Link Attributes in | E. Aries, "Advertising L2 Bundle Member Link Attributes in | |||
IS-IS", draft-ietf-isis-l2bundles-04 (work in progress), | IS-IS", draft-ietf-isis-l2bundles-07 (work in progress), | |||
April 2017. | May 2017. | |||
Authors' Addresses | Authors' Addresses | |||
Sriganesh Kini | Sriganesh Kini | |||
EMail: sriganeshkini@gmail.com | EMail: sriganeshkini@gmail.com | |||
Kireeti Kompella | Kireeti Kompella | |||
Juniper | Juniper | |||
End of changes. 80 change blocks. | ||||
228 lines changed or deleted | 230 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |