draft-ietf-mpls-spring-entropy-label-03.txt   draft-ietf-mpls-spring-entropy-label-04.txt 
Network Working Group S. Kini, Ed. Network Working Group S. Kini, Ed.
Internet-Draft Internet-Draft
Intended status: Standards Track K. Kompella Intended status: Informational K. Kompella
Expires: October 9, 2016 Juniper Expires: January 9, 2017 Juniper
S. Sivabalan S. Sivabalan
Cisco Cisco
S. Litkowski S. Litkowski
Orange Orange
R. Shakir R. Shakir
J. Tantsura
April 7, 2016 J. Tantsura
July 8, 2016
Entropy labels for source routed tunnels with label stacks Entropy labels for source routed tunnels with label stacks
draft-ietf-mpls-spring-entropy-label-03 draft-ietf-mpls-spring-entropy-label-04
Abstract Abstract
Source routed tunnels with label stacking is a technique that can be Source routed tunnels with label stacking is a technique that can be
leveraged to provide a method to steer a packet through a controlled leveraged to provide a method to steer a packet through a controlled
set of segments. This can be applied to the Multi Protocol Label set of segments. This can be applied to the Multi Protocol Label
Switching (MPLS) data plane. Entropy label (EL) is a technique used Switching (MPLS) data plane. Entropy label (EL) is a technique used
in MPLS to improve load balancing. This document examines and in MPLS to improve load balancing. This document examines and
describes how ELs are to be applied to source routed tunnels with describes how ELs are to be applied to source routed tunnels with
label stacks. label stacks.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 October 9, 2016. This Internet-Draft will expire on January 9, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 36 skipping to change at page 2, line 36
4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5 4. Recommended EL solution for SPRING . . . . . . . . . . . . . 5
5. Options considered . . . . . . . . . . . . . . . . . . . . . 6 5. Options considered . . . . . . . . . . . . . . . . . . . . . 6
5.1. Single EL at the bottom of the stack of tunnels . . . . . 6 5.1. Single EL at the bottom of the stack of tunnels . . . . . 6
5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7 5.2. An EL per tunnel in the stack . . . . . . . . . . . . . . 7
5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8 5.3. A re-usable EL for a stack of tunnels . . . . . . . . . . 8
5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8 5.3.1. EL at top of stack . . . . . . . . . . . . . . . . . 8
5.4. ELs at readable label stack depths . . . . . . . . . . . 8 5.4. ELs at readable label stack depths . . . . . . . . . . . 8
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
The source routed tunnels with label stacking paradigm is leveraged The source routed tunnels with label stacking paradigm is leveraged
by techniques such as Segment Routing (SR) by techniques such as Segment Routing (SR)
[I-D.ietf-spring-segment-routing] to steer a packet through a set of [I-D.ietf-spring-segment-routing] to steer a packet through a set of
skipping to change at page 4, line 39 skipping to change at page 4, line 39
multipath decisions. All other transit LSRs in the figure can read multipath decisions. All other transit LSRs in the figure can read
deep label stacks and the LSR S can insert as many <ELI, EL> pairs as deep label stacks and the LSR S can insert as many <ELI, EL> pairs as
needed. The LSR S requires data to be sent to LSR D along a traffic- needed. The LSR S requires data to be sent to LSR D along a traffic-
engineered path that goes over the link L1. Good load balancing is engineered path that goes over the link L1. Good load balancing is
also required across equal cost paths (including parallel links). To also required across equal cost paths (including parallel links). To
engineer traffic along a path that takes link L1, the label stack engineer traffic along a path that takes link L1, the label stack
that LSR S creates consists of a label to the node SID of LSR P3, that LSR S creates consists of a label to the node SID of LSR P3,
stacked over the label for the adjacency SID of link L1 and that in stacked over the label for the adjacency SID of link L1 and that in
turn is stacked over the label to the node SID of LSR D. For turn is stacked over the label to the node SID of LSR D. For
simplicity lets assume that all LSRs use the same label space for simplicity lets assume that all LSRs use the same label space for
source routed label stacks. Lets L_N-P denote the label to be used source routed label stacks. Let L_N-Px denote the label to be used
to reach the node SID of LSR P. Let L_A-Ln denote the label used for to reach the node SID of LSR Px. Let L_A-Ln denote the label used
the adjacency SID for link Ln. The LSR S must use the label stack for the adjacency SID for link Ln. The LSR S must use the label
<L_N-P3, L_A-L1, L_N-D> for traffic-engineering. However to achieve stack <L_N-P3, L_A-L1, L_N-D> for traffic-engineering. However to
good load balancing over the equal cost paths P2-P4-D, P2-P5-D and achieve good load balancing over the equal cost paths P2-P4-D,
the parallel links L3, L4, a mechanism such as Entropy labels P2-P5-D and the parallel links L3, L4, a mechanism such as Entropy
[RFC6790] should be adapted for source routed label stacks. Multiple labels [RFC6790] should be adapted for source routed label stacks.
ways to apply entropy labels were considered and are documented in Multiple ways to apply entropy labels were considered and are
Section 5 along with their tradeoffs. A recommended solution is documented in Section 5 along with their tradeoffs. A recommended
described in Section 4. solution is described in Section 4.
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 on the depth of the label stack that it
label stack in order to do multipath load balancing. This limitation can read and process in order to do multipath load balancing. This
expressed in terms of the number of label stack entries that the LSR limitation expressed in terms of the number of label stack entries
can read is henceforth referred to as the Readable Label Depth (RLD) that the LSR can read is defined as the Readable Label Depth (RLD)
capability of that LSR. If an EL does not occur within the RLD of an capability of that LSR. If an EL does not occur within the RLD of an
LSR in the label stack of the MPLS packet that it receives, then it LSR in the label stack of the MPLS packet that it receives, then it
would lead to poor load balancing at that LSR. The RLD of an LSR is would lead to poor load balancing at that LSR. Hence an ELI, EL pair
a characteristic of the forwarding plane of that LSR's implementation MUST be within the RLD of the LSR in order for the LSR to use the EL
and determining it is outside the scope of this document. during load balancing. The RLD of an LSR is a characteristic of the
forwarding plane of that LSR's implementation and determining it is
outside the scope of this document.
In order for the EL to occur within the RLD of LSRs along the path In order for the EL to occur within the RLD of LSRs along the path
corresponding to a label stack, multiple <ELI, EL> pairs MAY be corresponding to a label stack, multiple <ELI, EL> pairs MAY be
inserted in the label stack as long as the tunnel's label below which inserted in the label stack as long as the tunnel's label below which
they are inserted are advertised with entropy label capability they are inserted are advertised with entropy label capability
enabled. The LSR that inserts <ELI, EL> pairs MAY have limitations enabled. The ELs among multiple <ELI, EL> pairs inserted in the
on the number of such pairs that it can insert and also the depth at stack may be same or different. The LSR that inserts <ELI, EL> pairs
which it can insert them. If due to any limitation, the inserted ELs MAY have limitations on the number of such pairs that it can insert
are at positions such that an LSR along the path receives an MPLS and also the depth at which it can insert them. If due to any
packet without an EL in the label stack within that LSR's RLD, then limitation, the inserted ELs are at positions such that an LSR along
the load balancing performed by that LSR would be poor. Special the path receives an MPLS packet without an EL in the label stack
attention should be paid when a forwarding adjacency LSP (FA-LSP) within that LSR's RLD, then the load balancing performed by that LSR
[RFC4206] is used as a link along the path of a source routed LSP's would be poor. Special attention should be paid when a forwarding
label stack, since the labels of the FA-LSP would additionally count adjacency LSP (FA-LSP) [RFC4206] is used as a link along the path of
towards the depth of the label stack when calculating the appropriate a source routed LSP's label stack, since the labels of the FA-LSP
positions to insert the ELs. The recommendations for inserting <ELI, would additionally count towards the depth of the label stack when
EL> pairs are: 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 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
RLD of the incoming packet to that LSR. RLD of the incoming packet to that LSR.
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 that follows the above recommendations to insert
choose any algorithm as long as it follows the above recommendations. ELs is shown below. For node SIDs, the minimum value of RLDs of LSRs
on that node segment should be used.
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 RLD) AND (RLD > 2) ((last inserted EL is below the RLD) AND (RLD > 2)
AND AND
(new insertion point is EL-capable)) (new insertion point is EL-capable))
skipping to change at page 6, line 28 skipping to change at page 6, line 28
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>
The RLD can be advertised via protocols and those extensions are The RLD can be advertised via protocols and those extensions are
described in separate documents [I-D.xu-isis-mpls-elc] and described in separate documents [I-D.xu-isis-mpls-elc] and
[I-D.xu-ospf-mpls-elc]. [I-D.xu-ospf-mpls-elc].
It should be noted that the above algorithm is a sample and other
algorithms that optimize for other criteria and provide additional
tuning parameters to give operators the control of the optimization
criteria may be developed.
The recommendations above are not expected to bring any additional The recommendations above are not expected to bring any additional
OAM considerations beyond those described in section 6 of [RFC6790]. OAM considerations beyond those described in section 6 of [RFC6790].
However, the OAM requirements and solutions for source routed tunnels However, the OAM requirements and solutions for source routed tunnels
formed by label stacking are still under discussion and future formed by label stacking are still under discussion and future
revisions of this document will address those if needed. revisions of this document will address those if needed.
5. Options considered 5. 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.
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) at the bottom of the source LSR S encodes the entropy label (EL) at the bottom of the
label stack. In the example described in Section 3 it will result in label stack. In the example described in Section 3, it will result
the label stack at LSR S to look like <L_N-P3, L_A-L1, L_N-D, ELI, in the label stack at LSR S to look like <L_N-P3, L_A-L1, L_N-D, ELI,
EL> <remaining packet header>. Note that the notation in [RFC6790] EL> <remaining packet header>. Note that the notation in [RFC6790]
is used to describe the label stack. An issue with this approach is 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 transit the EL goes correspondingly deeper in the label stack. Hence transit
LSRs have to access a larger number of bytes in the packet header LSRs have to access a larger number of bytes in the packet header
when making forwarding decisions. In the example described in when making forwarding decisions. In the example described in
Section 3 the LSR P1 would poorly load-balance traffic on the Section 3, the LSR P1 would poorly load-balance traffic on the
parallel links L3, L4 since the EL is below the RLD of the packet parallel links L3, L4 since the EL is below the RLD of the packet
received by P1. A load balanced network design using this approach received by P1. A load balanced network design using this approach
must ensure that all intermediate LSRs have the capability to must ensure that all intermediate LSRs have the capability to
traverse the maximum label stack depth as required for that traverse the maximum label stack depth as required for that
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, 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 EL> pair at any depth, this option is the same as the recommended
solution in Section 4. solution in Section 4.
This option was discounted 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 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. In the load balancing is required to direct traffic on that tunnel. In the
skipping to change at page 7, line 41 skipping to change at page 7, line 46
the label stack. The network design should ensure that source LSRs the label stack. The network design should ensure that source LSRs
should have the capability to push such a deep label stack. Also, should have the capability to push such a deep label stack. Also,
the bandwidth overhead and potential MTU issues of deep label stacks the bandwidth overhead and potential MTU issues of deep label stacks
should be accounted for in the network design. should be 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
the recommended solution in Section 4. the recommended solution in Section 4.
This option was discounted 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 form a LSP and constrain the restrict the number of tunnels that can be stacked in a LSP and hence
types of LSPs that can be created. This was considered unacceptable. constrain the types of LSPs that can be created. This was considered
unacceptable.
5.3. A re-usable EL for a stack of tunnels 5.3. A re-usable EL for a stack of tunnels
In this option an LSR that terminates a tunnel re-uses the EL of the In this option an LSR that terminates a tunnel re-uses the EL of the
terminated tunnel for the next inner tunnel. It does this by storing terminated tunnel for the next inner tunnel. It does this by storing
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
skipping to change at page 8, line 28 skipping to change at page 8, line 30
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-D, 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 or 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 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 discounted due to the significant change in label This option was rejected due to the significant change in label swap
swap operations that would be required for existing hardware. 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
along the segment. An LSR that terminates a segment should use the along the segment. An LSR that terminates a segment should use the
EL from the terminated segment at the top of the stack when EL from the terminated segment at the top of the stack when
forwarding onto the next segment. forwarding onto the next segment.
This option was discounted due to the significant change in label This option was rejected due to the significant change in label swap
swap operations that would be required for existing hardware. operations that would be required for existing hardware.
5.4. ELs at readable label stack depths 5.4. ELs at readable label stack depths
In this option the source LSR inserts ELs for tunnels in the label In this option the source LSR inserts ELs for tunnels in the label
stack at depths such that each LSR along the path that must load stack at depths such that each LSR along the path that must load
balance is able to access at least one EL. Note that the source LSR balance is able to access at least one EL. Note that the source LSR
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. For the same Section 3 above, if LSR P1 protocol such as an IGP.
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 RLD has different values along the path and the
LSR that is inserting <ELI, EL> pairs has no limit on how many pairs LSR that is inserting <ELI, EL> pairs has no limit on how many pairs
it can insert, and it knows the appropriate positions in the stack it can insert, and it knows the appropriate positions in the stack
where they should be inserted, then this option is the same as the where they should be inserted, then this option is the same as the
recommended solution in Section 4. recommended solution in Section 4.
A variant of this solution was selected which balances the number of Note that a refinement of this solution which balances the number of
labels that need to be pushed against the requirement for entropy. pushed labels against the desired entropy is the solution described
in Section 4.
6. Acknowledgements 6. 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 and Nobo Akiya for Villamizar, Greg Mirsky, Markus Jork, Kamran Raza and Nobo Akiya for
their review comments and suggestions. their review comments and suggestions.
7. Contributors 7. Contributors
Xiaohu Xu Xiaohu Xu
skipping to change at page 10, line 24 skipping to change at page 10, line 29
[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>. <http://www.rfc-editor.org/info/rfc6790>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Decraene, B., Litkowski, S., Filsfils, C., Previdi, S., Decraene, B., Litkowski, S.,
and R. Shakir, "Segment Routing Architecture", draft-ietf- and R. Shakir, "Segment Routing Architecture", draft-ietf-
spring-segment-routing-07 (work in progress), December spring-segment-routing-09 (work in progress), July 2016.
2015.
[I-D.xu-isis-mpls-elc] [I-D.xu-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-xu-isis-mpls-elc-02 (work in progress), April IS", draft-xu-isis-mpls-elc-02 (work in progress), April
2015. 2015.
[I-D.xu-ospf-mpls-elc] [I-D.xu-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
 End of changes. 22 change blocks. 
54 lines changed or deleted 66 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/