draft-kini-mpls-spring-entropy-label-01.txt | draft-kini-mpls-spring-entropy-label-02.txt | |||
---|---|---|---|---|
Network Working Group S. Kini, Ed. | Network Working Group S. Kini, Ed. | |||
Internet-Draft Ericsson | Internet-Draft Ericsson | |||
Intended status: Informational K. Kompella | Intended status: Informational K. Kompella | |||
Expires: April 2, 2015 Juniper | Expires: April 28, 2015 Juniper | |||
S. Sivabalan | S. Sivabalan | |||
Cisco | Cisco | |||
S. Litkowski | S. Litkowski | |||
Orange | Orange | |||
R. Shakir | R. Shakir | |||
B.T. | B.T. | |||
X. Xu | X. Xu | |||
Huawei | Huawei | |||
W. Hendrickx | W. Hendrickx | |||
Alcatel-Lucent | Alcatel-Lucent | |||
J. Tantsura | J. Tantsura | |||
Ericsson | Ericsson | |||
September 29, 2014 | October 25, 2014 | |||
Entropy labels for source routed stacked tunnels | Entropy labels for source routed stacked tunnels | |||
draft-kini-mpls-spring-entropy-label-01 | draft-kini-mpls-spring-entropy-label-02 | |||
Abstract | Abstract | |||
Source routed tunnel stacking is a technique that can be leveraged to | Source routed tunnel stacking is a technique that can be leveraged to | |||
provide a method to steer a packet through a controlled set of | provide a method to steer a packet through a controlled set of | |||
segments. This can be applied to the Multi Protocol Label Switching | segments. This can be applied to the Multi Protocol Label Switching | |||
(MPLS) data plane. Entropy label (EL) is a technique used in MPLS to | (MPLS) data plane. Entropy label (EL) is a technique used in MPLS to | |||
improve load balancing. This document examines and describes how ELs | improve load balancing. This document examines and describes how ELs | |||
are to be applied to source routed stacked tunnels. | are to be applied to source routed stacked tunnels. | |||
skipping to change at page 1, line 48 | skipping to change at page 1, line 48 | |||
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 2, 2015. | This Internet-Draft will expire on April 28, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2014 IETF Trust and the persons identified as the | Copyright (c) 2014 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 | |||
skipping to change at page 2, line 26 | skipping to change at page 2, line 26 | |||
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 | |||
2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 | 2. Abbreviations and Terminology . . . . . . . . . . . . . . . . 3 | |||
3. Use-case for multipath load balancing in source stacked | 3. Use-case for multipath load balancing in source stacked | |||
tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 | tunnels . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
4. Recommended EL solution for SPRING . . . . . . . . . . . . . 4 | 4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5 | |||
5. Options considered . . . . . . . . . . . . . . . . . . . . . 5 | 5. Options considered . . . . . . . . . . . . . . . . . . . . . 6 | |||
5.1. Single EL at the bottom of the stack of tunnels . . . . . 5 | 5.1. Single EL at the bottom of the stack of tunnels . . . . . 6 | |||
5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 6 | 5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7 | |||
5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 7 | 5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8 | |||
5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 7 | 5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8 | |||
5.4. ELs at readable label stack depths . . . . . . . . . . . 7 | 5.4. ELs at readable label stack depths . . . . . . . . . . . 8 | |||
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 | 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 10 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
1. Introduction | 1. Introduction | |||
The source routed stacked tunnels paradigm is leveraged by techniques | The source routed stacked tunnels paradigm is leveraged by techniques | |||
such as Segment Routing (SR) [I-D.filsfils-spring-segment-routing] to | such as Segment Routing (SR) [I-D.filsfils-spring-segment-routing] to | |||
steer a packet through a set of segments. This can be directly | steer a packet through a set of segments. This can be directly | |||
applied to the MPLS data plane, but it has implications on label | applied to the MPLS data plane, but it has implications on label | |||
stack depth. | stack depth. | |||
Clarifying statements on label stack depth have been provided in | Clarifying statements on label stack depth have been provided in | |||
skipping to change at page 3, line 18 | skipping to change at page 3, line 18 | |||
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. One such issue is addressed by | applied. One such issue is addressed by | |||
[I-D.ravisingh-mpls-el-for-seamless-mpls] but that is when different | [I-D.ravisingh-mpls-el-for-seamless-mpls] but that is when different | |||
levels of the hierarchy are created at different LSRs. The current | levels of the hierarchy are created at different LSRs. The current | |||
document addresses the case where the hierarchy is created at a | document addresses the case where the hierarchy is created at a | |||
single LSR as required by source stacked tunnels. | single LSR as required by source stacked tunnels. | |||
A use-case requiring load balancing with source stacked tunnels is | A use-case requiring load balancing with source stacked tunnels is | |||
given in Section 3. A recommended solution is described in | given in Section 3. A recommended solution is described in Section 4 | |||
Section 4. Options that were considered to arrive at the recommended | keeping in consideration the limitations of implementations when | |||
solution are documented for historical purposes in Section 5. | applying [RFC6790] to deeper label stacks. Options that were | |||
considered to arrive at the recommended solution are documented for | ||||
historical purposes in Section 5. | ||||
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 RFC 2119 [RFC2119]. | document are to be interpreted as described in RFC 2119 [RFC2119]. | |||
Although this document is not a protocol specification, the use of | ||||
this language clarifies the instructions to protocol designers | ||||
producing solutions that satisfy the requirements set out in this | ||||
document. | ||||
2. Abbreviations and Terminology | 2. Abbreviations and Terminology | |||
EL - Entropy Label | EL - Entropy Label | |||
ELI - Entropy Label Identifier | ELI - Entropy Label Identifier | |||
ELC - Entropy Label Capability | ELC - Entropy Label Capability | |||
SR - Segment Routing | SR - Segment Routing | |||
ECMP - Equal Cost Multi Paths | ECMP - Equal Cost Multi Paths | |||
MPLS - Multiprotocol Label Switching | MPLS - Multiprotocol Label Switching | |||
SID - Segment Identifier | SID - Segment Identifier | |||
RLD - Readable Label Depth | ||||
OAM - Operation, Administration and Maintenance | ||||
3. Use-case for multipath load balancing in source stacked tunnels | 3. Use-case for multipath load balancing in source stacked tunnels | |||
Source stacked tunnels have several use-cases, one of which is | Source stacked tunnels have several use-cases, one of which is | |||
service chaining [I-D.filsfils-spring-segment-routing-use-cases]. | service chaining [I-D.filsfils-spring-segment-routing-use-cases]. | |||
Consider the service-chaining network in Figure 1 that has MPLS as | Consider the service-chaining network in Figure 1 that has MPLS as | |||
the data plane. The requirement of the use-case is to create a LSP | the data plane. The requirement of the use-case is to create a LSP | |||
from source LSR S, apply the services S1, S2 and finally terminate | from source LSR S, apply the services S1, S2 and finally terminate | |||
the LSP at destination LSR D. Local load balancing is required | the LSP at destination LSR D. Local load balancing is required | |||
across the parallel links between P1 and S1. Local load balancing is | across the parallel links between P1 and S1. Local load balancing is | |||
also required between the ECMP paths from S1 to S2 i.e., between the | also required between the ECMP paths from S1 to S2 i.e., between the | |||
skipping to change at page 5, line 5 | skipping to change at page 5, line 33 | |||
Figure 1: Service chaining use-case | Figure 1: Service chaining use-case | |||
4. Recommended EL solution for SPRING | 4. Recommended EL solution for SPRING | |||
The solution described in this section follows [RFC6790]. | The solution described in this section follows [RFC6790]. | |||
An LSR may have a limitation in its ability to read and process the | An LSR may have a limitation in its ability to read and process the | |||
label stack in order to do multipath load balancing. This limitation | label stack in order to do multipath load balancing. This limitation | |||
expressed in terms of the number of label stack entries that the LSR | expressed in terms of the number of label stack entries that the LSR | |||
can read and is henceforth referred to as the Readable Label Depth | can read is henceforth referred to as the Readable Label Depth (RLD) | |||
(RLD) capability. In order for the EL to occur within the RLD of | capability of that LSR. If an EL does not occur within the RLD of an | |||
LSRs along the path corresponding to a label stack, multiple <ELI, | LSR in the label stack of the MPLS packet that it receives, then it | |||
EL> pairs MAY be inserted. The recommendations for inserting <ELI, | would lead to poor load balancing at that LSR. The RLD of an LSR is | |||
EL> pairs are: | a characteristic of the forwarding plane of that LSR's implementation | |||
and determining it is outside the scope of this document. | ||||
o <ELI, EL> pairs MUST be inserted below those labels that are | In order for the EL to occur within the RLD of LSRs along the path | |||
advertised with ELC. | corresponding to a label stack, multiple <ELI, EL> pairs MAY be | |||
inserted in the label stack as long as the labels below which they | ||||
are inserted are entropy label capable. The LSR that inserts <ELI, | ||||
EL> pairs MAY have limitations on the number of such pairs that it | ||||
can insert and also the depth at which it can insert them. If due to | ||||
any limitation, the 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 LSR's RLD, then the load balancing performed by | ||||
that LSR would be poor. Special attention should be paid when a | ||||
forwarding adjacency LSP (FA-LSP) [RFC4206] is used as a link along | ||||
the path of a source stacked LSP, since the labels of the FA-LSP | ||||
would additionally count towards the depth of the label stack when | ||||
calculating the appropriate positions to insert the ELs. The | ||||
recommendations for inserting <ELI, EL> pairs are: | ||||
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 prefer to insert such pairs deeper in the stack. | can insert SHOULD insert such pairs deeper in the stack. | |||
o An LSR SHOULD try to insert an <ELI, EL> pair within the RLD of | o An LSR SHOULD try to insert an <ELI, EL> pair within the RLD of | |||
the maximum number of LSRs along the path as it can. | the maximum number of LSRs along the path as it can. | |||
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. | |||
A sample algorithm to insert ELs is shown below. Implementations can | A sample algorithm to insert ELs is shown below. Implementations can | |||
choose any algorithm as long as it follows the above recommendations. | choose any algorithm as long as it follows the above recommendations. | |||
set current EL insertion point to the bottommost EL-capable location | Initialize the current EL insertion point to the | |||
while local-node can push more labels or top of stack has been reached { | bottommost label in the stack that is EL-capable | |||
insert an ELI+EL at current insertion point | while local-node can push more labels OR | |||
move insertion point up until current EL is out of RLD | top of stack has been reached { | |||
AND | insert an ELI+EL at current insertion point | |||
insertion point is EL-capable | move insertion point up until current EL is out of RLD | |||
set current insertion point to new insertion point | AND | |||
} | insertion point is EL-capable | |||
set current insertion point to new insertion point | ||||
} | ||||
Figure 2: Algorithm to insert <ELI, EL> pairs in a label stack | Figure 2: Algorithm to insert <ELI, EL> pairs in a label stack | |||
The RLD can be advertised via protocols and those extensions would be | The RLD can be advertised via protocols and those extensions would be | |||
described in a separate document. | described in a separate document. | |||
The recommendations above are not expected to bring any additional | ||||
OAM considerations beyond those described in section 6 of [RFC6790]. | ||||
However, the OAM requirements and solutions for source stacked | ||||
tunnels are still under discussion and future revisions of this | ||||
document will address those if needed. | ||||
5. Options considered | 5. Options considered | |||
5.1. Single EL at the bottom of the stack of tunnels | 5.1. Single EL at the bottom of the stack of tunnels | |||
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) below the labels of all | source LSR S encodes the entropy label (EL) below the labels of all | |||
the stacked tunnels. In Figure 1 label stack at LSR S would look | the stacked tunnels. In Figure 1 label stack at LSR S would look | |||
like <SP1, SS1, S-SvcS1, SS2, S-SvcS2, SD, ELI, EL> <remaining packet | like <SP1, SS1, S-SvcS1, SS2, S-SvcS2, SD, ELI, EL> <remaining packet | |||
header>. Note that the notation in [RFC6790] is used to describe the | header>. Note that the notation in [RFC6790] is used to describe the | |||
label stack. An issue with this approach is that as the label stack | label stack. An issue with this approach is that as the label stack | |||
skipping to change at page 6, line 29 | skipping to change at page 7, line 32 | |||
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 but that is a critical requirement | a significant part of the network but that is a critical requirement | |||
in a service provider network. | in a service provider network. | |||
5.2. An EL per tunnel in the stack | 5.2. An EL per tunnel in the stack | |||
In this option each tunnel in the stack can be given its own EL. The | 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 | source LSR pushes an <ELI, EL> before pushing a tunnel label when | |||
load balancing is required to direct traffic on that tunnel. For the | load balancing is required to direct traffic on that tunnel. For the | |||
same Figure 1 above, the source LSR S encoded label stack would be | same Figure 1 above, the source LSR S encoded label stack would be | |||
<SS1, ELI, EL1, S-SvcS1, SS2, ELI, EL2, SD> where all the ELs can | <SS1, ELI, EL1, S-SvcS1, SS2, ELI, EL2, S-SvcS2, SD> where all the | |||
have the same value. Accessing the EL at an intermediate LSR is | ELs can have the same value. Accessing the EL at an intermediate LSR | |||
independent of the depth of the label stack and hence independent of | is independent of the depth of the label stack and hence independent | |||
the specific use-case to which the stacked tunnels are applied. A | of the specific use-case to which the stacked tunnels are applied. A | |||
drawback is that the depth of the label stack grows significantly, | drawback is that the depth of the label stack grows significantly, | |||
almost 3 times as the number of labels in the label stack. The | almost 3 times as the number of labels in the label stack. The | |||
network design should ensure that source LSRs should have the | network design should ensure that source LSRs should have the | |||
capability to push such a deep label stack. Also, the bandwidth | capability to push such a deep label stack. Also, the bandwidth | |||
overhead and potential MTU issues of deep label stacks should be | overhead and potential MTU issues of deep label stacks should be | |||
accounted for in the network design. | accounted for in the network design. | |||
In the case where the RLD is the minimum value (3) for all LSRs, all | In the case where the RLD is the minimum value (3) for all LSRs, all | |||
LSRs are EL capable and the LSR that is inserting <ELI, EL> pairs has | LSRs are EL capable and the LSR that is inserting <ELI, EL> pairs has | |||
no limit on how many it can insert then this option is the same as | no limit on how many it can insert then this option is the same as | |||
skipping to change at page 7, line 19 | skipping to change at page 8, line 21 | |||
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. | |||
For the same Figure 1 above, the source LSR S encoded label stack | For the same Figure 1 above, the source LSR S encoded label stack | |||
would be <SS11, ELI, EL, S-SvcS1, SS2, SD>. At P1 the outgoing label | would be <SS11, ELI, EL, S-SvcS1, SS2, S-SvcS2, SD>. At P1 the | |||
stack would be <SS1, ELI, EL, S-SvcS1, SS2, SD> after it has load | outgoing label stack would be <SS1, ELI, EL, S-SvcS1, SS2, S-SvcS2, | |||
balanced to one of the links L1 or L2. At S1 the outgoing label | SD> after it has load balanced to one of the links L1 or L2. At S1 | |||
stack would be <SS2, ELI, EL, SD>. At P2 the outgoing label stack | the outgoing label stack would be <SS2, S-SvS2, ELI, EL, SD>. At P2 | |||
would be <SS2, ELI, EL, SD> and it would load balance to one of the | the outgoing label stack would be <SS2, ELI, EL, S-SvcS2, SD> and it | |||
nexthop LSRs P3 or P4. Accessing the EL at an intermediate LSR (e.g. | would load balance to one of the nexthop LSRs P3 or P4. Accessing | |||
P3) is independent of the depth of the label stack and hence | the EL at an intermediate LSR (e.g. P3) is independent of the depth | |||
independent of the specific use-case to which the stacked tunnels are | of the label stack and hence independent of the specific use-case to | |||
applied. | which the stacked tunnels are applied. | |||
This option was discounted due to the significant change in label | This option was discounted due to the significant change in label | |||
swap operations that would be required for existing hardware. | swap operations that would be required for existing hardware. | |||
5.3.1. EL at top of stack | 5.3.1. 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 | |||
top of the stack rather than below the tunnel label. In this case | top of the stack rather than below the tunnel label. In this case | |||
each LSR that is not terminating a segment should continue to keep | each LSR that is not terminating a segment should continue to keep | |||
the received EL at the top of the stack when forwarding the packet | the received EL at the top of the stack when forwarding the packet | |||
skipping to change at page 8, line 32 | skipping to change at page 9, line 35 | |||
The authors would like to thank John Drake and Loa Andersson for | The authors would like to thank John Drake and Loa Andersson for | |||
their comments. | their comments. | |||
7. IANA Considerations | 7. IANA Considerations | |||
This memo includes no request to IANA. | This memo includes no request to IANA. | |||
8. Security Considerations | 8. Security Considerations | |||
This document does not introduce any new security considerations | ||||
beyond those already listed in [RFC6790]. | ||||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[I-D.filsfils-spring-segment-routing] | [I-D.filsfils-spring-segment-routing] | |||
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | Filsfils, C., Previdi, S., Bashandy, A., Decraene, B., | |||
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | |||
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, | Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe, | |||
"Segment Routing Architecture", draft-filsfils-spring- | "Segment Routing Architecture", draft-filsfils-spring- | |||
segment-routing-04 (work in progress), July 2014. | segment-routing-04 (work in progress), July 2014. | |||
[I-D.filsfils-spring-segment-routing-use-cases] | [I-D.filsfils-spring-segment-routing-use-cases] | |||
Filsfils, C., Francois, P., Previdi, S., Decraene, B., | Filsfils, C., Francois, P., Previdi, S., Decraene, B., | |||
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R., | |||
Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. | Ytti, S., Henderickx, W., Tantsura, J., Kini, S., and E. | |||
Crabbe, "Segment Routing Use Cases", draft-filsfils- | Crabbe, "Segment Routing Use Cases", draft-filsfils- | |||
spring-segment-routing-use-cases-00 (work in progress), | spring-segment-routing-use-cases-01 (work in progress), | |||
March 2014. | October 2014. | |||
[I-D.gredler-spring-mpls] | [I-D.gredler-spring-mpls] | |||
Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu, | Gredler, H., Rekhter, Y., Jalil, L., Kini, S., and X. Xu, | |||
"Supporting Source/Explicitly Routed Tunnels via Stacked | "Supporting Source/Explicitly Routed Tunnels via Stacked | |||
LSPs", draft-gredler-spring-mpls-06 (work in progress), | LSPs", draft-gredler-spring-mpls-06 (work in progress), | |||
May 2014. | May 2014. | |||
[I-D.ravisingh-mpls-el-for-seamless-mpls] | [I-D.ravisingh-mpls-el-for-seamless-mpls] | |||
Singh, R., Shen, Y., and J. Drake, "Entropy label for | Singh, R., Shen, Y., and J. Drake, "Entropy label for | |||
seamless MPLS", draft-ravisingh-mpls-el-for-seamless- | seamless MPLS", draft-ravisingh-mpls-el-for-seamless- | |||
mpls-02 (work in progress), July 2014. | mpls-02 (work in progress), July 2014. | |||
[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, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | ||||
Hierarchy with Generalized Multi-Protocol Label Switching | ||||
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. | ||||
[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, November 2012. | RFC 6790, November 2012. | |||
[RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A., and | [RFC7325] Villamizar, C., Kompella, K., Amante, S., Malis, A., and | |||
C. Pignataro, "MPLS Forwarding Compliance and Performance | C. Pignataro, "MPLS Forwarding Compliance and Performance | |||
Requirements", RFC 7325, August 2014. | Requirements", RFC 7325, August 2014. | |||
9.2. Informative References | 9.2. Informative References | |||
End of changes. 18 change blocks. | ||||
53 lines changed or deleted | 92 lines changed or added | |||
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |