idnits 2.17.1 draft-kompella-mpls-larp-11.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (13 December 2021) is 836 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) == Outdated reference: A later version (-17) exists of draft-kaliraj-idr-bgp-classful-transport-planes-12 -- Obsolete informational reference (is this intentional?): RFC 3107 (Obsoleted by RFC 8277) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MPLS Working Group K. Kompella 3 Internet-Draft R. Balaji 4 Intended status: Standards Track Juniper Networks 5 Expires: 16 June 2022 R. Thomas 6 Cohesity 7 13 December 2021 9 Label Distribution Using ARP 10 draft-kompella-mpls-larp-11 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 key to deploying MPLS in data centers and 18 enterprises. 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 https://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 16 June 2022. 37 Copyright Notice 39 Copyright (c) 2021 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 55 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of Ethernet ARP . . . . . . . . . . . . . . . . . . 3 57 3. L-ARP Protocol Operation . . . . . . . . . . . . . . . . . . 4 58 3.1. Setup . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Egress Operation . . . . . . . . . . . . . . . . . . . . 5 60 3.3. Ingress Operation . . . . . . . . . . . . . . . . . . . . 6 61 3.4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. Secondary Attributes . . . . . . . . . . . . . . . . . . 7 64 5. L-ARP Message Format . . . . . . . . . . . . . . . . . . . . 8 65 5.1. Hardware Address Format . . . . . . . . . . . . . . . . . 9 66 5.2. CT TLV . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 10 72 9.2. Informative References . . . . . . . . . . . . . . . . . 11 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 This document describes extensions to the Address Resolution Protocol 78 (ARP) [RFC0826] to advertise label bindings for IP host addresses. 79 While there are well-established protocols, such as LDP [RFC5036], 80 RSVP [RFC3209], BGP [RFC3107] and SPRING-MPLS [RFC8660], that provide 81 robust mechanisms for label distribution, these protocols tend to be 82 relatively complex, and often require detailed configuration for 83 proper operation. There are situations where a simpler protocol may 84 be more suitable from an operational standpoint. An example is the 85 case where an MPLS Fabric is the underlay technology in a Data 86 Center; here, MPLS tunnels originate from host machines. The host 87 thus needs a mechanism to acquire label bindings to participate in 88 the MPLS Fabric, but in a simple, plug-and-play manner. Existing 89 signaling/routing protocols do not always meet this need. Labeled 90 ARP (L-ARP) is a proposal to fill that gap. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 The term "server" will be used in this document to refer to an ARP/ 101 L-ARP server; the term "host" will be used to refer to a compute 102 server or other device acting as an ARP/L-ARP client. 104 1.2. Approach 106 ARP is a nearly ubiquitous protocol; every device with an Ethernet 107 interface, from hand-helds to hosts, have an implementation of ARP. 108 ARP is plug-and-play; ARP clients do not need configuration to use 109 ARP. That suggests that ARP may be a good fit for devices that want 110 to source and sink MPLS tunnels, but do so in a zero-config, plug- 111 and-play manner, with minimal impact to their code. 113 The approach taken here is to create a minor variant of the ARP 114 protocol, labeled ARP (L-ARP), which is distinguished by a new 115 hardware type, MPLS-over-Ethernet. Regular (Ethernet) ARP (E-ARP) 116 and L-ARP can coexist; a device, as an ARP client, can choose to send 117 out an E-ARP or an L-ARP request, depending on whether it needs 118 Ethernet or MPLS connectivity. Another device may choose to function 119 as an E-ARP server and/or an L-ARP server, depending on its ability 120 to provide an IP-to-Ethernet and/or IP-to-MPLS mapping. 122 2. Overview of Ethernet ARP 124 In the most straightforward mode of operation [RFC0826], ARP queries 125 are sent to resolve "directly connected" IP addresses. The ARP 126 request is broadcast, with the Target Protocol Address field (see 127 Section 5 for a description of the fields in an ARP message) carrying 128 the IP address of another node in the same subnet. All the nodes in 129 the LAN receive this ARP request. All the nodes, except the node 130 that owns the IP address, ignore the ARP request. The IP address 131 owner learns the MAC address of the sender from the Source Hardware 132 Address field in the ARP request, and unicasts an ARP reply to the 133 sender. The ARP reply carries the replying node's MAC address in the 134 Source Hardware Address field, thus enabling two-way communication 135 between the two nodes. 137 A variation of this scheme, known as "proxy ARP" [RFC2002], allows a 138 node to respond to an ARP request with its own MAC address, even when 139 the responding node does not own the requested IP address. 140 Generally, the proxy ARP response is generated by routers to attract 141 traffic for prefixes they can forward packets to. This scheme 142 requires the host to send ARP queries for the IP address the host is 143 trying to reach, rather than the IP address of the router. When 144 there is more than one router connected to a network, proxy ARP 145 enables a host to automatically select an exit router without running 146 any routing protocol to determine IP reachability. Unlike regular 147 ARP, a proxy ARP request can elicit multiple responses, e.g., when 148 more than one router has connectivity to the address being resolved. 149 The sender must be prepared to select one of the responding routers. 151 Yet another variation of the ARP protocol, called 'Gratuitous ARP' 152 [RFC2002], allows a node to update the ARP cache of other nodes in an 153 unsolicited fashion. Gratuitous ARP is sent as either an ARP request 154 or an ARP reply. In either case, the Source Protocol Address and 155 Target Protocol Address contain the sender's address, and the Source 156 Hardware Address is set to the sender's hardware address. In case of 157 a gratuitous ARP reply, the Target Hardware Address is also set to 158 the sender's address. 160 3. L-ARP Protocol Operation 162 The L-ARP protocol builds on the proxy ARP model, and also leverages 163 gratuitous ARP model for asynchronous updates. 165 In this memo, we will refer to L-ARP clients (that make L-ARP 166 requests) and L-ARP servers (that send L-ARP responses). In 167 Figure 1, H1, H2 and H3 are L-ARP clients, and T1, T2 and T3 are 168 L-ARP servers. T4 is a member of the MPLS Fabric that may not be an 169 L-ARP server. Within the MPLS Fabric, the usual MPLS protocols (IGP 170 (i.e., SPRING-MPLS), LDP, RSVP-TE) are run. Say H1, H2 and H3 want 171 to establish MPLS tunnels to each other (for example, they are using 172 BGP MPLS VPNs as the overlay virtual network technology). H1 might 173 also want to talk to a member of the MPLS Fabric, say T. Also, the 174 "protocol" addresses in L-ARP requests are either IPv4 or IPv6 175 addresses; note that while it is common to use Neighbor Discovery 176 (ND) [RFC4861] for "regular" ARP requests when dealing with IPv6 177 (i.e., to obtain Ethernet MAC addresses corresponding to an IPv6 178 address), ND is not used when the ARP request is for an MPLS label. 180 . . . . . . . 181 . . 182 H1 --- T1 T4 183 \ . MPLS . 184 \ . . 185 \ . Fabric . 186 H2 --- T2 T3 --- H3 187 . . 188 . . . . . . . 190 Figure 1: MPLS Fabric 192 3.1. Setup 194 In Figure 1, the nodes T1-T4, and those in between making up the 195 "MPLS Fabric" are assumed to be running some protocol whereby they 196 can signal MPLS reachability to themselves and to other nodes (like 197 hosts H1-H3). T1-T3 are L-ARP servers; T4 need not be, since it 198 doesn't have an attached L-ARP client. H1-H3 are L-ARP clients. 200 3.2. Egress Operation 202 A node (say T3) that wants an attached node (say H3) to have MPLS 203 reachability allocates a label L3 to reach H3 and advertises this 204 label into the MPLS Fabric. This can be triggered by configuration 205 on T3, or when T3 first receives an L-ARP request from H3 (indicating 206 that H3 wants MPLS connectivity), or via some other protocol. T3 207 then advertises (H3, L3) to its peers in the MPLS Fabric so that all 208 members of the Fabric have connectivity to H3. This advertisement 209 can be one of the following: 211 * a "proxy" LDP message (sent on behalf of H3) with prefix H3 and 212 label L3; or 214 * a node Segment ID (SID) advertised on behalf of H3; or 216 * a labeled BGP advertisement, with prefix H3, label L3 and next hop 217 self. 219 On receiving a packet with label L3, T3 pops the label and send 220 the packet to H3. (In the case of labeled BGP, there would be a 221 two-label stack, with outer label to reach T3 and inner label of 222 L3.) This is the usual operation of an MPLS Fabric, with the 223 addition of advertising labels for nodes outside the fabric. 225 3.3. Ingress Operation 227 A node (say H1, an L-ARP client) that needs an MPLS tunnel to another 228 node (say H3) identified by a host address (either IPv4 or IPv6) 229 broadcasts over all its interfaces an L-ARP request with the Target 230 Protocol Address set to H3 and Hardware Type set to "MPLS-over- 231 Ethernet". A node receiving the L-ARP request (say T1, an L-ARP 232 server) does the following: 234 1. checks if it has MPLS reachability to H3. If not, it ignores the 235 L-ARP request. 237 2. if it does, T1 allocates a label TL3 to reach H3 (if it doesn't 238 already have such a label) and installs an L-FIB entry to swap L1 239 with the label (stack) to reach H3. 241 3. sends a (proxy) L-ARP reply to H1 with the Source Hardware 242 Address (SHA) set to (L, M), where M is T1's metric to H3. T1 243 may also set some attribute bits in the SHA. 245 3.4. Data Plane 247 To send a packet to H3 over an MPLS tunnel, H1 pushes L1 onto the 248 packet, sets the destination MAC address to M1 and sends it to T1. 249 On receiving this packet, T1 swaps the top label with the label(s) 250 for its MPLS tunnel to H3. If T1's reachability to H3 is via a 251 SPRING label stack, the label L1 acts as an implicit binding SID. 253 If H1 and H3 have an overlay connection (say an IPVPN [RFC4364] VPN- 254 foo) whereby VM1 on H1 wishes to talk to VM3 on H3 over VPN-foo, H1 255 does the following: 257 1. H1 learns information about VPN-foo via BGP (or an SDN 258 controller), including the VPN label VL3 to use to talk to VM3; 260 2. H1 installs a VRF for VPN-foo, with prefix VM3, label VL3 and 261 next hop H3; 263 3. H1 binds the local "veth" interface to VM1 to this VRF. 265 4. When VM1 sends a packet to dest IP address VM3 over its veth 266 interface, H1 looks up VM3 in the corresponding VRF, gets label 267 VL3. It then sends an L-ARP request for next hop H3, and gets 268 TL3. 270 5. Finally, H1 pushes the label pair (TL3, VL3) onto the packet from 271 VM1 and sends this to T1. This packet will then end up at VM3 on 272 H3. 274 Note that H1 broadcasts its L-ARP request over its attached 275 interfaces. H1 may receive several L-ARP replies; in that case, H1 276 can select any subset of these to send MPLS packets destined to H3. 277 As described later, the L-ARP response may contain certain parameters 278 that enable the client to make an informed choice. If the target H3 279 belongs to one of the subnets that H1 participates in, and H3 is 280 capable of sending L-ARP replies, H1 can use H3's response to send 281 MPLS packets to H3. 283 4. Attributes 285 In addition to carrying a label stack to be used in the data plane, 286 an L-ARP reply carries some attributes that are typically used in the 287 control plane. One of these is a metric. The metric is the distance 288 from the L-ARP server to the destination. This allows an L-ARP 289 client that receives multiple responses to decide which ones to use, 290 and whether to load-balance across some of them. The metric 291 typically will be the IGP shortest path distance from server to the 292 destination; this makes comparing metrics from different servers 293 meaningful. 295 Another attribute is Entropy Label (EL) Capability. This attribute 296 says whether the destination is EL capable (ELC). In Figure 1, if T3 297 advertises a label to reach H3 and T3 is ELC, T3 can include in its 298 signaling to T1 that it is ELC. In that case, T1's L-ARP reply to H1 299 can have ELC bit set. This tells H1 that it may include (below the 300 outermost label) an Entropy Label Indicator followed by an Entropy 301 Label. This will help improve load balancing across the MPLS Fabric, 302 and possibly on the last hop to H3. 304 4.1. Secondary Attributes 306 Beyond the basic attributes that are carried with every L-ARP 307 request, there more optional attributes, for example, to ask for 308 certain characteristics of the path traffic takes to the destination. 309 These attributes are carried in TLVs that are carried in L-ARP 310 requests and replies. 312 One such TLV is the Classful Transport (CT: see 313 [I-D.kaliraj-idr-bgp-classful-transport-planes]) TLV. This TLV 314 allows the L-ARP client to request a label to a destination over a 315 tunnel of the given Transport Class. To satisfy this request, the 316 L-ARP server creates (or finds) a tunnel to the destination that is 317 routed over the CT Transport Plane, allocates a label L, inserts an 318 entry in the LFIB to swap L to the tunnel, and sends L to the L-ARP 319 client in its reply. 321 5. L-ARP Message Format 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | ar$hrd | ar$pro | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | ar$hln | ar$pln | ar$op | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 // ar$sha (ar$hln octets) // 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 // ar$spa (ar$pln octets) // 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 // ar$tha (ar$hln octets) // 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 // ar$tpa (ar$pln octets) // 336 +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 337 | Type | Length | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 // Value // 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Type | Length | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 // Value // 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | ... | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 Figure 2: L-ARP Packet Format 350 ar$hrd: Hardware Type: MPLS-over-Ethernet. The value of the field 351 used here is HTYPE-MPLS. To start with, we will use the 352 experimental value HW_EXP2 (256). 354 ar$pro: Protocol Type: IPv4/IPv6. The value of the field used here 355 is 0x0800 to resolve an IPv4 address and 0x86DD to resolve an IPv6 356 address. 358 ar$hln: Hardware Address Length: 6 360 ar$pln: Protocol Address Length: for an IPv4 address, the length is 361 4 octets; for an IPv6 address, it is 16. 363 ar$op: Operation Code: set to 1 for request, 2 for reply, and 10 for 364 ARP-NAK. Other op codes may be used as needed. 366 ar$sha: Source Hardware Address: In an L-ARP request, this is 367 usually all zeros. In an L-ARP reply, Source Hardware Address is 368 the label to reach ar$spa, as specified in Figure 3 below. 370 ar$spa: Source Protocol Address: In an L-ARP request, this field 371 carries the sender's IP address. In an L-ARP reply, this field 372 carries the requested IP address (which may not be the sender's IP 373 address). 375 ar$tha: Target Hardware Address: In an L-ARP message, this is all 376 zeros. 378 ar$tpa: Target Protocol Address: In an L-ARP request, this field 379 carries the IP address for which the client is seeking an MPLS 380 label. 382 Type: a 2-octet field defining the Type of the TVL 384 Length: a 2-octet field defining the Length L of the TVL 386 Value: an L-octet field with the Value of the TLV 388 5.1. Hardware Address Format 390 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 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | MPLS Label (20 bits) |E|Z|Z|Z| Metric ... | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | ... (3 octets) | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 Figure 3: Label Format in L-ARP 399 MPLS Label: The 20-bit label 401 E-bit: Entropy Label Capable: this flag indicates whether the 402 corresponding label in the label stack can be followd by an 403 Entropy Label. If this flag is set, the client has the option of 404 inserting ELI and EL as specified in [RFC6790]. The client can 405 choose not to insert ELI/EL pair. If this flag is clear, the 406 client must not insert ELI/EL after the corresponding label. 408 Z: These bits are not used, and SHOULD be set to zero on sending and 409 ignored on receipt. 411 Metric: The 3-octet IGP metric to ar$tha from the point of view of 412 the L-ARP replier. 414 5.2. CT TLV 416 The CT TLV has Type (TBD) and Length 4 octets; the Value field 417 consists of the CT attribute. 419 6. Security Considerations 421 There are many possible attacks on ARP: ARP spoofing, ARP cache 422 poisoning and ARP poison routing, to name a few. These attacks use 423 gratuitous ARP as the underlying mechanism, a mechanism used by 424 L-ARP. Thus, these types of attacks are applicable to L-ARP. 425 Furthermore, ARP does not have built-in security mechanisms; defenses 426 rely on means external to the protocol. 428 It is well outside the scope of this document to present a general 429 solution to the ARP security problem. One simple answer is to add a 430 TLV that contains a digital signature of the contents of the ARP 431 message. This TLV would be defined for use only in L-ARP messages, 432 although in principle, other ARP messages could use it as well. Such 433 an approach would, of course, need a review and approval by the 434 Security Directorate. If approved, the type of this TLV and its 435 procedures would be defined in this document. If some other 436 technique is suggested, the authors would be happy to include the 437 relevant text in this document, and refer to some other document for 438 the full solution. 440 7. IANA Considerations 442 IANA is requested to allocate a new ARP hardware type (from registry 443 hrd) for HTYPE-MPLS [IANA]. 445 IANA is further requested to create a registry for Types of L-ARP 446 Secondary Attributes. This registry should contain an entry for the 447 CT Type Section 5.2. 449 8. Acknowledgments 451 Many thanks to Shane Amante for his detailed comments and 452 suggestions. Many thanks to the team in Juniper prototyping this 453 work for their suggestions on making this variant workable in the 454 context of existing ARP implementations. Thanks too to Luyuan Fang, 455 Alex Semenyaka and Dmitry Afanasiev for their comments and 456 encouragement. 458 9. References 460 9.1. Normative References 462 [IANA] IANA, "Address Resolution Protocol (ARP) Parameters/ 463 Hardware Types", n.d., . 466 [RFC0826] Plummer, D., "An Ethernet Address Resolution Protocol: Or 467 Converting Network Protocol Addresses to 48.bit Ethernet 468 Address for Transmission on Ethernet Hardware", STD 37, 469 RFC 826, DOI 10.17487/RFC0826, November 1982, 470 . 472 [RFC2002] Perkins, C., Ed., "IP Mobility Support", RFC 2002, 473 DOI 10.17487/RFC2002, October 1996, 474 . 476 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 477 Requirement Levels", BCP 14, RFC 2119, 478 DOI 10.17487/RFC2119, March 1997, 479 . 481 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 482 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 483 RFC 6790, DOI 10.17487/RFC6790, November 2012, 484 . 486 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 487 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 488 May 2017, . 490 9.2. Informative References 492 [I-D.kaliraj-idr-bgp-classful-transport-planes] 493 Vairavakkalai, K., Venkataraman, N., Rajagopalan, B., 494 Mishra, G., Khaddam, M., Xu, X., Szarecki, R. J., and D. 495 J. Gowda, "BGP Classful Transport Planes", Work in 496 Progress, Internet-Draft, draft-kaliraj-idr-bgp-classful- 497 transport-planes-12, 25 August 2021, 498 . 501 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 502 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 503 . 505 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 506 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 507 Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, 508 . 510 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 511 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 512 2006, . 514 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 515 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 516 DOI 10.17487/RFC4861, September 2007, 517 . 519 [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., 520 "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, 521 October 2007, . 523 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 524 Decraene, B., Litkowski, S., and R. Shakir, "Segment 525 Routing with the MPLS Data Plane", RFC 8660, 526 DOI 10.17487/RFC8660, December 2019, 527 . 529 Authors' Addresses 531 Kireeti Kompella 532 Juniper Networks 533 1133 Innovation Way 534 Sunnyvale, 94089 535 United States of America 537 Phone: +1-408-745-2000 538 Email: kireeti.ietf@gmail.com 540 Balaji Rajagopalan 541 Juniper Networks 542 Survey No.111/1 to 115/4, Wing A & B 543 Bangalore 560103 544 India 546 Email: balajir@juniper.net 548 Reji Thomas 549 Cohesity 551 Email: rejithomas.d@gmail.com