idnits 2.17.1 draft-kompella-mpls-larp-03.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 30, 2015) is 3283 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: 'TODO-MPLS-FABRIC' is mentioned on line 96, but not defined == Missing Reference: 'HTYPE-MPLS' is mentioned on line 332, but not defined == Unused Reference: 'RFC5226' is defined on line 485, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS WG K. Kompella 3 Internet-Draft R. Balaji 4 Intended status: Standards Track Juniper Networks 5 Expires: November 1, 2015 G. Swallow 6 Cisco Systems 7 April 30, 2015 9 Label Distribution Using ARP 10 draft-kompella-mpls-larp-03 12 Abstract 14 This document describes extensions to the Address Resolution Protocol 15 to distribute MPLS labels for IPv4 and IPv6 host addresses. 16 Distribution of labels via ARP enables simple plug-and-play operation 17 of MPLS, which is a key goal of the MPLS Fabric architecture. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in [RFC2119]. 25 The term "server" will be used in this document to refer to an ARP/ 26 L-ARP server; the term "host" will be used to refer to a compute 27 server or other device acting as an ARP/L-ARP client. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on November 1, 2015. 46 Copyright Notice 48 Copyright (c) 2015 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 1.1. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 66 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 67 3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 68 3.2. Asynchronous operation . . . . . . . . . . . . . . . . . 5 69 3.3. Client-Server Synchronization . . . . . . . . . . . . . . 5 70 3.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 71 3.5. Backward Compatibility . . . . . . . . . . . . . . . . . 6 72 4. For Future Study . . . . . . . . . . . . . . . . . . . . . . 6 73 5. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 7 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 77 9. Normative References . . . . . . . . . . . . . . . . . . . . 11 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 This document describes extensions to the Address Resolution Protocol 83 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 84 While there are well-established protocols, such as LDP, RSVP and 85 BGP, that provide robust mechanisms for label distribution, these 86 protocols tend to be relatively complex, and often require detailed 87 configuration for proper operation. There are situations where a 88 simpler protocol may be more suitable from an operational standpoint. 89 An example is the case where an MPLS Fabric is the underlay 90 technology in a Data Centre; here, MPLS tunnels originate from host 91 machines. The host thus needs a mechanism to acquire label bindings 92 to participate in the MPLS Fabric, but in a simple, plug-and-play 93 manner. Existing signaling/routing protocols do not always meet this 94 need. Labeled ARP (L-ARP) is a proposal to fill that gap. 96 [TODO-MPLS-FABRIC] describes the motivation for using MPLS as the 97 fabric technology. 99 1.1. Approach 101 ARP is a nearly ubiquitous protocol; every device with an Ethernet 102 interface, from hand-helds to hosts, have an implementation of ARP. 103 ARP is plug-and-play; ARP clients do not need configuration to use 104 ARP. That suggests that ARP may be a good fit for devices that want 105 to source and sink MPLS tunnels, but do so in a zero-config, plug- 106 and-play manner, with minimal impact to their code. 108 The approach taken here is to create a minor variant of the ARP 109 protocol, labeled ARP (L-ARP), which is distinguished by a new 110 hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP (E-ARP) 111 and L-ARP can coexist; a device, as an ARP client, can choose to send 112 out an E-ARP or an L-ARP request, depending on whether it needs 113 Ethernet or MPLS connectivity. Another device may choose to function 114 as an E-ARP server and/or an L-ARP server, depending on its ability 115 to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. 117 2. Overview of Ethernet ARP 119 In the most straightforward mode of operation [RFC0826], ARP queries 120 are sent to resolve "directly connected" IP addresses. The ARP query 121 is broadcast, with the Target Protocol Address field (see Section 5 122 for a description of the fields in an ARP message) carrying the IP 123 address of another node in the same subnet. All the nodes in the LAN 124 receive this ARP query. All the nodes, except the node that owns the 125 IP address, ignore the ARP query. The IP address owner learns the 126 MAC address of the sender from the Source Hardware Address field in 127 the ARP request, and unicasts an ARP reply to the sender. The ARP 128 reply carries the replying node's MAC address in the Source Hardware 129 Address field, thus enabling two-way communication between the two 130 nodes. 132 A variation of this scheme, known as "proxy ARP" [RFC2002], allows a 133 node to respond to an ARP request with its own MAC address, even when 134 the responding node does not own the requested IP address. 135 Generally, the proxy ARP response is generated by routers to attract 136 traffic for prefixes they can forward packets to. This scheme 137 requires the host to send ARP queries for the IP address the host is 138 trying to reach, rather than the IP address of the router. When 139 there is more than one router connected to a network, proxy ARP 140 enables a host to automatically select an exit router without running 141 any routing protocol to determine IP reachability. Unlike regular 142 ARP, a proxy ARP request can elicit multiple responses, e.g., when 143 more than one router has connectivity to the address being resolved. 144 The sender must be prepared to select one of the responding routers. 146 Yet another variation of the ARP protocol, called 'Gratuitous ARP' 147 [RFC2002], allows a node to update the ARP cache of other nodes in an 148 unsolicited fashion. Gratuitous ARP is sent as either an ARP request 149 or an ARP reply. In either case, the Source Protocol Address and 150 Target Protocol Address contain the sender's address, and the Source 151 Hardware Address is set to the sender's hardware address. In case of 152 a gratuitous ARP reply, the Target Hardware Address is also set to 153 the sender's address. 155 3. L-ARP Protocol Operation 157 The L-ARP protocol builds on the proxy ARP model, and also leverages 158 gratuitous ARP model for asynchronous updates. 160 In this memo, we will refer to L-ARP clients (that make L-ARP 161 requests) and L-ARP servers (that send L-ARP responses). In 162 Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are 163 L-ARP servers. T is a member of the MPLS Fabric that may not be an 164 L-ARP server. Within the MPLS Fabric, the usual MPLS protocols (IGP, 165 LDP, RSVP-TE) are run. Say H1, H2 and H3 want to establish MPLS 166 tunnels to each other (for example, they are using BGP MPLS VPNs as 167 the overlay virtual network technology). H1 might also want to talk 168 to a member of the MPLS Fabric, say T. 170 . . . . . . 171 . . 172 H1 --- T1 T4 173 \ . MPLS . 174 \ . . 175 \ . Fabric . 176 H2 --- T2 T3 --- H3 177 . . 178 . . . . . . 180 Figure 1 182 3.1. Basic Operation 184 A node (say H1) that needs an MPLS tunnel to a destination (say H3) 185 broadcasts over all its interfaces an L-ARP query with the Target 186 Protocol Address set to H3. A node that has reachability to H3 (such 187 as T1 or T2) sends an L-ARP reply with the Source Hardware Address 188 set to a locally-allocated MPLS label plus its Ethernet MAC address. 190 After receiving one or more L-ARP replies, H1 can select either T1 or 191 T2 to send MPLS packets that are destined to H3. As described later, 192 the L-ARP response may contain certain parameters that enable the 193 client to make an informed choice of the routers. 195 As with standard ARP, the validity of the MPLS label obtained using 196 L-ARP is time-bound. The client should periodically resend its L-ARP 197 requests to obtain the latest information, and time out entries in 198 its ARP cache if such an update is not forthcoming. Once an L-ARP 199 server has advertised a label binding, it MUST NOT change the binding 200 until expiry of the binding's validity time. 202 The mechanism defined here is simplistic; see Section 4. 204 3.2. Asynchronous operation 206 The preceding sections described a request-response based model. In 207 some cases, the L-ARP server may want to asynchronously update its 208 clients. L-ARP uses the gratuitous ARP model [RFC2002] to "push" 209 such changes. 211 In a pure "push" model, a device may send out updates for all 212 prefixes it knows about. This naive approach will not scale well. 213 This memo specifies a mode of operation that is somewhere between 214 "push" and "pull" model. An L-ARP server does not advertise any 215 binding for a prefix until at least one L-ARP client expresses 216 interest in that prefix (by initiating an L-ARP query). As long as 217 the server has at least one interested client for a prefix, the 218 server sends unsolicited (aka gratuitous, though the term is less 219 appropriate in this context) L-ARP replies when a prefix's 220 reachability changes. The server will deem the client's interest in 221 a prefix to have ceased when it does not hear any L-ARP queries for 222 some configured timeout period. 224 3.3. Client-Server Synchronization 226 In an L-ARP reply, the server communicates several pieces of 227 information to the client: its hardware address, the MPLS label, 228 Entropy Label capability and metric. Since ARP is a stateless 229 protocol, it is possible that one of these changes without the client 230 knowing, which leads to a loss of synchronization between the client 231 and the server. This loss of synchronization can have several bad 232 effects 234 If the server's hardware address changes or the MPLS label is 235 repurposed by the server for a different purpose, then packets may be 236 sent to the wrong destination. The consequences can range from 237 suboptimally routed packets to dropped packets to packets being 238 delivered to the wrong customer, which may be a security breach. 239 This last may be the most troublesome consequence of loss of 240 synchronization. 242 If a destination transitions from entropy label capable to entropy 243 label incapable (an unlikely event) without the client knowing, then 244 packets encapsulated with entropy labels will be dropped. A 245 transition in the other direction is relatively benign. 247 If the metric changes without the client knowing, packets may be 248 suboptimally routed. This may be the most benign consequence of loss 249 of synchronization. 251 3.4. Applicability 253 L-ARP can be used between a host and its Top-of-Rack switch in a Data 254 Center. L-ARP can also be used between a DSLAM and its aggregation 255 switch going to the B-RAS. More generally, L-ARP can be used between 256 an "access node" and its first hop MPLS-enabled device in the context 257 of Seamless MPLS [reference]. In all these cases, L-ARP can handle 258 the presence of multiple connections between the access device and 259 its first hop devices. 261 ARP is not a routing protocol. The use of L-ARP should be limited to 262 cases where the L-ARP client has a small number of one-hop 263 connections to L-ARP servers. The presence of a complex topology 264 between the L-ARP client and server suggests the use of a different 265 protocol. 267 3.5. Backward Compatibility 269 Since L-ARP uses a new hardware type, it is backward compatible with 270 "regular" ARP. ARP servers and clients MUST be able to send out, 271 receive and process ARP messages based on hardware type. They MAY 272 choose to ignore requests and replies of some hardware types; they 273 MAY choose to log errors if they encounter hardware types they do not 274 recognize; however, they MUST handle all hardware types gracefully. 275 For hardware types that they do understand, ARP servers and clients 276 MUST handle operation codes gracefully, processing those they 277 understand, and ignoring (and possibly logging) others. 279 4. For Future Study 281 The L-ARP specification is quite simple, and the goal is to keep it 282 that way. However, inevitably, there will be questions and features 283 that will be requested. Some of these are: 285 1. Keeping L-ARP clients and servers in sync. In particular, 286 dealing with: 288 A. client and/or server restart 290 B. lost packets 292 C. timeouts 294 2. Withdrawing a response. 296 3. Dealing with scale. 298 4. If there are many servers, which one to pick? 300 5. How can a client make best use of underlying ECMP paths? 302 6. and probably many more. 304 In all of these, it is important to realize that, whenever possible, 305 a solution that places most of the burden on the server rather than 306 on the client is preferable. 308 5. L-ARP Message Format 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | ar$hrd | ar$pro | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | ar$hln | ar$pln | ar$op | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 // ar$sha (ar$hln octets) // 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 // ar$spa (ar$pln octets) // 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 // ar$tha (ar$hln octets) // 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 // ar$tpa (ar$pln octets) // 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 // ar$lst (variable...) // 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 // ar$att (variable...) // 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 Figure 2: L-ARP Packet Format 331 ar$hrd Hardware Type: MPLS-over-Ethernet. The value of the field 332 used here is [HTYPE-MPLS]. To start with, we will use the 333 experimental value HW_EXP2 (256) 335 ar$pro Protocol Type: IPv4/IPv6. The value of the field used here 336 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an 337 IPv6 address. 339 ar$hln Hardware Length: 6. 341 ar$pln Protocol Address Length: for an IPv4 address, the value is 4; 342 for an IPv6 address, it is 16. 344 ar$op Operation Code: set to 1 for request, 2 for reply, and 10 for 345 ARP-NAK. Other op codes may be used as needed. 347 ar$sha Source Hardware Address: In an L-ARP message, Source Hardware 348 Address is the 6 octet sender's MAC address. 350 ar$spa Source Protocol Address: In an L-ARP message, this field 351 carries the sender's IP address. 353 ar$tha Target Hardware Address: In an L-ARP query message, Target 354 Hardware Address is the all-ones Broadcast MAC address; in an 355 L-ARP reply message, it is the client's MAC address. 357 ar$tpa Target Protocol Address: In an L-ARP message, this field 358 carries the IP address for which the client is seeking an MPLS 359 label. 361 ar$lst Label Stack: In an L-ARP request, this field is empty. In an 362 L-ARP reply, this field carries the MPLS label stack as an ARP 363 TLV in the format below. 365 ar$att Attributes: In an L-ARP request, this field is empty. In an 366 L-ARP reply, this field carries attributes for the MPLS label 367 stack as an ARP TLV in the format below. 369 This document introduces the notion of ARP TLVs. These take the form 370 as in Figure 3. Figure 4 describes the format of Label Stack TLV 371 carried in L-ARP. Figure 5 describes the format of Attributes TLV 372 carried in L-ARP. 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Type | Length | Value (Length octets) ... | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | ... | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 Type is the type of the TLV; Length is the length of the value field 382 in octets; Value is the value field. 384 Figure 3: ARP TLVs 386 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 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | Type | Length | MPLS Label (20 bits) | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | |E|Z|Z|Z| MPLS Label (20 bits) |E|Z|Z|Z| 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | ... 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 4: MPLS Label Stack Format 397 Label Stack: Type = TLV-LST; Length = n*3 octets, where n is the 398 number of labels. The Value field contains the MPLS label stack 399 for the client to use to get to the target. Each label is 3 400 octets. This field is valid only in an L-ARP reply message. 402 E-bit: Entropy Label Capable: this flag indicates whether the 403 corresponding label in the label stack can be followd by an 404 Entropy Label. If this flag is set, the client has the option of 405 inserting ELI and EL as specified in [RFC6790]. The client can 406 choose not to insert ELI/EL pair. If this flag is clear, the 407 client must not insert ELI/EL after the corresponding label. 409 Z These bits are not used, and SHOULD be set to zero on sending and 410 ignored on receipt. 412 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 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Type | Length | Metric (4 octets) ... | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | ... Metric | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 Figure 5: Attribute TLV 421 Attributes TLV: Type = TLV-ATT; Length = 4 octets. The Value field 422 contains the metric (typically, IGP distance) from the responder 423 to the destination (device with the requested IP address). This 424 field is valid only in an L-ARP reply message. 426 If other parameters are deemed useful in the ATT TLV, they will be 427 added as needed. 429 6. Security Considerations 431 There are many possible attacks on ARP: ARP spoofing, ARP cache 432 poisoning and ARP poison routing, to name a few. These attacks use 433 gratuitous ARP as the underlying mechanism, a mechanism used by 434 L-ARP. Thus, these types of attacks are applicable to L-ARP. 435 Furthermore, ARP does not have built-in security mechanisms; defenses 436 rely on means external to the protocol. 438 It is well outside the scope of this document to present a general 439 solution to the ARP security problem. One simple answer is to add a 440 TLV that contains a digital signature of the contents of the ARP 441 message. This TLV would be defined for use only in L-ARP messages, 442 although in principle, other ARP messages could use it as well. Such 443 an approach would, of course, need a review and approval by the 444 Security Directorate. If approved, the type of this TLV and its 445 procedures would be defined in this document. If some other 446 technique is suggested, the authors would be happy to include the 447 relevant text in this document, and refer to some other document for 448 the full solution. 450 7. IANA Considerations 452 IANA is requested to allocate a new ARP hardware type (from the 453 registry hrd) for HTYPE-MPLS. 455 IANA is also requested to create a new registry ARP-TLV ("tlv"). 456 This is a registry of one octet numbers. Allocation policies: 0 is 457 not to be allocated; the range 1-127 is Standards Action; the values 458 128-251 are FCFS; and the values 252-255 are Experimental. 460 Finally, IANA is requested to allocate two values in the ARP-TLV 461 registry, one for TLV-LST and another for TLV-ATT. 463 8. Acknowledgments 465 Many thanks to Shane Amante for his detailed comments and 466 suggestions. Many thanks to the team in Juniper prototyping this 467 work for their suggestions on making this variant workable in the 468 context of existing ARP implementations. Thanks too to Luyuan Fang, 469 Alex Semenyaka and Dmitry Afanasiev for their comments and 470 encouragement. 472 9. Normative References 474 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 475 converting network protocol addresses to 48.bit Ethernet 476 address for transmission on Ethernet hardware", STD 37, 477 RFC 826, November 1982. 479 [RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 480 1996. 482 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 483 Requirement Levels", BCP 14, RFC 2119, March 1997. 485 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 486 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 487 May 2008. 489 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 490 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 491 RFC 6790, November 2012. 493 Authors' Addresses 495 Kireeti Kompella 496 Juniper Networks 497 1194 N. Mathilda Avenue 498 Sunnyvale, CA 94089 499 USA 501 Email: kireeti.kompella@gmail.com 503 Balaji Rajagopalan 504 Juniper Networks 505 Prestige Electra, Exora Business Park 506 Marathahalli - Sarjapur Outer Ring Road 507 Bangalore 560103 508 India 510 Email: balajir@juniper.net 511 George Swallow 512 Cisco Systems 513 1414 Massachusetts Ave 514 Boxborough, MA 01719 515 US 517 Email: swallow@cisco.com