idnits 2.17.1 draft-ietf-mpls-entropy-label-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3031, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC3031, updated by this document, for RFC5378 checks: 1998-03-17) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4559 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TL0' is mentioned on line 936, but not defined == Missing Reference: 'E' is mentioned on line 936, but not defined == Missing Reference: 'AL' is mentioned on line 758, but not defined == Missing Reference: 'TL1' is mentioned on line 759, but not defined == Missing Reference: '-' is mentioned on line 803, but not defined == Missing Reference: 'VL' is mentioned on line 858, but not defined -- Looks like a reference, but probably isn't: '0' on line 938 == Missing Reference: 'SL1' is mentioned on line 801, but not defined == Missing Reference: 'HL' is mentioned on line 802, but not defined == Missing Reference: 'SL2' is mentioned on line 803, but not defined == Missing Reference: 'CL' is mentioned on line 859, but not defined == Missing Reference: 'PL1' is mentioned on line 937, but not defined == Missing Reference: 'PL2' is mentioned on line 938, but not defined ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft J. Drake 4 Updates: 3031 (if approved) Juniper Networks 5 Intended status: Standards Track S. Amante 6 Expires: May 3, 2012 Level 3 Communications, LLC 7 W. Henderickx 8 Alcatel-Lucent 9 L. Yong 10 Huawei USA 11 October 31, 2011 13 The Use of Entropy Labels in MPLS Forwarding 14 draft-ietf-mpls-entropy-label-01 16 Abstract 18 Load balancing is a powerful tool for engineering traffic across a 19 network. This memo suggests ways of improving load balancing across 20 MPLS networks using the concept of "entropy labels". It defines the 21 concept, describes why entropy labels are useful, enumerates 22 properties of entropy labels that allow maximal benefit, and shows 23 how they can be signaled and used for various applications. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2012. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions used . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Entropy Labels and Their Structure . . . . . . . . . . . . . . 7 64 4. Data Plane Processing of Entropy Labels . . . . . . . . . . . 8 65 4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3. Egress LSR . . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 10 69 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 10 70 5.2. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 11 71 5.3. RSVP-TE Signaling . . . . . . . . . . . . . . . . . . . . 12 72 6. Operations, Administration, and Maintenance (OAM) and 73 Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 13 74 7. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 14 75 8. Point-to-Multipoint LSPs and Entropy Labels . . . . . . . . . 15 76 9. Entropy Labels and Applications . . . . . . . . . . . . . . . 15 77 9.1. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 9.2. LDP Pseudowires . . . . . . . . . . . . . . . . . . . . . 17 79 9.3. BGP Applications . . . . . . . . . . . . . . . . . . . . . 18 80 9.3.1. Inter-AS BGP VPNs . . . . . . . . . . . . . . . . . . 19 81 9.4. Multiple Applications . . . . . . . . . . . . . . . . . . 20 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 84 11.1. LDP Entropy Label TLV . . . . . . . . . . . . . . . . . . 22 85 11.2. BGP Entropy Label Attribute . . . . . . . . . . . . . . . 22 86 11.3. Attribute Flags for LSP_Attributes Object . . . . . . . . 22 87 11.4. Attributes TLV for LSP_Attributes Object . . . . . . . . . 22 88 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 89 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 13.1. Normative References . . . . . . . . . . . . . . . . . . . 23 91 13.2. Informative References . . . . . . . . . . . . . . . . . . 23 92 Appendix A. Applicability of LDP Entropy Label sub-TLV . . . . . 24 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 95 1. Introduction 97 Load balancing, or multi-pathing, is an attempt to balance traffic 98 across a network by allowing the traffic to use multiple paths. Load 99 balancing has several benefits: it eases capacity planning; it can 100 help absorb traffic surges by spreading them across multiple paths; 101 it allows better resilience by offering alternate paths in the event 102 of a link or node failure. 104 As providers scale their networks, they use several techniques to 105 achieve greater bandwidth between nodes. Two widely used techniques 106 are: Link Aggregation Group (LAG) and Equal-Cost Multi-Path (ECMP). 107 LAG is used to bond together several physical circuits between two 108 adjacent nodes so they appear to higher-layer protocols as a single, 109 higher bandwidth 'virtual' pipe. ECMP is used between two nodes 110 separated by one or more hops, to allow load balancing over several 111 shortest paths in the network. This is typically obtained by 112 arranging IGP metrics such that there are several equal cost paths 113 between source-destination pairs. Both of these techniques may, and 114 often do, co-exist in various parts of a given provider's network, 115 depending on various choices made by the provider. 117 A very important requirement when load balancing is that packets 118 belonging to a given 'flow' must be mapped to the same path, i.e., 119 the same exact sequence of links across the network. This is to 120 avoid jitter, latency and re-ordering issues for the flow. What 121 constitutes a flow varies considerably. A common example of a flow 122 is a TCP session. Other examples are an L2TP session corresponding 123 to a given broadband user, or traffic within an ATM virtual circuit. 125 To meet this requirement, a node uses certain fields, termed 'keys', 126 within a packet's header as input to a load balancing function 127 (typically a hash function) that selects the path for all packets in 128 a given flow. The keys chosen for the load balancing function depend 129 on the packet type; a typical set (for IP packets) is the IP source 130 and destination addresses, the protocol type, and (for TCP and UDP 131 traffic) the source and destination port numbers. An overly 132 conservative choice of fields may lead to many flows mapping to the 133 same hash value (and consequently poorer load balancing); an overly 134 aggressive choice may map a flow to multiple values, potentially 135 violating the above requirement. 137 For MPLS networks, most of the same principles (and benefits) apply. 138 However, finding useful keys in a packet for the purpose of load 139 balancing can be more of a challenge. In many cases, MPLS 140 encapsulation may require fairly deep inspection of packets to find 141 these keys at transit LSRs. 143 One way to eliminate the need for this deep inspection is to have the 144 ingress LSR of an MPLS Label Switched Path extract the appropriate 145 keys from a given packet, input them to its load balancing function, 146 and place the result in an additional label, termed the 'entropy 147 label', as part of the MPLS label stack it pushes onto that packet. 149 The packet's MPLS entire label stack can then be used by transit LSRs 150 to perform load balancing, as the entropy label introduces the right 151 level of "entropy" into the label stack. 153 There are four key reasons why this is beneficial: 155 1. at the ingress LSR, MPLS encapsulation hasn't yet occurred, so 156 deep inspection is not necessary; 158 2. the ingress LSR has more context and information about incoming 159 packets than transit LSRs; 161 3. ingress LSRs usually operate at lower bandwidths than transit 162 LSRs, allowing them to do more work per packet, and 164 4. transit LSRs do not need to perform deep packet inspection and 165 can load balance effectively using only a packet's MPLS label 166 stack. 168 This memo describes why entropy labels are needed and defines the 169 properties of entropy labels; in particular how they are generated 170 and received, and the expected behavior of transit LSRs. Finally, it 171 describes in general how signaling works and what needs to be 172 signaled, as well as specifics for the signaling of entropy labels 173 for LDP ([RFC5036]), BGP ([RFC3107], [RFC4364]), and RSVP-TE 174 ([RFC3209]). 176 1.1. Conventions used 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 180 document are to be interpreted as described in [RFC2119]. 182 The following acronyms are used: 184 LSR: Label Switching Router; 186 LER: Label Edge Router; 188 PE: Provider Edge router; 189 CE: Customer Edge device; and 191 FEC: Forwarding Equivalence Class. 193 The term ingress (or egress) LSR is used interchangeably with ingress 194 (or egress) LER. The term application throughout the text refers to 195 an MPLS application (such as a VPN or VPLS). 197 A label stack (say of three labels) is denoted by , where 198 L1 is the "outermost" label and L3 the innermost (closest to the 199 payload). Packet flows are depicted left to right, and signaling is 200 shown right to left (unless otherwise indicated). 202 The term 'label' is used both for the entire 32-bit label and the 20- 203 bit label field within a label. It should be clear from the context 204 which is meant. 206 1.2. Motivation 208 MPLS is very successful generic forwarding substrate that transports 209 several dozen types of protocols, most notably: IP, PWE3, VPLS and IP 210 VPNs. Within each type of protocol, there typically exist several 211 variants, each with a different set of load balancing keys, e.g., for 212 IP: IPv4, IPv6, IPv6 in IPv4, etc.; for PWE3: Ethernet, ATM, Frame- 213 Relay, etc. There are also several different types of Ethernet over 214 PW encapsulation, ATM over PW encapsulation, etc. as well. Finally, 215 given the popularity of MPLS, it is likely that it will continue to 216 be extended to transport new protocols. 218 Currently, each transit LSR along the path of a given LSP has to try 219 to infer the underlying protocol within an MPLS packet in order to 220 extract appropriate keys for load balancing. Unfortunately, if the 221 transit LSR is unable to infer the MPLS packet's protocol (as is 222 often the case), it will typically use the topmost (or all) MPLS 223 labels in the label stack as keys for the load balancing function. 224 The result may be an extremely inequitable distribution of traffic 225 across equal-cost paths exiting that LSR. This is because MPLS 226 labels are generally fairly coarse-grained forwarding labels that 227 typically describe a next-hop, or provide some of demultiplexing 228 and/or forwarding function, and do not describe the packet's 229 underlying protocol. 231 On the other hand, an ingress LSR (e.g., a PE router) has detailed 232 knowledge of an packet's contents, typically through a priori 233 configuration of the encapsulation(s) that are expected at a given 234 PE-CE interface, (e.g., IPv4, IPv6, VPLS, etc.). They also have more 235 flexible forwarding hardware. PE routers need this information and 236 these capabilities to: 238 a) apply the required services for the CE; 240 b) discern the packet's CoS forwarding treatment; 242 c) apply filters to forward or block traffic to/from the CE; 244 d) to forward routing/control traffic to an onboard management 245 processor; and, 247 e) load-balance the traffic on its uplinks to transit LSRs (e.g., 248 P routers). 250 By knowing the expected encapsulation types, an ingress LSR router 251 can apply a more specific set of payload parsing routines to extract 252 the keys appropriate for a given protocol. This allows for 253 significantly improved accuracy in determining the appropriate load 254 balancing behavior for each protocol. 256 If the ingress LSR were to capture the flow information so gathered 257 in a convenient form for downstream transit LSRs, transit LSRs could 258 remain completely oblivious to the contents of each MPLS packet, and 259 use only the captured flow information to perform load balancing. In 260 particular, there will be no reason to duplicate an ingress LSR's 261 complex packet/payload parsing functionality in a transit LSR. This 262 will result in less complex transit LSRs, enabling them to more 263 easily scale to higher forwarding rates, larger port density, lower 264 power consumption, etc. The idea in this memo is to capture this 265 flow information as a label, the so-called entropy label. 267 Ingress LSRs can also adapt more readily to new protocols and extract 268 the appropriate keys to use for load balancing packets of those 269 protocols. This means that deploying new protocols or services in 270 edge devices requires fewer concommitant changes in the core, 271 resulting in higher edge service velocity and at the same time more 272 stable core networks. 274 2. Approaches 276 There are two main approaches to encoding load balancing information 277 in the label stack. The first allocates multiple labels for a 278 particular Forwarding Equivalance Class (FEC). These labels are 279 equivalent in terms of forwarding semantics, but having multiple 280 labels allows flexibility in assigning labels to flows belonging to 281 the same FEC. This approach has the advantage that the label stack 282 has the same depth whether or not one uses label-based load 283 balancing; and so, consequently, there is no change to forwarding 284 operations on transit and egress LSRs. However, it has a major 285 drawback in that there is a significant increase in both signaling 286 and forwarding state. 288 The other approach encodes the load balancing information as an 289 additional label in the label stack, thus increasing the depth of the 290 label stack by one. With this approach, there is minimal change to 291 signaling state for a FEC; also, there is no change in forwarding 292 operations in transit LSRs, and no increase of forwarding state in 293 any LSR. The only purpose of the additional label is to increase the 294 entropy in the label stack, so this is called an "entropy label". 295 This memo focuses solely on this approach. 297 3. Entropy Labels and Their Structure 299 An entropy label (as used here) is a label: 301 1. that is not used for forwarding; 303 2. that is not signaled; and 305 3. whose only purpose in the label stack is to provide 'entropy' to 306 improve load balancing. 308 Entropy labels are generated by an ingress LSR, based entirely on 309 load balancing information. However, they MUST NOT have values in 310 the reserved label space (0-15). To ensure that they are not used 311 inadvertently for forwarding, entropy labels SHOULD have a TTL of 0. 312 The CoS field of an entropy label can be set to any value deemed 313 appropriate. 315 Since entropy labels are generated by an ingress LSR, an egress LSR 316 MUST be able to tell unambiguously that a given label is an entropy 317 label. If any ambiguity is possible, the label above the entropy 318 label MUST be an 'entropy label indicator' (ELI), which indicates 319 that the following Label is an entropy label. An ELI is typically 320 signaled by an egress LSR and is added to the MPLS label stack along 321 with an entropy label by an ingress LSR. For many applications, the 322 use of entropy labels is unambiguous, and an ELI is not needed. An 323 ELI MUST have 'Bottom of Stack' (S) bit = 0 ([RFC3032]). The TTL 324 SHOULD be set to whatever value the label above it in the stack has. 325 The CoS field can be set to any value deemed appropriate; typically, 326 this will be the value in the label above it in the stack. 328 Applications for MPLS entropy labels include pseudowires ([RFC4447]), 329 Layer 3 VPNs ([RFC4364]), VPLS ([RFC4761], [RFC4762]) and Tunnel LSPs 330 carrying, say, IP traffic. [I-D.ietf-pwe3-fat-pw] explains how 331 entropy labels can be used for RFC 4447-style pseudowires, and thus 332 is complementary to this memo, which focuses on several other 333 applications of entropy labels. 335 4. Data Plane Processing of Entropy Labels 337 4.1. Ingress LSR 339 Suppose that for a particular application (or service or FEC), an 340 ingress LSR X is to push label stack , where TL is the 341 'tunnel label' and AL is the 'application label'. (Note the use of 342 the convention for label stacks described in Section 1.1. The use of 343 a two-label stack is just for illustrative purposes.) Suppose 344 furthermore that the egress LSR Y has told X that it is capable of 345 processing entropy labels for this application. If X cannot insert 346 entropy labels, it simply uses a label stack of for this 347 application. If X can insert entropy labels, it does the following 348 for an incoming packet: 350 1. X identifies the application to which the packet belongs, 351 identifies the egress LSR as Y, and thereby picks the outgoing 352 label stack to push onto the packet to send to Y. 354 2. X determines which keys that it will use for load balancing. 356 3. X, having kept state that Y can process entropy labels for this 357 application, generates an entropy label EL (based on the output 358 of the load balancing function). 360 4. If Y does not need an ELI, X pushes onto the packet 361 before forwarding it to the next hop to Y. 363 5. If Y requires an ELI, X pushes onto the packet 364 before forwarding it to the next hop to Y, where E is a label 365 whose 20-bit label field is the ELI that Y signaled, and whose 366 other fields are set as per Section 3. 368 Note that ingress LSR X MUST NOT include an entropy label unless the 369 egress LSR Y for this application has indicated that it is ready to 370 receive entropy labels. Furthermore, if Y has signaled that an ELI 371 is needed, then X MUST include the ELI before the entropy label. 373 Note that the signaling and use of entropy labels in one direction 374 (signaling from Y to X, and data path from X to Y) has no bearing on 375 the behavior in the opposite direction (signaling from X to Y, and 376 data path from Y to X). 378 4.2. Transit LSR 380 Transit LSRs have virtually no change in forwarding behavior. For 381 load balancing, transit LSRs SHOULD use the whole label stack as keys 382 for the load balancing function. Transit LSRs MUST NOT include 383 reserved labels as input to its load balancing function. Transit 384 LSRs MAY choose to look beyond the label stack for further keys; 385 however, if entropy labels are being used, this may not be very 386 useful. Looking beyond the label stack may be the simplest approach 387 in an environment where some ingress LSRs use entropy labels and 388 others don't, or for backward compatibility. Thus, other than using 389 the full label stack as input to the load balancing function, transit 390 LSRs are almost unaffected by the use of entropy labels. 392 4.3. Egress LSR 394 Suppose egress LSR Y signals that it is capable of processing entropy 395 labels for a tunnel or an application with label L. There are three 396 cases of interest: (a) L is the implicit NULL label, in which case an 397 ELI is mandatory; (b) L is not the implicit NULL label and an ELI is 398 not required (L's S bit will be used to determine whether or not 399 there is an EL); and (c) L is not the implicit NULL label but an ELI 400 is required. 402 a1) Y receives an unlabeled packet. There is obviously no EL; Y 403 processes the packet as usual. 405 a2) Y receives a packet whose top label is the ELI. Y processes the 406 TTL and CoS fields of the ELI label, ensures that the S bit is 0, 407 then pops it, and pops the next label as well (which must be the 408 EL), then pops it. Y processes the remaining payload as usual. 410 b) Y receives a packet with top label L, and an ELI is not required. 411 Y processes L as usual; if L's S bit is 1, the label stack is 412 done. If L's S bit is 0, the following label is the EL. Y pops 413 the EL. Y processes the payload as usual. 415 c) Y receives a packet with top label L. Y processes L as usual; if 416 L's S bit is 1, the label stack is done. If L's S bit is 0, Y 417 checks the following label. If it is the ELI label, Y processes 418 the TTL and CoS fields of the ELI, ensures that the S bit is 0, 419 pops the ELI label and the following label (which is the EL), and 420 processes the remaining payload as usual. 422 If there is an ELI with S bit = 1, there is an error in the label 423 stack. Note that the TTL field of the EL (if present) will be 0; Y 424 MUST NOT react to this. 426 5. Signaling for Entropy Labels 428 An egress LSR Y may signal to ingress LSR(s) its ability to process 429 entropy labels on a per-application (or per-FEC) basis. As part of 430 this signaling, Y also signals the ELI to use, if any. 432 In cases where an application label is used and must be the 433 bottommost label in the label stack, Y MAY signal that no ELI is 434 needed for that application. 436 In cases where no application label exists, or where the application 437 label may not be the bottommost label in the label stack, Y MUST 438 signal a valid ELI to be used in conjunction with the entropy label 439 for this FEC. In this case, an ingress LSR will either not add an 440 entropy label, or push the ELI before the entropy label. This makes 441 the use or non-use of an entropy label by the ingress LSR 442 unambiguous. Valid ELI label values are strictly greater than 15. 444 It should be noted that egress LSR Y may use the same ELI value for 445 all applications for which an ELI is needed. The ELI MUST be a label 446 that does not conflict with any other labels that Y has advertised to 447 other LSRs for other applications. Furthermore, it should be noted 448 that the ability to process entropy labels (and the corresponding 449 ELI) may be asymmetric: an LSR X may be willing to process entropy 450 labels, whereas LSR Y may not be willing to process entropy labels. 451 The signaling extensions below allow for this asymmetry. 453 For an illustration of signaling and forwarding with entropy labels, 454 see Figure 9. 456 5.1. LDP Signaling 458 When using LDP for signaling tunnel labels ([RFC5036]), a Label 459 Mapping Message sub-TLV (Entropy Label sub-TLV) is used to signal an 460 egress LSR's ability to process entropy labels. 462 The presence of the Entropy Label sub-TLV in the Label Mapping 463 Message indicates to ingress LSRs that the egress LSR can process an 464 entropy label. In addition, the Entropy Label sub-TLV contains a 465 label value for the ELI. If the ELI is zero, this indicates the 466 egress doesn't need an ELI for the signaled application; if not, the 467 egress requires the given ELI with entropy labels. An example where 468 an ELI is needed is when the signaled application is an LSP that can 469 carry IP traffic. 471 The structure of the Entropy Label sub-TLV is shown below. 473 0 1 2 3 474 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 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 |U|F| Type (TBD) | Length (8) | 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Value | Must Be Zero | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 1: Entropy Label sub-TLV 483 where: 485 U: Unknown bit. This bit MUST be set to 1. If the Entropy Label 486 sub-TLV is not understood, then the TLV is not known to the 487 receiver and MUST be ignored. 489 F: Forward bit. This bit MUST be set be set to 1. Since this 490 sub-TLV is going to be propagated hop-by-hop, the sub-TLV should 491 be forwarded even by nodes that may not understand it. 493 Type: sub-TLV Type field, as specified by IANA. 495 Length: sub-TLV Length field. This field specifies the total 496 length in octets of the Entropy Label sub-TLV. 498 Value: value of the Entropy Label Indicator Label. 500 5.2. BGP Signaling 502 When BGP [RFC4271] is used for distributing Network Layer 503 Reachability Information (NLRI) as described in, for example, 504 [RFC3107], [RFC4364] and [RFC4761], the BGP UPDATE message may 505 include the Entropy Label attribute. This is an optional, transitive 506 BGP attribute of type TBD. The inclusion of this attribute with an 507 NLRI indicates that the advertising BGP router can process entropy 508 labels as an egress LSR for that NLRI. If the attribute length is 509 less than three octets, this indicates that the egress doesn't need 510 an ELI for the signaled application. If the attribute length is at 511 least three octets, the first three octets encode an ELI label value 512 as the high order 20 bits; the egress requires this ELI with entropy 513 labels. An example where an ELI is needed is when the NLRI contains 514 unlabeled IP prefixes. 516 A BGP speaker S that originates an UPDATE should only include the 517 Entropy Label attribute if both of the following are true: 519 A1: S sets the BGP NEXT_HOP attribute to itself; AND 521 A2: S can process entropy labels for the given application. 523 If both A1 and A2 are true, and S needs an ELI to recognize entropy 524 labels, then S MUST include the ELI label value as part of the 525 Entropy Label attribute. An UPDATE SHOULD contain at most one 526 Entropy Label attribute. 528 Suppose a BGP speaker T receives an UPDATE U with the Entropy Label 529 attribute ELA. T has two choices. T can simply re-advertise U with 530 the same ELA if either of the following is true: 532 B1: T does not change the NEXT_HOP attribute; OR 534 B2: T simply swaps labels without popping the entire label stack and 535 processing the payload below. 537 An example of the use of B1 is Route Reflectors; an example of the 538 use of B2 is illustrated in Section 9.3.1.2. 540 However, if T changes the NEXT_HOP attribute for U and in the data 541 plane pops the entire label stack to process the payload, T MUST 542 remove ELA. T MAY include a new Entropy Label attribute ELA' for 543 UPDATE U' if both of the following are true: 545 C1: T sets the NEXT_HOP attribute of U' to itself; AND 547 C2: T can process entropy labels for the given application. 549 Again, if both C1 and C2 are true, and T needs an ELI to recognize 550 entropy labels, then T MUST include the ELI label value as part of 551 the Entropy Label attribute. 553 5.3. RSVP-TE Signaling 555 Entropy Label support is signaled in RSVP-TE [RFC3209] using an 556 Entropy Label Attribute TLV (Type TBD) of the LSP_ATTRIBUTES object 557 [RFC5420]. The presence of this attribute indicates that the 558 signaler (the egress in the downstream direction using Resv messages; 559 the ingress in the upstream direction using Path messages) can 560 process entropy labels. The Entropy Label Attribute contains a value 561 for the ELI. If the ELI is zero, this indicates that the signaler 562 doesn't need an ELI for this application; if not, then the signaler 563 requires the given ELI with entropy labels. An example where an ELI 564 is needed is when the signaled LSP can carry IP traffic. 566 The format of the Entropy Label Attribute is as follows: 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Entropy Label Attribute | Length (4) | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 573 | ELI Label | MBZ | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 An egress LSR includes the Entropy Label Attribute in a Resv message 577 to indicate that it can process entropy labels in the downstream 578 direction of the signaled LSP. 580 An ingress LSR includes the Entropy Label Attribute in a Path message 581 for a bi-directional LSP to indicate that it can process entropy 582 labels in the upstream direction of the signaled LSP. If the 583 signaled LSP is not bidirectional, the Entropy Label Attribute SHOULD 584 NOT be included in the Path message, and egress LSR(s) SHOULD ignore 585 the attribute, if any. 587 As described in Section 8, there is also the need to distribute an 588 ELI from the ingress (upstream label allocation). In the case of 589 RSVP-TE, this is accomplished using the Upstream ELI Attribute TLV of 590 the LSP_ATTRIBUTES object, as shown below: 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Upstream ELI Attribute | Length (4) | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | ELI Label | MBZ | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 6. Operations, Administration, and Maintenance (OAM) and Entropy Labels 602 Generally OAM comprises a set of functions operating in the data 603 plane to allow a network operator to monitor its network 604 infrastructure and to implement mechanisms in order to enhance the 605 general behavior and the level of performance of its network, e.g., 606 the efficient and automatic detection, localization, diagnosis and 607 handling of defects. 609 Currently defined OAM mechanisms for MPLS include LSP Ping/Traceroute 610 [RFC4379] and Bidirectional Failure Detection (BFD) for MPLS 611 [RFC5884]. The latter provides connectivity verification between the 612 endpoints of an LSP, and recommends establishing a separate BFD 613 session for every path between the endpoints. 615 The LSP traceroute procedures of [RFC4379] allow an ingress LSR to 616 obtain label ranges that can be used to send packets on every path to 617 the egress LSR. It works by having ingress LSR sequentially ask the 618 transit LSRs along a particular path to a given egress LSR to return 619 a label range such that the inclusion of a label in that range in a 620 packet will cause the replying transit LSR to send that packet out 621 the egress interface for that path. The ingress provides the label 622 range returned by transit LSR N to transit LSR N + 1, which returns a 623 label range which is less than or equal in span to the range provided 624 to it. This process iterates until the penultimate transit LSR 625 replies to the ingress LSR with a label range that is acceptable to 626 it and to all LSRs along path preceding it for forwarding a packet 627 along the path. 629 However, the LSP traceroute procedures do not specify where in the 630 label stack the value from the label range is to be placed, whether 631 deep packet inspection is allowed and if so, which keys and key 632 values are to be used. 634 This memo updates LSP traceroute by specifying that the value from 635 the label range is to be placed in the entropy label. Deep packet 636 inspection is thus not necessary, although an LSR may use it, 637 provided it do so consistently, i.e., if the label range to go to a 638 given downstream LSR is computed with deep packet inspection, then 639 the data path should use the same approach and the same keys. 641 In order to have a BFD session on a given path, a value from the 642 label range for that path should be used as the EL value for BFD 643 packets sent on that path. 645 As part of the MPLS-TP work, an in-band OAM channel is defined in 646 [RFC5586]. Packets sent in this channel are identified with a 647 reserved label, the Generic Associated Channel Label (GAL) placed at 648 the bottom of the MPLS label stack. In order to use the inband OAM 649 channel with entropy labels, this memo relaxes the restriction that 650 the GAL must be at the bottom of the MPLS label stack. Rather, the 651 GAL is placed in the MPLS label stack above the entropy label so that 652 it effectively functions as an application label. 654 7. MPLS-TP and Entropy Labels 656 Since MPLS-TP does not use ECMP, entropy labels are not applicable to 657 an MPLS-TP deployment. 659 8. Point-to-Multipoint LSPs and Entropy Labels 661 Point-to-Multipoint (P2MP) LSPs [RFC4875] typically do not use ECMP 662 for load balancing, as the combination of replication and 663 multipathing can lead to duplicate traffic delivery. However, P2MP 664 LSPs can traverse Bundled Links [RFC4201] and LAGs. In both these 665 cases, load balancing is useful, and hence entropy labels can be of 666 some value for P2MP LSPs. 668 There are two potential complications with the use of entropy labels 669 in the context of P2MP LSPs, both a consequence of the fact that the 670 entire label stack below the P2MP label must be the same for all 671 egress LSRs. First, all egress LSRs must be willing to receive 672 entropy labels; if even one egress LSR is not willing, then entropy 673 labels MUST NOT be used for this P2MP LSP. Second, if an ELI is 674 required, all egress LSRs must agree to the same value of ELI. This 675 can be achieved by upstream allocation of the ELI; in particular, for 676 RSVP-TE P2MP LSPs, the ingress LSR distributes the ELI value using 677 the Upstream ELI Attribute TLV of the LSP_ATTRIBUTES object, defined 678 in Section 5.3. 680 With regard to the first issue, the ingress LSR MUST keep track of 681 the ability of each egress LSR to process entropy labels, especially 682 since the set of egress LSRs of a given P2MP LSP may change over 683 time. Whenever an existing egress LSR leaves, or a new egress LSR 684 joins the P2MP LSP, the ingress MUST re-evaluate whether or not to 685 include entropy labels for the P2MP LSP. 687 In some cases, it may be feasible to deploy two P2MP LSPs, one to 688 entropy label capable egress LSRs, and the other to the remaining 689 egress LSRs. However, this requires more state in the network, more 690 bandwidth, and more operational overhead (tracking EL-capable LSRs, 691 and provisioning P2MP LSPs accordingly). Furthermore, this approach 692 may not work for some applications (such mVPNs and VPLS) which 693 automatically create and/or use P2MP LSPs for their multicast 694 requirements. 696 9. Entropy Labels and Applications 698 This section describes the usage of entropy labels in various 699 scenarios with different applications. 701 9.1. Tunnels 703 Tunnel LSPs, signaled with either LDP or RSVP-TE, typically carry 704 other MPLS applications such as VPNs or pseudowires. This being the 705 case, if the egress LSR of a tunnel LSP is willing to process entropy 706 labels, it would signal the need for an Entropy Label Indicator to 707 distinguish between entropy labels and other application labels. 709 In the figures below, the following convention is used to depict 710 information signaled between X and Y: 712 X ---------- ... ---------- Y 713 app: <--- [label L, ELI value] 715 This means Y signals to X label L for application app. The ELI value 716 can be one of: 718 -: meaning entropy labels are NOT accepted; 720 0: meaning entropy labels are accepted, no ELI is needed; or 722 E: entropy labels are accepted, ELI label E is required. 724 The following illustrates a simple intra-AS tunnel LSP. 726 X -------- A --- ... --- B -------- Y 727 tunnel LSP L: [TL, E] <--- ... <--- [TL0, E] 729 IP pkt: push ---------------> 731 Figure 2: Tunnel LSPs and Entropy Labels 733 Tunnel LSPs may cross Autonomous System (AS) boundaries, usually 734 using BGP ([RFC3107]). In this case, the AS Border Routers (ASBRs) 735 MAY simply propagate the egress LSR's ability to process entropy 736 labels, or they MAY declare that entropy labels may not be used. If 737 an ASBR (say A2 below) chooses to propagate the egress LSR Y's 738 ability to process entropy labels, A2 MUST also propagate Y's choice 739 of ELI. 741 X ---- ... ---- A1 ------- A2 ---- ... ---- Y 742 intra-AS LSP A2-Y: <--- [TL0, E] 743 inter-AS LSP A1-A2: [AL, E] 744 intra-AS LSP X-A1: <--- [TL1, E] 746 IP pkt: push 748 Here, ASBR A2 chooses to propagate Y's ability to process entropy 749 labels, by "translating" Y's signaling of entropy label capability 750 (say using LDP) to BGP; and A1 translate A2's BGP signaling to (say) 751 RSVP-TE. The end-to-end tunnel (X to Y) will have entropy labels if 752 X chooses to insert them. 754 Figure 3: Inter-AS Tunnel LSP with Entropy Labels 756 X ---- ... ---- A1 ------- A2 ---- ... ---- Y 757 intra-AS LSP A2-Y: <--- [TL0, E] 758 inter-AS LSP A1-A2: [AL, E] 759 intra-AS LSP X-A1: <--- [TL1, -] 761 IP pkt: push --> 763 Here, ASBR A1 decided that entropy labels are not to be used; thus, 764 the end-to-end tunnel cannot have entropy labels, even though both X 765 and Y may be capable of inserting and processing entropy labels. 767 Figure 4: Inter-AS Tunnel LSP with no Entropy Labels 769 9.2. LDP Pseudowires 771 [I-D.ietf-pwe3-fat-pw] describes the signaling and use of entropy 772 labels in the context of RFC 4447 pseudowires, so this will not be 773 described further here. 775 [RFC4762] specifies the use of LDP for signaling VPLS pseudowires. 776 An egress VPLS PE that can process entropy labels can indicate this 777 by adding the Entropy Label sub-TLV in the LDP message it sends to 778 other PEs. An ELI is not required. An ingress PE must maintain 779 state per egress PE as to whether it can process entropy labels. 781 X -------- A --- ... --- B -------- Y 782 tunnel LSP L: [TL, E] <--- ... <--- [TL0, E] 783 VPLS label: <------------------------ [VL, 0] 785 VPLS pkt: push --------------> 787 Figure 5: Entropy Labels with LDP VPLS 789 Note that although the underlying tunnel LSP signaling indicated the 790 need for an ELI, VPLS packets don't need an ELI, and thus the label 791 stack pushed by X do not have one. 793 [RFC4762] also describes the notion of "hierarchical VPLS" (H-VPLS). 794 In H-VPLS, 'hub PEs' remove the label stack and process VPLS packets; 795 thus, they must make their own decisions on the use of entropy 796 labels, independent of other hub PEs or spoke PEs with which they 797 exchange signaling. In the example below, spoke PEs X and Y and hub 798 PE B can process entropy labels, but hub PE A cannot. 800 X ---- ... ---- A ---- ... ---- B ---- ... ---- Y 801 spoke PW1: <--- [SL1, 0] 802 hub-hub PW: <---- [HL, 0] 803 spoke PW2: <--- [SL2, -] 805 SPW2 pkt: push 806 H-H PW pkt: push 807 SPW1 pkt: push 809 Figure 6: Entropy Labels with H-VPLS 811 9.3. BGP Applications 813 Section 9.1 described a BGP application for the creation of inter-AS 814 tunnel LSPs. This section describes two other BGP applications, IP 815 VPNs ([RFC4364]) and BGP VPLS ([RFC4761]). An egress PE for either 816 of these applications indicates its ability to process entropy labels 817 by adding the Entropy Label attribute to its BGP UPDATE message. 818 Again, ingress PEs must maintain per-egress PE state regarding its 819 ability to process entropy labels. In this section, both of these 820 applications will be referred to as VPNs. 822 In the intra-AS case, PEs signal application labels and entropy label 823 capability to each other, either directly, or via Route Reflectors 824 (RRs). If RRs are used, they must not change the BGP NEXT_HOP 825 attribute in the UPDATE messages; furthermore, they can simply pass 826 on the Entropy Label attribute as is. 828 X -------- A --- ... --- B -------- Y 829 tunnel LSP L: [TL, E] <--- ... <--- [TL0, E] 830 BGP VPN label: <------------------------ [VL, 0] 832 BGP VPN pkt: push --------------> 834 Figure 7: Entropy Labels with Intra-AS BGP apps 836 For BGP VPLS, the application label is at the bottom of stack, so no 837 ELI is needed. For BGP IP VPNs, the application label is usually at 838 the bottom of stack, so again no ELI is needed. However, in the case 839 of Carrier's Carrier (CsC) VPNs, the BGP VPN label may not be at the 840 bottom of stack. In this case, an ELI is necessary for CsC VPN 841 packets with entropy labels to distinguish them from nested VPN 842 packets. In the example below, the nested VPN signaling is not 843 shown; the egress PE for the nested VPN (not shown) must signal 844 whether or not it can process egress labels, and the ingress nested 845 VPN PE may insert an entropy label if so. 847 Three cases are shown: a plain BGP VPN packet, a CsC VPN packet 848 originating from X, and a transit nested VPN packet originating from 849 a nested VPN ingress PE (conceptually to the left of X). It is 850 assumed that the nested VPN packet arrives at X with label stack where ZL is the tunnel label (to be swapped with ) and 852 CVL is the nested VPN label. Note that Y can use the same ELI for 853 the tunnel LSP and the CsC VPN (and any other application that needs 854 an ELI). 856 X -------- A --- ... --- B -------- Y 857 tunnel LSP L: [TL, E] <--- ... <--- [TL0, E] 858 BGP VPN label: <------------------------ [VL, 0] 859 BGP CsC VPN label: <------------------------ [CL, E] 861 BGP VPN pkt: push --------------> 862 CsC VPN pkt: push -----------> 863 nested VPN pkt: swap with --------> 865 Figure 8: Entropy Labels with CoC VPN 867 9.3.1. Inter-AS BGP VPNs 869 There are three commonly used options for inter-AS IP VPNs and BGP 870 VPLS, known informally as "Option A", "Option B" and "Option C". 871 This section describes how entropy labels can be used in these 872 options. 874 9.3.1.1. Option A Inter-AS VPNs 876 In option A, an ASBR pops the full label stack of a VPN packet 877 exiting an AS, processes the payload header (IP or Ethernet), and 878 forwards the packet natively (i.e., as IP or Ethernet, but not as 879 MPLS) to the peer ASBR. Thus, entropy label signaling and insertion 880 are completely local to each AS. The inter-AS paths do not use 881 entropy labels, as they do not use a label stack. 883 9.3.1.2. Option B Inter-AS VPNs 885 The ASBRs in option B inter-AS VPNs have a choice (usually determined 886 by configuration) of whether to just swap labels (from within the AS 887 to the neighbor AS or vice versa), or to pop the full label stack and 888 process the packet natively. This choice occurs at each ASBR in each 889 direction. In the case of native packet processing at an ASBR, 890 entropy label signaling and insertion is local to each AS and to the 891 inter-AS paths (which, unlike option A, do have labeled packets). 893 In the case of simple label swapping at an ASBR, the ASBR can 894 propagate received entropy label signaling onward. That is, if a PE 895 signals to its ASBR that it can process entropy labels (via an 896 Entropy Label attribute), the ASBR can propagate that attribute to 897 its peer ASBR; if a peer ASBR signals that it can process entropy 898 labels, the ASBR can propagate that to all PEs within its AS). Note 899 that this is the case even though ASBRs change the BGP NEXT_HOP 900 attribute to "self", because of clause B2 in Section 5.2. 902 9.3.1.3. Option C Inter-AS VPNs 904 In Option C inter-AS VPNs, the ASBRs are not involved in signaling; 905 they do not have VPN state; they simply swap labels of inter-AS 906 tunnels. Signaling is PE to PE, usually via Route Reflectors; 907 however, if RRs are used, the RRs do not change the BGP NEXT_HOP 908 attribute. Thus, entropy label signaling and insertion are on a PE- 909 pair basis, and the intermediate routers, ASBRs and RRs do not play a 910 role. 912 9.4. Multiple Applications 914 It has been mentioned earlier that an ingress PE must keep state per 915 egress PE with regard to its ability to process entropy labels. An 916 ingress PE must also keep state per application, as entropy label 917 processing must be based on the application context in which a packet 918 is received (and of course, the corresponding entropy label 919 signaling). 921 In the example below, an egress LSR Y signals a tunnel LSP L, and is 922 prepared to receive entropy labels on L, but requires an ELI. 923 Furthermore, Y signals two pseudowires PW1 and PW2 with labels PL1 924 and PL2, respectively, and indicates that it can receive entropy 925 labels for both pseudowires without the need of an ELI; and finally, 926 Y signals a L3 VPN with label VL, but Y does not indicate that it can 927 receive entropy labels for the L3 VPN. Ingress LSR X chooses to send 928 native IP packets to Y over L with entropy labels, thus X must 929 include the given ELI (yielding a label stack of ). X 930 chooses to add entropy labels on PW1 packets to Y, with a label stack 931 of , but chooses not to do so for PW2 packets. X must 932 not send entropy labels on L3 VPN packets to Y, i.e., the label stack 933 must be . 935 X -------- A --- ... --- B -------- Y 936 tunnel LSP L: [TL, E] <--- ... <--- [TL0, E] 937 PW1 label: <----------------------- [PL1, 0] 938 PW2 label: <----------------------- [PL2, 0] 939 VPN label: <----------------------- [VL, -] 941 IP pkt: push -------------> 942 PW1 pkt: push -------------> 943 PW2 pkt: push -----------------> 944 VPN pkt: push ------------------> 946 Figure 9: Entropy Labels for Multiple Applications 948 10. Security Considerations 950 This document describes advertisement of the capability to support 951 receipt of entropy-labels and an Entropy Label Indicator that an 952 ingress LSR may apply to MPLS packets in order to allow transit LSRs 953 to attain better load-balancing across LAG and/or ECMP paths in the 954 network. 956 This document does not introduce new security vulnerabilities to LDP. 957 Please refer to the Security Considerations section of LDP 958 ([RFC5036]) for security mechanisms applicable to LDP. 960 Given that there is no end-user control over the values used for 961 entropy labels, there is little risk of Entropy Label forgery which 962 could cause uneven load-balancing in the network. 964 If Entropy Label Capability is not signaled from an egress PE to an 965 ingress PE, due to, for example, malicious configuration activity on 966 the egress PE, then the PE's will fall back to not using entropy 967 labels for load-balancing traffic over LAG or ECMP paths which, in 968 some cases, in no worse than the behavior observed in current 969 production networks. That said, operators are recommended to monitor 970 changes to PE configurations and, more importantly, the fairness of 971 load distribution over equal-cost LAG or ECMP paths. If the fairness 972 of load distribution over a set of paths changes that could indicate 973 a misconfiguration, bug or other non-optimal behavior on their PE's 974 and they should take corrective action. 976 Given that most applications already signal an Application Label, 977 e.g.: IPVPNs, LDP VPLS, BGP VPLS, whose Bottom of Stack bit is being 978 re-used to signal entropy label capability, there is little to no 979 additional risk that traffic could be misdirected into an 980 inappropriate IPVPN VRF or VPLS VSI at the egress PE. 982 In the context of downstream-signaled entropy labels that require the 983 use of an Entropy Label Indicator (ELI), there should be little to no 984 additional risk because the egress PE is solely responsible for 985 allocating an ELI value and ensuring that ELI label value DOES NOT 986 conflict with other MPLS labels it has previously allocated. On the 987 other hand, for upstream-signaled entropy labels, e.g.: RSVP-TE 988 point-to-point or point-to-multipoint LSP's or Multicast LDP (mLDP) 989 point-to-multipoint or multipoint-to-multipoint LSP's, there is a 990 risk that the head-end MPLS LER may choose an ELI value that is 991 already in use by a downstream LSR or LER. In this case, it is the 992 responsibility of the downstream LSR or LER to ensure that it MUST 993 NOT accept signaling for an ELI value that conflicts with MPLS 994 label(s) that are already in use. 996 11. IANA Considerations 998 11.1. LDP Entropy Label TLV 1000 IANA is requested to allocate the next available value from the IETF 1001 Consensus range in the LDP TLV Type Name Space Registry as the 1002 "Entropy Label TLV". 1004 11.2. BGP Entropy Label Attribute 1006 IANA is requested to allocate the next available Path Attribute Type 1007 Code from the "BGP Path Attributes" registry as the "BGP Entropy 1008 Label Attribute". 1010 11.3. Attribute Flags for LSP_Attributes Object 1012 IANA is requested to allocate a new bit from the "Attribute Flags" 1013 sub-registry of the "RSVP TE Parameters" registry. 1015 Bit | Name | Attribute | Attribute | RRO 1016 No | | Flags Path | Flags Resv | 1017 ----+----------------------+------------+------------+----- 1018 TBD Entropy Label LSP Yes Yes No 1020 11.4. Attributes TLV for LSP_Attributes Object 1022 IANA is requested to allocate the next available value from the 1023 "Attributes TLV" sub-registry of the "RSVP TE Parameters" registry. 1025 12. Acknowledgments 1027 We wish to thank Ulrich Drafz for his contributions, as well as the 1028 entire 'hash label' team for their valuable comments and discussion. 1030 13. References 1032 13.1. Normative References 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1037 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 1038 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 1039 Encoding", RFC 3032, January 2001. 1041 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 1042 BGP-4", RFC 3107, May 2001. 1044 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1045 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1046 Tunnels", RFC 3209, December 2001. 1048 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 1049 Ayyangarps, "Encoding of Attributes for MPLS LSP 1050 Establishment Using Resource Reservation Protocol Traffic 1051 Engineering (RSVP-TE)", RFC 5420, February 2009. 1053 13.2. Informative References 1055 [I-D.ietf-pwe3-fat-pw] 1056 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 1057 J., and S. Amante, "Flow Aware Transport of Pseudowires 1058 over an MPLS Packet Switched Network", 1059 draft-ietf-pwe3-fat-pw-07 (work in progress), July 2011. 1061 [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling 1062 in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. 1064 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 1065 Protocol 4 (BGP-4)", RFC 4271, January 2006. 1067 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1068 Networks (VPNs)", RFC 4364, February 2006. 1070 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 1071 Label Switched (MPLS) Data Plane Failures", RFC 4379, 1072 February 2006. 1074 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 1075 Heron, "Pseudowire Setup and Maintenance Using the Label 1076 Distribution Protocol (LDP)", RFC 4447, April 2006. 1078 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 1079 (VPLS) Using BGP for Auto-Discovery and Signaling", 1080 RFC 4761, January 2007. 1082 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 1083 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 1084 RFC 4762, January 2007. 1086 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 1087 "Extensions to Resource Reservation Protocol - Traffic 1088 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 1089 Switched Paths (LSPs)", RFC 4875, May 2007. 1091 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 1092 Specification", RFC 5036, October 2007. 1094 [RFC5586] Bocci, M., Vigoureux, M., and S. Bryant, "MPLS Generic 1095 Associated Channel", RFC 5586, June 2009. 1097 [RFC5884] Aggarwal, R., Kompella, K., Nadeau, T., and G. Swallow, 1098 "Bidirectional Forwarding Detection (BFD) for MPLS Label 1099 Switched Paths (LSPs)", RFC 5884, June 2010. 1101 Appendix A. Applicability of LDP Entropy Label sub-TLV 1103 In the case of unlabeled IPv4 (Internet) traffic, the Best Current 1104 Practice is for an egress LSR to propagate eBGP learned routes within 1105 a SP's Autonomous System after resetting the BGP next-hop attribute 1106 to one of its Loopback IP addresses. That Loopback IP address is 1107 injected into the Service Provider's IGP and, concurrently, a label 1108 assigned to it via LDP. Thus, when an ingress LSR is performing a 1109 forwarding lookup for a BGP destination it recursively resolves the 1110 associated next-hop to a Loopback IP address and associated LDP label 1111 of the egress LSR. 1113 Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label 1114 sub-TLV will typically be applied only to the FEC for the Loopback IP 1115 address of the egress LSR and the egress LSR will not announce an 1116 entropy label capability for the eBGP learned route. 1118 Authors' Addresses 1120 Kireeti Kompella 1121 Juniper Networks 1122 1194 N. Mathilda Ave. 1123 Sunnyvale, CA 94089 1124 US 1126 Email: kireeti@juniper.net 1128 John Drake 1129 Juniper Networks 1130 1194 N. Mathilda Ave. 1131 Sunnyvale, CA 94089 1132 US 1134 Email: jdrake@juniper.net 1136 Shane Amante 1137 Level 3 Communications, LLC 1138 1025 Eldorado Blvd 1139 Broomfield, CO 80021 1140 US 1142 Email: shane@level3.net 1144 Wim Henderickx 1145 Alcatel-Lucent 1146 Copernicuslaan 50 1147 2018 Antwerp 1148 Belgium 1150 Email: wim.henderickx@alcatel-lucent.com 1152 Lucy Yong 1153 Huawei USA 1154 1700 Alma Dr. Suite 500 1155 Plano, TX 75075 1156 US 1158 Email: lucyyong@huawei.com