< draft-ietf-mpls-entropy-label-02.txt   draft-ietf-mpls-entropy-label-03.txt >
Network Working Group K. Kompella Network Working Group K. Kompella
Internet-Draft J. Drake Internet-Draft J. Drake
Updates: 3031 (if approved) Juniper Networks Updates: 3031, 5036 (if approved) Juniper Networks
Intended status: Standards Track S. Amante Intended status: Standards Track S. Amante
Expires: November 8, 2012 Level 3 Communications, LLC Expires: November 10, 2012 Level 3 Communications, LLC
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
L. Yong L. Yong
Huawei USA Huawei USA
May 7, 2012 May 9, 2012
The Use of Entropy Labels in MPLS Forwarding The Use of Entropy Labels in MPLS Forwarding
draft-ietf-mpls-entropy-label-02 draft-ietf-mpls-entropy-label-03
Abstract Abstract
Load balancing is a powerful tool for engineering traffic across a Load balancing is a powerful tool for engineering traffic across a
network. This memo suggests ways of improving load balancing across network. This memo suggests ways of improving load balancing across
MPLS networks using the concept of "entropy labels". It defines the MPLS networks using the concept of "entropy labels". It defines the
concept, describes why entropy labels are useful, enumerates concept, describes why entropy labels are useful, enumerates
properties of entropy labels that allow maximal benefit, and shows properties of entropy labels that allow maximal benefit, and shows
how they can be signaled and used for various applications. how they can be signaled and used for various applications.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 8, 2012. This Internet-Draft will expire on November 10, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 8 3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 8
4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 9 4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 9
4.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 11
4.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 11 4.4. Penultimate Hop LSR . . . . . . . . . . . . . . . . . . . 11
5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 11 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 11
5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 12 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 12
5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 12 5.1.1. Processing the ELC TLV . . . . . . . . . . . . . . . . 12
5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 13 5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 13
5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 14
5.4. Multicast LSPs and Entropy Labels . . . . . . . . . . . . 14
6. Operations, Administration, and Maintenance (OAM) and 6. Operations, Administration, and Maintenance (OAM) and
Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13 Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 14
7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14 7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 15
8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15 8. Entropy Labels in Various Scenarios . . . . . . . . . . . . . 15
9. Entropy Labels in Various Scenarios . . . . . . . . . . . . . 15 8.1. LDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. LDP Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 16 8.2. LDP Over RSVP-TE . . . . . . . . . . . . . . . . . . . . . 18
9.2. LDP Over RSVP-TE . . . . . . . . . . . . . . . . . . . . . 18 8.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 18
9.3. MPLS Applications . . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 10.1. Reserved Label for ELI . . . . . . . . . . . . . . . . . . 19
11.1. Reserved Label for ELI . . . . . . . . . . . . . . . . . . 19 10.2. LDP Entropy Label Capability TLV . . . . . . . . . . . . . 19
11.2. LDP Entropy Label Capability TLV . . . . . . . . . . . . . 19 10.3. BGP Entropy Label Capability Attribute . . . . . . . . . . 20
11.3. BGP Entropy Label Capability Attribute . . . . . . . . . . 19 10.4. RSVP-TE Entropy Label Capability flag . . . . . . . . . . 20
11.4. RSVP-TE Entropy Label Capability flag . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . . 20 Appendix A. Applicability of LDP Entropy Label Capability TLV . . 22
Appendix A. Applicability of LDP Entropy Label Capability TLV . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Load balancing, or multi-pathing, is an attempt to balance traffic Load balancing, or multi-pathing, is an attempt to balance traffic
across a network by allowing the traffic to use multiple paths. Load across a network by allowing the traffic to use multiple paths. Load
balancing has several benefits: it eases capacity planning; it can balancing has several benefits: it eases capacity planning; it can
help absorb traffic surges by spreading them across multiple paths; help absorb traffic surges by spreading them across multiple paths;
it allows better resilience by offering alternate paths in the event it allows better resilience by offering alternate paths in the event
of a link or node failure. of a link or node failure.
skipping to change at page 9, line 21 skipping to change at page 9, line 21
MUST be able to distinguish unambiguously between entropy labels and MUST be able to distinguish unambiguously between entropy labels and
application labels. This is accomplished by REQUIRING that the label application labels. This is accomplished by REQUIRING that the label
immediately preceding an entropy label (EL) in the MPLS label stack immediately preceding an entropy label (EL) in the MPLS label stack
be an 'entropy label indicator' (ELI). The ELI is a reserved label be an 'entropy label indicator' (ELI). The ELI is a reserved label
with value (TBD by IANA). An ELI MUST have 'Bottom of Stack' (BoS) with value (TBD by IANA). An ELI MUST have 'Bottom of Stack' (BoS)
bit = 0 ([RFC3032]). The TTL SHOULD be set to whatever value the bit = 0 ([RFC3032]). The TTL SHOULD be set to whatever value the
label above it in the stack has. The CoS field can be set to any label above it in the stack has. The CoS field can be set to any
value deemed appropriate; typically, this will be the value in the value deemed appropriate; typically, this will be the value in the
label above the ELI in the label stack. label above the ELI in the label stack.
Entropy labels are useful for pseudowires ([RFC4447]). Entropy labels are useful for pseudowires ([RFC4447]). [RFC6391]
[I-D.ietf-pwe3-fat-pw] explains how entropy labels can be used for explains how entropy labels can be used for RFC 4447-style
RFC 4447-style pseudowires, and thus is complementary to this memo, pseudowires, and thus is complementary to this memo, which focuses on
which focuses on how entropy labels can be used for tunnels, and thus how entropy labels can be used for tunnels, and thus for all other
for all other MPLS applications. MPLS applications.
4. Data Plane Processing of Entropy Labels 4. Data Plane Processing of Entropy Labels
4.1. Egress LSR 4.1. Egress LSR
Suppose egress LSR Y is capable of processing entropy labels for a Suppose egress LSR Y is capable of processing entropy labels for a
tunnel. Y indicates this to all ingresses via signaling (see tunnel. Y indicates this to all ingresses via signaling (see
Section 5). Y MUST be prepared to deal both with packets with an Section 5). Y MUST be prepared to deal both with packets with an
imposed EL and those without; the ELI will distinguish these cases. imposed EL and those without; the ELI will distinguish these cases.
If a particular ingress chooses not to impose an EL, Y's processing If a particular ingress chooses not to impose an EL, Y's processing
skipping to change at page 12, line 4 skipping to change at page 12, line 4
5. Signaling for Entropy Labels 5. Signaling for Entropy Labels
An egress LSR Y can signal to ingress LSR(s) its ability to process An egress LSR Y can signal to ingress LSR(s) its ability to process
entropy labels (henceforth called "Entropy Label Capability" or ELC) entropy labels (henceforth called "Entropy Label Capability" or ELC)
on a given tunnel. Note that Entropy Label Capability may be on a given tunnel. Note that Entropy Label Capability may be
asymmetric: if LSRs X and Y are at opposite ends of a tunnel, X may asymmetric: if LSRs X and Y are at opposite ends of a tunnel, X may
be able to process entropy labels, whereas Y may not. The signaling be able to process entropy labels, whereas Y may not. The signaling
extensions below allow for this asymmetry. extensions below allow for this asymmetry.
For an illustration of signaling and forwarding with entropy labels, For an illustration of signaling and forwarding with entropy labels,
see Section 9. see Section 8.
5.1. LDP Signaling 5.1. LDP Signaling
A new LDP TLV ([RFC5036]) is defined to signal an egress's ability to A new LDP TLV ([RFC5036]) is defined to signal an egress's ability to
process entropy labels. This is called the ELC TLV, and may appear process entropy labels. This is called the ELC TLV, and may appear
as an Optional Parameter of the Label Mapping Message TLV. as an Optional Parameter of the Label Mapping Message TLV.
The presence of the ELC TLV in a Label Mapping Message indicates to The presence of the ELC TLV in a Label Mapping Message indicates to
ingress LSRs that the egress LSR can process entropy labels for the ingress LSRs that the egress LSR can process entropy labels for the
associated LDP tunnel. The ELC TLV has Type (TBD by IANA) and Length associated LDP tunnel. The ELC TLV has Type (TBD by IANA) and Length
skipping to change at page 12, line 29 skipping to change at page 12, line 29
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type (TBD) | Length (0) | |U|F| Type (TBD) | Length (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Entropy Label Capability TLV Figure 1: Entropy Label Capability TLV
where: where:
U: Unknown bit. This bit MUST be set to 1. If the Entropy Label U: Unknown bit. This bit MUST be set to 1. If the ELC TLV is not
Capability TLV is not understood, then the TLV is not known to the understood by the receiver, then it MUST be ignored.
receiver and MUST be ignored.
F: Forward bit. This bit MUST be set be set to 1. Since this F: Forward bit. This bit MUST be set be set to 1. Since the ELC
Capability TLV is going to be propagated hop-by-hop, the TLV TLV is going to be propagated hop-by-hop, it should be forwarded
should be forwarded even by nodes that may not understand it. even by nodes that may not understand it.
Type: Type field. To be assigned by IANA. Type: Type field. To be assigned by IANA.
Length: Length field. This field specifies the total length in Length: Length field. This field specifies the total length in
octets of the ELC TLV, and is currently defined to be 0. octets of the ELC TLV, and is currently defined to be 0.
5.1.1. Processing the ELC TLV
An LSR that receives a Label Mapping with the ELC TLV but does not
understand it MUST propagate it intact to its neighbors and MUST NOT
send a notification to the sender (following the meaning of the U-
and F-bits).
An LSR X may receive multiple Label Mappings for a given FEC F from
its neighbors. In its turn, X may advertise a Label Mapping for F to
its neighbors. If X understands the ELC TLV, and if any of the
advertisements it received for FEC F does not include the ELC TLV, X
MUST NOT include the ELC TLV in its own advertisements of F. If all
the advertised Mappings for F include the ELC TLV, then X MUST
advertise its Mapping for F with the ELC TLV. If any of X's
neighbors resends its Mapping, sends a new Mapping or Withdraws a
previously advertised Mapping for F, X MUST re-evaluate the status of
ELC for FEC F, and, if there is a change, X MUST re-advertise its
Mapping for F with the updated status of ELC.
5.2. BGP Signaling 5.2. BGP Signaling
When BGP [RFC4271] is used for distributing Network Layer When BGP [RFC4271] is used for distributing Network Layer
Reachability Information (NLRI) as described in, for example, Reachability Information (NLRI) as described in, for example,
[RFC3107], the BGP UPDATE message may include the ELC attribute as [RFC3107], the BGP UPDATE message may include the ELC attribute as
part of the Path Attributes. This is an optional, transitive BGP part of the Path Attributes. This is an optional, transitive BGP
attribute of type (to be assigned by IANA). The inclusion of this attribute of type (to be assigned by IANA). The inclusion of this
attribute with an NLRI indicates that the advertising BGP router can attribute with an NLRI indicates that the advertising BGP router can
process entropy labels as an egress LSR for all routes in that NLRI. process entropy labels as an egress LSR for all routes in that NLRI.
skipping to change at page 13, line 47 skipping to change at page 14, line 18
Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the Entropy Label Capability (ELC) flag in the Attribute Flags TLV of the
LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a LSP_ATTRIBUTES object [RFC5420]. The presence of the ELC flag in a
Path message indicates that the ingress can process entropy labels in Path message indicates that the ingress can process entropy labels in
the upstream direction; this only makes sense for a bidirectional LSP the upstream direction; this only makes sense for a bidirectional LSP
and MUST be ignored otherwise. The presence of the ELC flag in a and MUST be ignored otherwise. The presence of the ELC flag in a
Resv message indicates that the egress can process entropy labels in Resv message indicates that the egress can process entropy labels in
the downstream direction. the downstream direction.
The bit number for the ELC flag is to be assigned by IANA. The bit number for the ELC flag is to be assigned by IANA.
5.4. Multicast LSPs and Entropy Labels
Multicast LSPs [RFC4875], [RFC6388] typically do not use ECMP for
load balancing, as the combination of replication and multipathing
can lead to duplicate traffic delivery. However, these LSPs can
traverse bundled links [RFC4201] and LAGs. In both these cases, load
balancing is useful, and hence entropy labels can be of value for
multicast LSPs.
The methodology defined for entropy labels here will be used for
multicast LSPs; however, the details of signaling and processing ELs
for multicast LSPs will be specified in a companion document.
6. Operations, Administration, and Maintenance (OAM) and Entropy Labels 6. Operations, Administration, and Maintenance (OAM) and Entropy Labels
Generally OAM comprises a set of functions operating in the data Generally OAM comprises a set of functions operating in the data
plane to allow a network operator to monitor its network plane to allow a network operator to monitor its network
infrastructure and to implement mechanisms in order to enhance the infrastructure and to implement mechanisms in order to enhance the
general behavior and the level of performance of its network, e.g., general behavior and the level of performance of its network, e.g.,
the efficient and automatic detection, localization, diagnosis and the efficient and automatic detection, localization, diagnosis and
handling of defects. handling of defects.
Currently defined OAM mechanisms for MPLS include LSP Ping/Traceroute Currently defined OAM mechanisms for MPLS include LSP Ping/Traceroute
skipping to change at page 15, line 5 skipping to change at page 15, line 33
In order to have a BFD session on a given path, a value from the In order to have a BFD session on a given path, a value from the
label range for that path should be used as the EL value for BFD label range for that path should be used as the EL value for BFD
packets sent on that path. packets sent on that path.
7. MPLS-TP and Entropy Labels 7. MPLS-TP and Entropy Labels
Since MPLS-TP does not use ECMP, entropy labels are not applicable to Since MPLS-TP does not use ECMP, entropy labels are not applicable to
an MPLS-TP deployment. an MPLS-TP deployment.
8. Point-to-Multipoint LSPs and Entropy Labels 8. Entropy Labels in Various Scenarios
Point-to-Multipoint (P2MP) LSPs [RFC4875] typically do not use ECMP
for load balancing, as the combination of replication and
multipathing can lead to duplicate traffic delivery. However, P2MP
LSPs can traverse bundled links [RFC4201] and LAGs. In both these
cases, load balancing is useful, and hence entropy labels can be of
value for P2MP LSPs.
There is a potential complication with the use of entropy labels in
the context of P2MP LSPs, a consequence of the fact that the entire
label stack below the P2MP label must be the same for all egress
LSRs. This is that all egress LSRs must be willing to receive
entropy labels; if even one egress LSR is not willing, then entropy
labels MUST NOT be used for this P2MP LSP.
In this regard, the ingress LSR MUST keep track of the ability of
each egress LSR to process entropy labels, especially since the set
of egress LSRs of a given P2MP LSP may change over time. Whenever an
existing egress LSR leaves, or a new egress LSR joins the P2MP LSP,
the ingress MUST re-evaluate whether or not to include entropy labels
for the P2MP LSP.
In some cases, it may be feasible to deploy two P2MP LSPs, one to ELC
egress LSRs, and the other to the remaining non-ELC egress LSRs.
However, this requires more state in the network, more bandwidth, and
more operational overhead (tracking ELC LSRs, and provisioning P2MP
LSPs accordingly). Alternatively, an ingress LSR may choose to
signal two separate P2MP LSPs, one to ELC egresses, the other to non-
ELC egresses, trading off implementation complexity for operational
complexity.
9. Entropy Labels in Various Scenarios
This section describes the use of entropy labels in various This section describes the use of entropy labels in various
scenarios. scenarios.
In the figures below, the following conventions used to depict In the figures below, the following conventions used to depict
processing between X and Y. Note that control plane signaling goes processing between X and Y. Note that control plane signaling goes
right to left, whereas data plane processing goes left to right. right to left, whereas data plane processing goes left to right.
Protocols Protocols
Y: <--- [L, E] Y signals L to X Y: <--- [L, E] Y signals L to X
skipping to change at page 16, line 4 skipping to change at page 15, line 48
In the figures below, the following conventions used to depict In the figures below, the following conventions used to depict
processing between X and Y. Note that control plane signaling goes processing between X and Y. Note that control plane signaling goes
right to left, whereas data plane processing goes left to right. right to left, whereas data plane processing goes left to right.
Protocols Protocols
Y: <--- [L, E] Y signals L to X Y: <--- [L, E] Y signals L to X
X ------------- Y X ------------- Y
LS: <L, ELI, EL> Label stack LS: <L, ELI, EL> Label stack
X: +<L, ELI, EL> X pushes <L, ELI, EL> X: +<L, ELI, EL> X pushes <L, ELI, EL>
Y: -<L, ELI, EL> Y pops <L, ELI, EL> Y: -<L, ELI, EL> Y pops <L, ELI, EL>
This means that Y signals to X label L for an LDP tunnel. E can be This means that Y signals to X label L for an LDP tunnel. E can be
one of: one of:
0: meaning egress is NOT entropy label capable, or 0: meaning egress is NOT entropy label capable, or
1: meaning egress is entropy label capable. 1: meaning egress is entropy label capable.
The line with LS: shows the label stack on the wire. Below that is The line with LS: shows the label stack on the wire. Below that is
the operation that each LSR does in the data plane, where + means the operation that each LSR does in the data plane, where + means
push the following label stack, - means pop the following label push the following label stack, - means pop the following label
stack, L~L' means swap L with L', and * means that the operation is stack, L~L' means swap L with L', and * means that the operation is
not depicted. not depicted.
9.1. LDP Tunnel 8.1. LDP Tunnel
The following illustrates several simple intra-AS LDP tunnels. The The following illustrates several simple intra-AS LDP tunnels. The
first diagram shows ultimate hop popping (UHP) with ingress inserting first diagram shows ultimate hop popping (UHP) with ingress inserting
an EL, the second UHP with no ELs, the third PHP with ELs, and an EL, the second UHP with no ELs, the third PHP with ELs, and
finally, PHP with no ELs, but also with an application label AL finally, PHP with no ELs, but also with an application label AL
(which could, for example, be a VPN label). (which could, for example, be a VPN label).
Note that, in all the cases below, the MPLS application does not Note that, in all the cases below, the MPLS application does not
matter; it may be that X pushes some more labels (perhaps for a VPN matter; it may be that X pushes some more labels (perhaps for a VPN
or VPLS) below the ones shown, and Y pops them. or VPLS) below the ones shown, and Y pops them.
skipping to change at page 18, line 6 skipping to change at page 18, line 6
X --------------- A --------- B ... W ---------- Y X --------------- A --------- B ... W ---------- Y
LS: <TL4, AL> <TL3, AL> <AL> LS: <TL4, AL> <TL3, AL> <AL>
X: +<TL4, AL> X: +<TL4, AL>
A: TL4~TL3 A: TL4~TL3
B: TL3~TL2 B: TL3~TL2
... ...
W: -TL1 W: -TL1
Y: -<AL> Y: -<AL>
LDP with PHP + VPN; ingress does not insert ELs LDP with PHP + VPN; ingress does not insert ELs
9.2. LDP Over RSVP-TE A: <--- [TL4, 1]
B: <-- [TL3, 1]
...
W: <-- [TL1, 1]
Y: <-- [3, 1]
VPN: <--------------------------------------------- [AL]
X --------------- A ------------ B ... W ---------- Y
LS: <TL4,ELI,EL,AL> <TL3,ELI,EL,AL> <ELI,EL,AL>
X: +<TL4,ELI,EL,AL>
A: TL4~TL3
B: TL3~TL2
...
W: -TL1
Y: -<ELI,EL,AL>
LDP with PHP + VPN; ingress inserts ELs
8.2. LDP Over RSVP-TE
The following illustrates "LDP over RSVP-TE" tunnels. X and Y are The following illustrates "LDP over RSVP-TE" tunnels. X and Y are
the ingress and egress (respectively) of the LDP tunnel; A and W are the ingress and egress (respectively) of the LDP tunnel; A and W are
the ingress and egress of the RSVP-TE tunnel. It is assumed that the ingress and egress of the RSVP-TE tunnel. It is assumed that
both the LDP and RSVP-TE tunnels have PHP. both the LDP and RSVP-TE tunnels have PHP.
LDP with ELs, RSVP-TE without ELs LDP with ELs, RSVP-TE without ELs
LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1] LDP: <--- [L4, 1] <------- [L3, 1] <--- [3, 1]
RSVP-TE: <-- [Rn, 0] RSVP-TE: <-- [Rn, 0]
<-- [3, 0] <-- [3, 0]
X --------------- A --------- B ... W ---------- Y X --------------- A --------- B ... W ---------- Y
LS: <L4, ELI, EL> <Rn,L3,ELI,EL> ... <ELI, EL> LS: <L4, ELI, EL> <Rn,L3,ELI,EL> ... <ELI, EL>
DP: +<L4, ELI, EL> L4~<Rn, L3> * -L1 -<ELI, EL> DP: +<L4, ELI, EL> L4~<Rn, L3> * -L1 -<ELI, EL>
Figure 2: LDP over RSVP-TE Tunnels Figure 2: LDP over RSVP-TE Tunnels
9.3. MPLS Applications 8.3. MPLS Applications
An ingress LSR X must keep state per unicast tunnel as to whether the An ingress LSR X must keep state per unicast tunnel as to whether the
egress for that tunnel can process entropy labels. X does not have egress for that tunnel can process entropy labels. X does not have
to keep state per application running over that tunnel. However, an to keep state per application running over that tunnel. However, an
ingress PE can choose on a per-application basis whether or not to ingress PE can choose on a per-application basis whether or not to
insert ELs. For example, X may have an application for which it does insert ELs. For example, X may have an application for which it does
not wish to use ECMP (e.g., circuit emulation), or for which it does not wish to use ECMP (e.g., circuit emulation), or for which it does
not know which keys to use for load balancing (e.g., Appletalk over a not know which keys to use for load balancing (e.g., Appletalk over a
pseudowire). In either of those cases, X may choose not to insert pseudowire). In either of those cases, X may choose not to insert
entropy labels, but may choose to insert entropy labels for an IP VPN entropy labels, but may choose to insert entropy labels for an IP VPN
over the same tunnel. over the same tunnel.
10. Security Considerations 9. Security Considerations
This document describes advertisement of the capability to support This document describes advertisement of the capability to support
receipt of entropy labels which an ingress LSR may insert in MPLS receipt of entropy labels which an ingress LSR may insert in MPLS
packets in order to allow transit LSRs to attain better load packets in order to allow transit LSRs to attain better load
balancing across LAG and/or ECMP paths in the network. balancing across LAG and/or ECMP paths in the network.
This document does not introduce new security vulnerabilities to LDP, This document does not introduce new security vulnerabilities to LDP,
BGP or RSVP-TE. Please refer to the Security Considerations section BGP or RSVP-TE. Please refer to the Security Considerations section
of these protocols ([RFC5036], [RFC4271] and [RFC3209]) for security of these protocols ([RFC5036], [RFC4271] and [RFC3209]) for security
mechanisms applicable to each. mechanisms applicable to each.
skipping to change at page 19, line 17 skipping to change at page 19, line 34
the egress PE, then the PE will fall back to not using entropy labels the egress PE, then the PE will fall back to not using entropy labels
for load-balancing traffic over LAG or ECMP paths which is in general for load-balancing traffic over LAG or ECMP paths which is in general
no worse than the behavior observed in current production networks. no worse than the behavior observed in current production networks.
That said, it is recommended that operators monitor changes to PE That said, it is recommended that operators monitor changes to PE
configurations and, more importantly, the fairness of load configurations and, more importantly, the fairness of load
distribution over LAG or ECMP paths. If the fairness of load distribution over LAG or ECMP paths. If the fairness of load
distribution over a set of paths changes that could indicate a distribution over a set of paths changes that could indicate a
misconfiguration, bug or other non-optimal behavior on their PEs and misconfiguration, bug or other non-optimal behavior on their PEs and
they should take corrective action. they should take corrective action.
11. IANA Considerations 10. IANA Considerations
11.1. Reserved Label for ELI 10.1. Reserved Label for ELI
IANA is requested to allocate a reserved label for the Entropy Label IANA is requested to allocate a reserved label for the Entropy Label
Indicator (ELI) from the "Multiprotocol Label Switching Architecture Indicator (ELI) from the "Multiprotocol Label Switching Architecture
(MPLS) Label Values" Registry. (MPLS) Label Values" Registry.
11.2. LDP Entropy Label Capability TLV 10.2. LDP Entropy Label Capability TLV
IANA is requested to allocate the next available value from the IETF IANA is requested to allocate the next available value from the IETF
Consensus range in the LDP TLV Type Name Space Registry as the Consensus range in the LDP TLV Type Name Space Registry as the
"Entropy Label Capability TLV". "Entropy Label Capability TLV".
11.3. BGP Entropy Label Capability Attribute 10.3. BGP Entropy Label Capability Attribute
IANA is requested to allocate the next available Path Attribute Type IANA is requested to allocate the next available Path Attribute Type
Code from the "BGP Path Attributes" registry as the "BGP Entropy Code from the "BGP Path Attributes" registry as the "BGP Entropy
Label Capability Attribute". Label Capability Attribute".
11.4. RSVP-TE Entropy Label Capability flag 10.4. RSVP-TE Entropy Label Capability flag
IANA is requested to allocate a new bit from the "Attribute Flags" IANA is requested to allocate a new bit from the "Attribute Flags"
sub-registry of the "RSVP TE Parameters" registry. sub-registry of the "RSVP TE Parameters" registry.
Bit | Name | Attribute | Attribute | RRO Bit | Name | Attribute | Attribute | RRO
No | | Flags Path | Flags Resv | No | | Flags Path | Flags Resv |
----+--------------------------+------------+------------+----- ----+--------------------------+------------+------------+-----
TBD Entropy Label Capability Yes Yes No TBD Entropy Label Capability Yes Yes No
12. Acknowledgments 11. Acknowledgments
We wish to thank Ulrich Drafz for his contributions, as well as the We wish to thank Ulrich Drafz for his contributions, as well as the
entire 'hash label' team for their valuable comments and discussion. entire 'hash label' team for their valuable comments and discussion.
Sincere thanks to Nischal Sheth for his many suggestions and Sincere thanks to Nischal Sheth for his many suggestions and
comments, and his careful reading of the document, especially with comments, and his careful reading of the document, especially with
regard to data plane processing of entropy labels. regard to data plane processing of entropy labels.
13. References 12. References
13.1. Normative References 12.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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, January 2001. Encoding", RFC 3032, January 2001.
[RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001. BGP-4", RFC 3107, May 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A.
Ayyangarps, "Encoding of Attributes for MPLS LSP Ayyangar, "Encoding of Attributes for MPLS LSP
Establishment Using Resource Reservation Protocol Traffic Establishment Using Resource Reservation Protocol Traffic
Engineering (RSVP-TE)", RFC 5420, February 2009. Engineering (RSVP-TE)", RFC 5420, February 2009.
13.2. Informative References 12.2. Informative References
[I-D.ietf-pwe3-fat-pw]
Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow Aware Transport of Pseudowires
over an MPLS Packet Switched Network",
draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011.
[RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006. Networks (VPNs)", RFC 4364, February 2006.
skipping to change at page 21, line 27 skipping to change at page 21, line 42
[RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service
(VPLS) Using Label Distribution Protocol (LDP) Signaling", (VPLS) Using Label Distribution Protocol (LDP) Signaling",
RFC 4762, January 2007. RFC 4762, January 2007.
[RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to Resource Reservation Protocol - Traffic "Extensions to Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) for Point-to-Multipoint TE Label Engineering (RSVP-TE) for Point-to-Multipoint TE Label
Switched Paths (LSPs)", RFC 4875, May 2007. Switched Paths (LSPs)", RFC 4875, May 2007.
[RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP
Specification", RFC 5036, October 2007.
[RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic
Associated Channel", RFC 5586, June 2009.
[RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow,
"Bidirectional Forwarding Detection (BFD) for MPLS Label "Bidirectional Forwarding Detection (BFD) for MPLS Label
Switched Paths (LSPs)", RFC 5884, June 2010. Switched Paths (LSPs)", RFC 5884, June 2010.
[RFC6388] Wijnands, IJ., Minei, I., Kompella, K., and B. Thomas,
"Label Distribution Protocol Extensions for Point-to-
Multipoint and Multipoint-to-Multipoint Label Switched
Paths", RFC 6388, November 2011.
[RFC6391] Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan,
J., and S. Amante, "Flow-Aware Transport of Pseudowires
over an MPLS Packet Switched Network", RFC 6391,
November 2011.
Appendix A. Applicability of LDP Entropy Label Capability TLV Appendix A. Applicability of LDP Entropy Label Capability TLV
In the case of unlabeled IPv4 (Internet) traffic, the Best Current In the case of unlabeled IPv4 (Internet) traffic, the Best Current
Practice is for an egress LSR to propagate eBGP learned routes within Practice is for an egress LSR to propagate eBGP learned routes within
a SP's Autonomous System after resetting the BGP next-hop attribute a SP's Autonomous System after resetting the BGP next-hop attribute
to one of its Loopback IP addresses. That Loopback IP address is to one of its Loopback IP addresses. That Loopback IP address is
injected into the Service Provider's IGP and, concurrently, a label injected into the Service Provider's IGP and, concurrently, a label
assigned to it via LDP. Thus, when an ingress LSR is performing a assigned to it via LDP. Thus, when an ingress LSR is performing a
forwarding lookup for a BGP destination it recursively resolves the forwarding lookup for a BGP destination it recursively resolves the
associated next-hop to a Loopback IP address and associated LDP label associated next-hop to a Loopback IP address and associated LDP label
 End of changes. 32 change blocks. 
96 lines changed or deleted 115 lines changed or added

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