idnits 2.17.1 draft-kompella-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 (July 12, 2010) is 5037 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) == Outdated reference: A later version (-07) exists of draft-ietf-pwe3-fat-pw-03 -- Obsolete informational reference (is this intentional?): RFC 4447 (Obsoleted by RFC 8077) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Kompella 3 Internet-Draft Juniper Networks 4 Updates: 3031 (if approved) S. Amante 5 Intended status: Standards Track Level 3 Communications, LLC 6 Expires: January 13, 2011 July 12, 2010 8 The Use of Entropy Labels in MPLS Forwarding 9 draft-kompella-mpls-entropy-label-01 11 Abstract 13 Load balancing is a powerful tool for engineering traffic across a 14 network. This memo suggests ways of improving load balancing across 15 MPLS networks using the notion of "entropy labels". It defines the 16 concept, describes why they are needed, suggests how they can be 17 used, and enumerates properties of entropy labels that allow optimal 18 benefit. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 13, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2. Conventions used . . . . . . . . . . . . . . . . . . . . . 6 57 2. Approaches . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 3. Entropy Labels . . . . . . . . . . . . . . . . . . . . . . . . 7 59 4. Forwarding and Load Balancing Behaviors for Entropy Labels . . 7 60 4.1. Ingress LSR . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.2. Transit LSR . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.3. Egress LSRs . . . . . . . . . . . . . . . . . . . . . . . 8 63 5. Signaling for Entropy Labels . . . . . . . . . . . . . . . . . 9 64 5.1. LDP Signaling . . . . . . . . . . . . . . . . . . . . . . 9 65 5.1.1. Structure of Entropy Label sub-TLV . . . . . . . . . . 10 66 5.2. RSVP Signaling . . . . . . . . . . . . . . . . . . . . . . 11 67 5.3. BGP Signaling . . . . . . . . . . . . . . . . . . . . . . 11 68 6. MPLS-TP and Entropy Labels . . . . . . . . . . . . . . . . . . 11 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 70 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 71 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 10.2. Informative References . . . . . . . . . . . . . . . . . . 12 75 Appendix A. Applicability of LDP Entropy Label sub-TLV . . . . . 12 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 78 1. Introduction 80 Load balancing, or multi-pathing, is an attempt to balance traffic 81 across a network by allowing the traffic to use several paths, not 82 just a single shortest path. Load balancing has several benefits: it 83 eases capacity planning; it can help absorb traffic surges by 84 spreading them across several links; it allow better resilience by 85 offering alternate paths should a link or node fail. 87 As providers scale their networks, they resort to a small number of 88 techniques to achieve greater bandwidth between nodes and, 89 subsequently, depend on load-balancing of traffic over those paths. 90 Two widely used techniques are: Link Aggregation (LAG) and Equal-Cost 91 Multi-Path (ECMP). LAG is only used to bond together several 92 physical circuits between two adjacent nodes so they appear to 93 higher-layer protocols as a single, higher bandwidth "virtual" pipe. 94 On the other hand, ECMP is used between two nodes, separated by one 95 or more hops, to allow load-sharing over more than just the shortest 96 path in the network -- this is typically obtained by arranging IGP 97 metrics such that there are several equal cost paths between source- 98 destination pairs. In summary, both of these techniques may, and 99 oftentimes do, co-exist in various parts of a given providers 100 network, depending on various choices made by the provider. 102 A very important consideration when load balancing is that packets 103 belonging to a given "flow" MUST be mapped to the same path, i.e., 104 the same exact sequence of links across the network. This is to 105 avoid jitter, latency and re-ordering issues for the flow. However, 106 what constitutes a flow varies considerably. A common example of a 107 flow is a TCP session. Other examples are L2TP sessions 108 corresponding to broadband users, or traffic within an ATM virtual 109 circuit. A flow is usually defined, for the purposes of forwarding 110 and load balancing, by a hash computed on packet headers such that 111 packets belonging to a given flow map to the same hash value. The 112 fields chosen for such a hash depend on the packet type; a typical 113 set (for IP packets) is the IP source and destination address, the 114 protocol type, and (for TCP and UDP traffic) the source and 115 destination port numbers. A conservative choice of fields leads to 116 many flows mapping to the same hash value (and consequently poor load 117 balancing); an overly aggressive choice may map a flow to multiple 118 values, potentially causing the issues mentioned above. 120 For MPLS networks, most of the same principles (and benefits) apply. 121 However, finding useful fields in a packet for the purpose of load 122 balancing can be more of a challenge. In many cases, the extra 123 encapsulation may require fairly deep inspection of packets to find 124 these fields at every hop. An idea for removing the need for this 125 deep inspection is to extract this information *once*, at the ingress 126 of an MPLS Label Switched Path (LSP), and encode, within the label 127 stack itself, in addition to the forwarding semantics of the label 128 stack, the load balancing information. This information can then be 129 used on all MPLS hops across the network. There are three key 130 reasons why this is beneficial: 132 1. at the ingress of the LSP, MPLS encapsulation hasn't yet 133 occurred, so deep inspection is not necessary; 135 2. the ingress of an LSP has more context and information about 136 incoming packets than transit nodes; and 138 3. ingress nodes usually operate at lower bandwidths than transit 139 nodes, allowing them to do more work per packet. 141 This memo describes a few approaches to solving this problem, and 142 focuses on one method, which uses the notion of entropy labels. This 143 memo goes on to define entropy labels, and describes why they are 144 needed, and the properties of entropy labels in the forwarding plane: 145 how they are generated and received and what is expected of transit 146 Label Switching Routers (LSRs). Finally, it describes in general how 147 signaling works and what needs to be signaled, as well as specifics 148 for LDP. 150 1.1. Motivation 152 MPLS is very successful generic forwarding substrate that may 153 transport several dozen types of protocols, most notably: IP, PWE3, 154 VPLS and IP VPN's. Within each type of protocol, there typically 155 exist several variants as it relates to load-sharing, e.g.: IP: IPv4, 156 IPv6, IPv6 in IPv4, etc.; PWE3: Ethernet, ATM, Frame-Relay, etc. 157 There are also several different types of Ethernet over PW 158 encapsulation, ATM over PW encapsulation, etc. as well. Finally, 159 given the popularity of MPLS, it is likely that it will continue to 160 be extended to transport new protocols as the need arises. 162 Currently, each MPLS LSR along a given path needs to individually 163 infer the underlying protocol within a MPLS packet in order to then 164 extract appropriate keys from the payload. Those keys are then used 165 as input into a hash algorithm to determine the specific output 166 interface on a LSR that is used for that given "microflow". 167 Unfortunately, if the MPLS LSR is unable to infer the MPLS packet's 168 payload (as is often the case), they typically will resort to using 169 the topmost MPLS labels in the MPLS stack as keys to the load-hashing 170 algorithm. The result is an extremely inequitable distribution of 171 traffic across multiple equal-cost paths exiting that node, simply 172 because the topmost MPLS labels are very coarse-grained forwarding 173 labels that typically describe a next-hop, or provide some other type 174 of mux/demux forwarding function, and do not describe the granularity 175 of the underlying traffic. 177 On the other hand, ingress MPLS LER's (PE routers) have detailed 178 knowledge of an MPLS packet's contents, typically through a priori 179 configuration of encapsulation(s) that are expected at a given PE-CE 180 interface, (e.g.: IPv4, IPv6, VPLS, etc.). PE routers need this 181 information to: a) discern the packet's CoS forwarding treatment, b) 182 apply filters to forward or block traffic to/from the CE; c) to 183 forward routing/control traffic to an onboard management processor; 184 or, d) load-share the traffic on its uplinks to P routers. By 185 knowing the expected encapsulation types, an ingress PE router could 186 apply a smaller subset of payload parsing routines to extract keys 187 appropriate for the given protocol. Ultimately, this should allow 188 for significantly improved accuracy in determining the appropriate 189 load-balancing behavior for each protocol. 191 In addition, compared to MPLS LSR's, PE routers typically operate at 192 lower forwarding rates as well as have more flexible forwarding 193 hardware. As a result, a PE router can typically adapt much more 194 quickly to new/emerging protocols and determine the appropriate keys 195 used for load-sharing traffic that type of traffic through the 196 network. 198 An additional advantage of applying entropy labels only at the edge 199 of the network, on PE routers, would be that core/transit MPLS LSR's 200 could once again return to being completely oblivious to the contents 201 of each MPLS packet, and only use the outer MPLS labels to determine 202 forwarding and forwarding treatment of MPLS packets. Specifically, 203 there will be no reason to duplicate, from MPLS LER's, extremely 204 complex packet/payload parsing functionality within MPLS LSR's and 205 attempt to keep to keep this functionality at parity across all 206 network elements, e.g.: both MPLS LSR's and LER's. Ultimately, this 207 should result in less complexity within core LSR's allowing them to 208 more easily scale to higher forwarding rates, larger port density, 209 consume less power, etc. Finally, the approach discussed in this 210 memo would allow for more rapid deployment of new protocols, since 211 MPLS LSR's will not have to be developed or modified to understand 212 how to properly extract keys to achieve good load-sharing of traffic 213 throughout the network. 215 In summary, MPLS LSR's are ill-equipped to infer the protocol within 216 a packet's payload and choose appropriate keys within the payload to 217 correctly identify a given "microflow", which is required to provide 218 the most equitable load-sharing over multiple equal cost paths. On 219 the other hand, PE routers have both the knowledge and capabilities 220 to more accurately determine the load-sharing treatment that should 221 be applied to a given protocol encapsulated within MPLS by MPLS 222 LSR's. 224 1.2. Conventions used 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 Labels stacks are denoted , which L1 is the "outermost" 231 label and L3 the innermost (closest to the payload). Packet flows 232 are depicted left to right, and signaling is shown right to left 233 (unless otherwise indicated). 235 2. Approaches 237 There are two main approaches to encoding load balancing information 238 in the label stack. The first allocates multiple labels for a 239 particular Forwarding Equivalance Class (FEC). These labels are 240 equivalent in terms of forwarding semantics, but having several 241 allows flexibility in assigning labels to flows from the same FEC. 242 The other approach encodes the load balancing information as a 243 separate label in the label stack. Here, there are two sub- 244 approaches, based on whether this load-balancing label is signaled or 245 not. 247 The first approach has the advantage that the label stack stays the 248 same depth whether using label-based load balancing or not; and so, 249 consequently, do forwarding operations on transit and egress LSRs. 250 However, it has a major drawback in that signaling and forwarding 251 state are both increased significantly. The number of independent 252 choices for load balancing packets belonging to a FEC limits the 253 effectiveness of load balancing, so one would like this number to be 254 large. However, the larger this number is, the greater the signaling 255 and forwarding state in the network. 257 The second approach increases the size of the label stack by one 258 label. This consequently affects operations on ingress, transit and 259 egress LSRs. The sub-approach of signaling the load-balancing labels 260 increases signaling and forwarding state, and so suffers from some of 261 the problems of the first approach. 263 The approach advocated by this memo, and the only one described in 264 detail, is the one where the load-balancing labels are not signaled. 265 With this approach, there is minimal change to signaling state for a 266 FEC; also, there is no change in forwarding operations in transit 267 LSRs, and no increase of forwarding state in any LSR. The only 268 purpose of these labels is to increase the entropy in the label 269 stack, so they are called "entropy labels". 271 3. Entropy Labels 273 An entropy label (as used here) is a label: 275 1. that is not used for forwarding; 277 2. that is not signaled; and 279 3. whose only purpose in the label stack is to provide "entropy" to 280 improve load balancing. 282 Entropy labels are generated by an ingress LSR, based entirely on 283 load balancing information. However, they MUST NOT have values in 284 the reserved label space (0-15). Entropy labels MUST be at the 285 bottom of the label stack, and thus the "end-of-stack" bit in the 286 label should be set. To ensure that they are not used inadvertently 287 for forwarding, entropy labels SHOULD have a TTL of 0. 289 Since entropy labels are generated by the ingress LSR, an egress LSR 290 MUST be able to tell unambiguously that a given label is an entropy 291 label. This of course depends on the underlying application. If any 292 ambiguity is possible, the label above the entropy label MUST be an 293 "entropy label indicator" (ELI), which says that the following label 294 is an entropy label. The ELI may be signaled, or may be a reserved 295 label reserved specifically for this purpose. Fortunately, for many 296 applications, the use of entropy labels is unambiguous, and does not 297 need an ELI. 299 Applications for MPLS entropy labels include pseudowires ([RFC4447], 300 [I-D.ietf-pwe3-fat-pw]), Layer 3 VPN's ([RFC4364]), VPLS ([RFC4761], 301 [RFC4762]) and Tunnel LSPs. This memo specifies general properties 302 of entropy labels, and the signaling of entropy labels for LDP 303 ([RFC5036]) tunnel LSPs. Other memos will specify the signaling and 304 use of entropy labels for specific applications. 306 4. Forwarding and Load Balancing Behaviors for Entropy Labels 308 4.1. Ingress LSR 310 Suppose that for a particular application (or FEC), an ingress LSR X 311 has to push label stack , where TL is the "tunnel label" and 312 AL is the application label. (Note the use of the convention for 313 label stacks described in Section 1.2. The use of a two-label stack 314 is just for illustrative purposes.) Suppose furthermore that X is to 315 use entropy labels for this application. Thus, the resultant label 316 stack will be , where EL is the entropy label. 318 When a packet for this FEC arrives at X, X must first determine the 319 fields that it will use for load balancing. Typically, X will then 320 generate a hash H over those fields. X will then pick an outgoing 321 label stack to push on the packet. However, X must also 322 generate an entropy label EL (based either directly on the load 323 balancing fields, or on the hash H). EL is a "regular" 32-bit label, 324 encoded in the usual way; however, the EOS bit MUST be 1 and the TTL 325 field MUST be 0. X then pushes on to the packet before 326 forwarding it to the next LSR. If X is told (via signaling) that it 327 must use an entropy label indicator ELI, then X instead pushes on to the packet. 330 Note that ingress LSR X MUST NOT include an entropy label unless the 331 egress LSR for this FEC has indicated that it is ready to receive 332 entropy labels. Furthermore, if the egress LSR has signaled that an 333 ELI is needed, then X MUST include the ELI with the entropy label; 334 otherwise, X MUST NOT use entropy labels. 336 4.2. Transit LSR 338 Transit LSRs have no change in forwarding behavior. For load 339 balancing, transit LSRs SHOULD use the whole label stack (e.g., for 340 computing the load balance hash). Transit LSRs MAY choose to look 341 beyond the label stack for further load balancing information; 342 however, if entropy labels are being used, this may not be very 343 useful. In a mixed environment (or for backward compatibility), this 344 is the simplest approach. 346 Thus, transit LSRs are almost unaffected by the use of entropy 347 labels. If transit LSRs were programmed to use a subset of the label 348 stack, they may have to be reconfigured to use the full stack. But 349 otherwise, no changes are needed. 351 4.3. Egress LSRs 353 An ingress LSR X MUST NOT send entropy labels to an egress LSR Y 354 unless Y has signaled its readiness to receive such labels. Y must 355 also determine (for a particular application or FEC), whether it can 356 distinguish whether the ingress has added an entropy label or not; if 357 Y cannot do so, Y MUST request that an ELI be used for this FEC. 358 Alternatively, Y MUST require the use of entropy labels. (See 359 Section 5 for more details on signaling.) 361 Suppose Y has signaled that it is prepared to receive entropy labels 362 for a given FEC. In this case, Y must be able to distinguish whether 363 an ingress LSR has inserted an entropy label or not based solely on 364 the 'end-of-stack' (EOS) bit on the application label for this FEC. 365 When Y receives a packet with this application label, then Y looks to 366 see if the EOS bit is set. If not, Y assumes that the label below is 367 an entropy label and pops it. Y MAY choose to ensure that the 368 entropy label has its EOS bit set and TTL=0. Y then processes the 369 packet as usual. Implementations may choose the order in which they 370 apply these operations, but the net result should be as specified. 372 5. Signaling for Entropy Labels 374 Signaling for entropy labels exchanges three types of information: 376 1. whether an LSR Y is prepared to receive entropy labels, 378 2. whether receiving LSR Y requires ELIs with entropy labels, and if 379 so, what label to use as the ELI, and 381 3. whether an LSR X is able to send entropy labels. 383 The uses of this information can be illustrated as follows. If an 384 LSR Y is prepared to receive entropy labels for an application (or 385 FEC), it signals that to the ingress LSR(s). That means that an 386 ingress LSR for this application MAY send an entropy label for this 387 application; Y MUST be able to distinguish whether or not an entropy 388 label was sent based solely on the EOS bit on the application label. 390 In cases where an application label is used, Y does not need to 391 signal an ELI for this FEC. However, Y MUST clear the EOS bit on the 392 application label to indicate that the label that follows will be an 393 Entropy Label. 395 In cases where no application label exists, Y can signal that an ELI 396 MUST be used for this FEC; Y may also signal what ELI to use. In 397 this case, an ingress LSR will either not send an entropy label, or 398 push the ELI before the entropy label. This makes the use/non-use of 399 an entropy label unambiguous. However, this also increases the size 400 of the label stack. 402 The specific protocols and encoding details for the above will depend 403 on the underlying application; see [I-D.ietf-pwe3-fat-pw] for an 404 example for pseudowires. 406 5.1. LDP Signaling 408 When using LDP for signaling tunnel labels ([RFC5036]), a Label 409 Mapping Message sub-TLV (Entropy Label sub-TLV) type is used to 410 synchronize the entropy label states between the ingress and egress 411 PE's. 413 The presence of the Entropy Label sub-TLV in the Label Mapping 414 Message indicates to the ingress PE that the egress PE can correctly 415 process a entropy label. In addition, the Entropy Label sub-TLV 416 contains a label value that must be inserted as the ELI by the 417 ingress PE, assuming the ingress PE can apply entropy labels to 418 outgoing packets. 420 It should be noted that the egress PE only needs to send a single 421 Label value for the ELI, which does not conflict with any other 422 labels it has advertised to other PE's for other applications. 424 5.1.1. Structure of Entropy Label sub-TLV 426 The structure of the Entropy Label sub-TLV is shown in Figure 1. 428 0 1 2 3 429 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 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 |U|F| Type | Length | 432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 433 | ELI Label | 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 Figure 1: Entropy Label sub-TLV 438 Where: 440 U: Unknown bit. This bit MUST be set to 1. If the Entropy Label 441 sub-TLV is not understood, then the TLV is not known to the 442 receiver and MUST be ignored. 444 F: Forward bit. This bit MUST be set be set to 1. Since this 445 sub-TLV is going to propagated hop-by-hop, the sub-TLV should be 446 forwarded even by devices that may not understand it. 448 Type: Type field. 'Entropy Label sub-TLV' specified by IANA. 450 Length: Length field. This field specifies the total length in 451 octets of the Entropy Label sub-TLV. 453 ELI Label: Entropy Label Indicator Label. The Entropy Label 454 Indicator (ELI) label notifies the receiver that the following 455 label in the MPLS Label stack is the Entropy Label. It should be 456 noted that the ELI Label is unnecessary for protocols that use an 457 application label that precedes the Entropy Label. 459 Label 461 This is a 20-bit label value represented as a 20-bit number in a 4 462 octet field as follows: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | ELI Label | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 2: Entropy Label Indicator Label 472 5.2. RSVP Signaling 474 TBD. 476 5.3. BGP Signaling 478 TBD. 480 6. MPLS-TP and Entropy Labels 482 Interoperability with MPLS-TP Generic Associated Channel Label (GAL) 483 are outside the scope of this document. 485 7. Security Considerations 487 This document describes advertisement of the capability to support 488 receipt of entropy-labels and an Entropy Label Indicator that an 489 ingress PE may apply to MPLS packets in order to allow Core LSR's to 490 attain better load-balancing across LAG and/or ECMP paths in the 491 network. 493 This document does not introduce new security vulnerabilities to LDP. 494 Please refer to the Security Considerations section of LDP 495 ([RFC5036]) for security mechanisms applicable to LDP. 497 8. IANA Considerations 499 IANA is requested to allocate the next available value from IETF 500 Consensus range in the LDP TLV Type Name Space Registry as the 501 Entropy Label TLV. 503 9. Acknowledgments 505 We wish to thank Ulrich Drafz and John Drake for their contributions, 506 as well as the entire "hash label" team for their valuable comments 507 and discussion. 509 10. References 511 10.1. Normative References 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 10.2. Informative References 518 [I-D.ietf-pwe3-fat-pw] 519 Bryant, S., Filsfils, C., Drafz, U., Kompella, V., Regan, 520 J., and S. Amante, "Flow Aware Transport of Pseudowires 521 over an MPLS PSN", draft-ietf-pwe3-fat-pw-03 (work in 522 progress), January 2010. 524 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 525 Networks (VPNs)", RFC 4364, February 2006. 527 [RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. 528 Heron, "Pseudowire Setup and Maintenance Using the Label 529 Distribution Protocol (LDP)", RFC 4447, April 2006. 531 [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service 532 (VPLS) Using BGP for Auto-Discovery and Signaling", 533 RFC 4761, January 2007. 535 [RFC4762] Lasserre, M. and V. Kompella, "Virtual Private LAN Service 536 (VPLS) Using Label Distribution Protocol (LDP) Signaling", 537 RFC 4762, January 2007. 539 [RFC5036] Andersson, L., Minei, I., and B. Thomas, "LDP 540 Specification", RFC 5036, October 2007. 542 Appendix A. Applicability of LDP Entropy Label sub-TLV 544 In the case of unlabeled IPv4 (Internet) traffic, the Best Current 545 Practice is for an egress PE to propagate eBGP learned routes within 546 a SP's Autonomous System after resetting the BGP next-hop attribute 547 to the Loopback IP address of the egress PE. That Loopback IP 548 address is injected into the Service Provider's IGP and, 549 concurrently, a label assigned to it via LDP. Thus, when an ingress 550 PE is performing a forwarding lookup for a BGP destination it 551 recursively resolves the associated next-hop to a Loopback IP address 552 and associated LDP label of the egress PE. 554 Thus, in the context of unlabeled IPv4 traffic, the LDP Entropy Label 555 sub-TLV will typically be applied only to the FEC for the Loopback IP 556 address of the egress PE. 558 Authors' Addresses 560 Kireeti Kompella 561 Juniper Networks 562 1194 N. Mathilda Ave. 563 Sunnyvale, CA 94089 564 US 566 Email: kireeti@juniper.net 568 Shane Amante 569 Level 3 Communications, LLC 570 1025 Eldorado Blvd 571 Broomfield, CO 80021 572 US 574 Email: shane@level3.net