idnits 2.17.1 draft-ietf-mpls-rfc3107bis-04.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 (August 17, 2017) is 2441 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) ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) == Outdated reference: A later version (-22) exists of draft-ietf-idr-tunnel-encaps-07 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force E. Rosen 3 Internet-Draft Juniper Networks, Inc. 4 Obsoletes: 3107 (if approved) August 17, 2017 5 Intended status: Standards Track 6 Expires: February 18, 2018 8 Using BGP to Bind MPLS Labels to Address Prefixes 9 draft-ietf-mpls-rfc3107bis-04 11 Abstract 13 This document specifies a set of procedures for using BGP to 14 advertise that a specified router has bound a specified MPLS label 15 (or a specified sequence of MPLS labels, organized as a contiguous 16 part of a label stack) to a specified address prefix. This can be 17 done by sending a BGP UPDATE message whose Network Layer Reachability 18 Information field contains both the prefix and the MPLS label(s), and 19 whose Next Hop field identifies the node at which said prefix is 20 bound to said label(s). This document obsoletes RFC 3107. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on February 18, 2018. 39 Copyright Notice 41 Copyright (c) 2017 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Using BGP to Bind an Address Prefix to One or More MPLS 58 Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.1. Multiple Labels Capability . . . . . . . . . . . . . . . 5 60 2.2. NLRI Encoding when the Multiple Labels Capability is 61 Not Used . . . . . . . . . . . . . . . . . . . . . . . . 8 62 2.3. NLRI Encoding when the Multiple Labels Capability is Used 10 63 2.4. How to Explicitly Withdraw the Binding of a Label to a 64 Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.5. Changing the Label that is Bound to a Prefix . . . . . . 12 66 3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes . . . 13 67 3.1. Comparability of Routes . . . . . . . . . . . . . . . . . 13 68 3.2. Modification of Label(s) Field When Propagating . . . . . 14 69 3.2.1. When the Next Hop Field is Unchanged . . . . . . . . 14 70 3.2.2. When the Next Hop Field is Changed . . . . . . . . . 14 71 4. Data Plane . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5. Relationship Between SAFI-4 and SAFI-1 Routes . . . . . . . . 17 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 75 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 78 9.2. Informative References . . . . . . . . . . . . . . . . . 22 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 81 1. Introduction 83 [RFC3107] specifies encodings and procedures for using BGP to 84 indicate that a particular router has bound either a single MPLS 85 label or a sequence of MPLS labels (organized as a contiguous part of 86 an MPLS label stack) ([RFC3031], [RFC3032]) to a particular address 87 prefix. This is done by sending a BGP UPDATE message whose Network 88 Layer Reachability Information field contains both the prefix and the 89 MPLS label(s), and whose Next Hop field identifies the node at which 90 said prefix is bound to said label(s). Each such UPDATE also 91 advertises a path to the specified prefix, via the specified next 92 hop. 94 Although there are many implementations and deployments of [RFC3107], 95 there are a number of issues with [RFC3107] that have impeded 96 interoperability in the past, and may potentially impede 97 interoperability in the future: 99 o Although [RFC3107] specifies an encoding that allows a sequence of 100 MPLS labels (rather than just a single label) to be bound to a 101 prefix, it does not specify the semantics of binding a sequence of 102 labels to a prefix. 104 o Many implementations of [RFC3107] assume that only one label will 105 be bound to a prefix, and cannot properly process a BGP UPDATE 106 message that binds a sequence of labels to a prefix. Thus an 107 implementation attempting to provide this feature is likely to 108 experience problems interoperating with other implementations. 110 o [RFC3107]'s procedures for withdrawing the binding of a label or 111 sequence of labels to a prefix are not specified clearly and 112 correctly. 114 o [RFC3107] specifies an optional feature, known as "Advertising 115 Multiple Routes to a Destination", that, to the best of the 116 author's knowledge, has never been implemented as specified. The 117 functionality that this feature was intended to provide can and 118 has been implemented in a different way using the procedures of 119 [RFC7911], which were not available at the time that [RFC3107] was 120 written. In [RFC3107], this feature was controlled by a BGP 121 Capability Code that has never been implemented, and is now 122 essentially obsolete. 124 o It is possible for a BGP speaker to receive two BGP UPDATEs that 125 advertise paths to the same address prefix, where one UPDATE binds 126 a label (or sequence of labels) to the prefix and the other does 127 not. [RFC3107] is silent on the issue of how the presence of two 128 such UPDATEs impacts the BGP decision process, and does not say 129 explicitly whether one or the other or both of these UPDATEs 130 should be propagated. This has led different implementations to 131 handle this situation in different ways. 133 o Much of [RFC3107] applies to the VPN-IPv4 ([RFC4364]) and VPN-IPv6 134 ([RFC4659]) address families, but those address families are not 135 mentioned in [RFC3107]. 137 This document replaces and obsoletes [RFC3107]. It defines a new BGP 138 Capability to be used when binding a sequence of labels to a prefix; 139 by using this Capability, the interoperability problems alluded to 140 above can be avoided. This document also removes the unimplemented 141 "Advertising Multiple Routes to a Destination" feature (see Section 4 142 of [RFC3107]), while specifying how to use [RFC7911] to provide the 143 same functionality. This document also addresses the issue of the 144 how UPDATEs that bind labels to a given prefix interact with UPDATEs 145 that advertise paths to that prefix but do not bind labels to it. 146 However, for backwards compatibility, it declares most of these 147 interactions to be matters of local policy. 149 The places where this specification differs from [RFC3107] are 150 indicated in the text. It is believed that implementations that 151 conform to the current document will interoperate correctly with 152 existing deployed implementations of [RFC3107]. 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in 157 [RFC2119]. 159 2. Using BGP to Bind an Address Prefix to One or More MPLS Labels 161 BGP may be used to advertise that a particular node, call it N, has 162 bound a particular MPLS label, or a particular sequence of MPLS 163 labels (organized as a contiguous part of an MPLS label stack), to a 164 particular address prefix. This is done by sending a Multiprotocol 165 BGP UPDATE message, i.e., an UPDATE message with an MP_REACH_NLRI 166 attribute ([RFC4760]). The "Network Address of Next Hop" field of 167 that attribute contains an IP address of node N. The label(s) and 168 the prefix are encoded in the NLRI field of the MP_REACH_NLRI. The 169 encoding of the NLRI field is specified in Sections 2.2 and 2.3. 171 If the prefix is an IPv4 address prefix or a VPN-IPv4 ([RFC4364]) 172 address prefix, the Address Family Identifier (AFI) of the 173 MP_REACH_NLRI attribute is set to 1. If the prefix is an IPv6 174 address prefix or a VPN-IPv6 prefix ([RFC4659]), the AFI is set to 2. 176 If the prefix is an IPv4 address prefix or an IPv6 address prefix, 177 the Subsequent Address Family Identifier (SAFI) field is set to 4. 178 If the prefix is a VPN-IPv4 address prefix or a VPN-IPv6 address 179 prefix, the SAFI is set to 128. 181 The use of SAFI 4 or SAFI 128 when the AFI is other than 1 or 2 is 182 outside the scope of this document. 184 This document does not specify the format of the "Network Address of 185 Next Hop" field of the MP_REACH_NLRI attribute. The format of the 186 next hop field depends upon a number of factors, and is discussed in 187 a number of other RFCs: see [RFC4364], [RFC4659], [RFC4798], and 188 [RFC5549]. 190 There are a variety of applications that make use of alternative 191 methods of using BGP to advertise MPLS label bindings. See, e.g., 193 [RFC7432], [RFC6514], or [TUNNEL-ENCAPS]. The method described in 194 the current document is not claimed to be the only way of using BGP 195 to advertise MPLS label bindings. Discussion of which method to use 196 for which application is outside the scope of the current document. 198 In the remainder of this document, we will use the term "SAFI-x 199 UPDATE" to refer to a BGP UPDATE message containing an MP_REACH_NLRI 200 attribute or an MP_UNREACH_NLRI attribute ([RFC4760]) whose SAFI 201 field contains the value x. 203 This document defines a BGP Optional Capabilities parameter 204 ([RFC5492]) known as the "Multiple Labels Capability". 206 o Unless this Capability is sent on a given BGP session by both of 207 that session's BGP speakers, a SAFI-4 or SAFI-128 UPDATE message 208 sent on that session from either speaker MUST bind a prefix to 209 only a single label, and MUST use the encoding of Section 2.2. 211 o If this Capability is sent by both BGP speakers on a given 212 session, an UPDATE message on that session, from either speaker, 213 MUST use the encoding of Section 2.3, and MAY bind a prefix to a 214 sequence of more than one label. 216 The encoding of the Multiple Labels Capability is specified in 217 Section 2.1. 219 Procedures for explicitly withdrawing a label binding are given in 220 Section 2.4. Procedures for changing the label(s) bound to a given 221 prefix by a given node are given in Section 2.5. 223 Procedures for propagating SAFI-4 and SAFI-128 UPDATEs are discussed 224 in Section 3. 226 When a BGP speaker installs and propagates a SAFI-4 or SAFI-128 227 update, and if it changes the value of the Network Address of Next 228 Hop field, it must program its data plane appropriately. This is 229 discussed in Section 4. 231 2.1. Multiple Labels Capability 233 [RFC5492] defines the "Capabilities Optional Parameter". A BGP 234 speaker can include a Capabilities Optional Parameter in a BGP OPEN 235 message. The Capabilities Optional Parameter is a triple including a 236 one-octet Capability Code, a one-octet Capability length, and a 237 variable-length Capability Value. 239 This document defines a Capability Code, known as the "Multiple 240 Labels Capability" code. IANA will assign a codepoint for this 241 Capability Code. (This Capability Code is new to this document and 242 does not appear in [RFC3107].) 244 If a BGP speaker has not sent the Multiple Labels Capability in its 245 BGP Open message on a particular BGP session, or if it has not 246 received the Multiple Labels Capability in the BGP Open message from 247 its peer on that BGP session, that BGP speaker MUST NOT send on that 248 session any UPDATE message that binds more than one MPLS label to any 249 given prefix. Further, when advertising the binding of a single 250 label to a prefix, the BGP speaker MUST use the encoding specified in 251 Section 2.2. 253 The value field of the Multiple Labels Capability (shown in Figure 1) 254 consists of one or more triples, where each triple consists of four 255 octets. The first two octets of a triple specify an AFI value, the 256 third octet specifies a SAFI value, and the fourth specifies a Count. 257 If one of the triples is , the Count is the maximum 258 number of labels that the BGP speaker sending the Capability can 259 process in a received UPDATE of the specified AFI/SAFI. If the count 260 is 255, then no limit has been placed on the number of labels that 261 can be processed in a received UPDATE of the specified AFI/SAFI. 263 Any implementation that sends a Multiple Labels Capability MUST be 264 able to support at least two labels in the NLRI. However, there may 265 be deployment scenarios in which a larger number of labels is needed. 267 0 1 2 3 268 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 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | AFI | SAFI | Count ~ 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 ~ AFI | SAFI | Count | 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 Figure 1: Value Field of Multiple Labels Capability 277 If the Capability contains more than one triple with a given AFI/ 278 SAFI, all but the first MUST be ignored. 280 A triple of the form or 281 MUST NOT be sent. If such a triple is received, it MUST be ignored. 283 A Multiple Labels Capability whose length is not a multiple of four 284 MUST be considered to be malformed. 286 [RFC4724] ("Graceful Restart Mechanism for BGP") describes a 287 procedure that allows routes learned over a given BGP session to be 288 maintained when the session fails and then restarts. This procedure 289 requires the entire RIB to be transmitted when the session restarts. 290 If the Multiple Labels Capability for a given AFI/SAFI had been 291 exchanged on the failed session, but is not exchanged on the 292 restarted session, then any prefixes advertised in that AFI/SAFI with 293 multiple labels MUST be explicitly withdrawn. Similarly, if the 294 maximum label count, specified in the Capability for a given AFI/SAFI 295 is reduced, any prefixes advertised with more labels than are valid 296 for the current session MUST be explicitly withdrawn. 298 [Enhanced-GR] ("Accelerated Routing Convergence for BGP Graceful 299 Restart") describes another procedure that allows the routes learned 300 over a given BGP session to be maintained when the session fails and 301 then restarts. These procedures MUST NOT be applied if either of the 302 following conditions hold: 304 o The Multiple Labels Capability for a given AFI/SAFI had been 305 exchanged prior to the restart, but has not been exchanged on the 306 restarted session. 308 o The Multiple Labels Capability for a given AFI/SAFI had been 309 exchanged with a given Count prior to the restart, but has been 310 exchanged with a smaller count on the restarted session. 312 If either of these conditions hold, the complete set of routes for of 313 the given AFI/SAFI MUST be exchanged. 315 If a BGP OPEN message contains multiple copies of the Multiple Labels 316 Capability, only the first copy is significant; subsequent copies 317 MUST be ignored. 319 If a BGP speaker has sent the Multiple Labels Capability in its BGP 320 OPEN message for a particular BGP session, and has also received the 321 Multiple Labels Capability in its peer's BGP OPEN message for that 322 session, and if both Capabilities specify AFI/SAFI x/y, then: 324 when using an UPDATE of AFI x and SAFI y to advertise the binding 325 of a label or sequence of labels to a given prefix, the BGP 326 speaker MUST use the encoding of Section 2.3. This encoding MUST 327 be used even if only one label is being bound to a given prefix. 329 If both BGP speakers of a given BGP session have sent the Multiple 330 Labels Capability, but AFI/SAFI x/y has not been specified in both 331 Capabilities, then UPDATES of AFI/SAFI x/y on that session MUST use 332 the encoding of Section 2.2, and such UPDATEs can only bind one label 333 to a prefix. 335 A BGP speaker SHOULD NOT send an UPDATE that binds more labels to a 336 given prefix than its peer is capable of receiving, as specified in 337 the Multiple Labels Capability sent by that peer. If a BGP speaker 338 receives an UPDATE that binds more labels to a given prefix than the 339 number of labels the BGP speaker is prepared to receive (as announced 340 in its Multiple Labels Capability), the BGP speaker MUST apply the 341 "treat-as-withdraw" strategy of [RFC7606] to that UPDATE. 343 Notwithstanding the number of labels that a BGP speaker has claimed 344 to be able to receive, its peer MUST NOT attempt to send more labels 345 than can be properly encoded in the NLRI field of the MP_REACH_NLRI 346 attribute. Please note that there is only a limited amount of space 347 in the NLRI field for labels: 349 o per [RFC4760] the size of this field is limited to 255 bits (not 350 255 octets), including the number of bits in the prefix; 352 o in a SAFI-128 update, the prefix is at least 64 bits long, and may 353 be as long as 192 bits (e.g., in a VPN-IPv6 host route). 355 2.2. NLRI Encoding when the Multiple Labels Capability is Not Used 357 If the Multiple Labels Capability has not been both sent and received 358 on a given BGP session, then in a BGP UPDATE on that session whose 359 MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations 360 specified in Section 2, the NLRI field is encoded as shown in 361 Figure 2: 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Length | Label |Rsrv |S| 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Prefix ~ 369 ~ | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Figure 2: NLRI With One Label 374 - Length: 376 The Length field consists of a single octet. It specifies the 377 length in bits of the remainder of the NLRI field. 379 Note that the length will always be the sum of 20 (number of bits 380 in label field) plus 3 (number of bits in Rsrv field) plus 1 381 (number of bits in S field) plus the length in bits of the prefix. 383 In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix 384 length will be 32 bits or less. In an MP_REACH_NLRI attribute 385 whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. 386 In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will 387 be 96 bits or less if the AFI is 1, and will be 192 bits or less 388 if the AFI is 2. 390 As specified in [RFC4760], the actual length of the NLRI field 391 will be the number of bits specified in the length field, rounded 392 up to the nearest integral number of octets. 394 - Label: 396 The Label field is a 20-bit field, containing an MPLS label value 397 (see [RFC3032]). 399 - Rsrv: 401 This 3-bit field SHOULD be set to zero on transmission, and MUST 402 be ignored on reception. 404 - S: 406 This 1-bit field MUST be set to one on transmission, and MUST be 407 ignored on reception. 409 Note that the UPDATE message not only advertises the binding between 410 the prefix and the label, it also advertises a path to the prefix via 411 the node identified in the "Network Address of Next Hop" field of the 412 MP_REACH_NLRI attribute. 414 [RFC3107] requires that if only a single label is bound to a prefix, 415 the S bit must be set. If the S bit is not set, [RFC3107] specifies 416 that additional labels will appear in the NLRI. However, some 417 implementations assume that the NLRI will contain only a single 418 label, and do not check the setting of the S bit. The procedures 419 specified in the current document will interwork with such 420 implementations. As long as the Multiple Labels Capability is not 421 sent and received by both BGP speakers on a given BGP session, this 422 document REQUIRES that only one label be specified in the NLRI, that 423 the S bit be set on transmission, and that it be ignored on 424 reception. 426 If the procedures of [RFC7911] are being used, a four-octet "path 427 identifier" (as defined in Section 3 of [RFC7911]) is part of the 428 NLRI, and precedes the Length field. 430 2.3. NLRI Encoding when the Multiple Labels Capability is Used 432 If the Multiple Labels Capability has been both sent and received on 433 a given BGP session, then in a BGP UPDATE on that session whose 434 MP_REACH_NLRI attribute contains one of the AFI/SAFI combinations 435 specified in Section 2, the NLRI field is encoded as shown in 436 Figure 3: 438 0 1 2 3 439 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 440 +-+-+-+-+-+-+-+-+ 441 | Length | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | Label |Rsrv |S~ 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 ~ Label |Rsrv |S| 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Prefix ~ 448 ~ | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 Figure 3: NLRI With Multiple Labels 453 - Length: 455 The Length field consists of a single octet. It specifies the 456 length in bits of the remainder of the NLRI field. 458 Note that for each label, the length is increased by 24 bits (20 459 bits in label field plus 3 bits in Rsrv field plus 1 S bit). 461 In an MP_REACH_NLRI attribute whose AFI/SAFI is 1/4, the prefix 462 length will be 32 bits or less. In an MP_REACH_NLRI attribute 463 whose AFI/SAFI is 2/4, the prefix length will be 128 bits or less. 464 In an MP_REACH_NLRI attribute whose SAFI is 128, the prefix will 465 be 96 bits or less if the AFI is 1, and will be 192 bits or less 466 if the AFI is 2. 468 As specified in [RFC4760], the actual length of the NLRI field 469 will be the number of bits specified in the length field, rounded 470 up to the nearest integral number of octets. 472 - Label: 474 The Label field is a 20-bit field, containing an MPLS label value 475 ([RFC3032]). 477 - Rsrv: 479 This 3-bit field SHOULD be set to zero on transmission, and MUST 480 be ignored on reception. 482 - S: 484 In all labels except the last (i.e., in all labels except the one 485 immediately preceding the prefix), the S bit MUST be 0. In the 486 last label, the S bit MUST be 1. 488 Note that failure to set the S bit in the last label will make it 489 impossible to parse the NLRI correctly. See Section 3 paragraph j 490 of [RFC7606] for a discussion of error handling when the NLRI 491 cannot be parsed. 493 Note that the UPDATE message not only advertises the binding between 494 the prefix and the labels, it also advertises a path to the prefix 495 via the node identified in the "next hop" field of the MP_REACH_NLRI 496 attribute. 498 If the procedures of [RFC7911] are being used, a four-octet "path 499 identifier" (as defined in Section 3 of [RFC7911]) is part of the 500 NLRI, and precedes the Length field. 502 2.4. How to Explicitly Withdraw the Binding of a Label to a Prefix 504 Suppose a BGP speaker has announced, on a given BGP session, the 505 binding of a given label or sequence of labels to a given prefix. 506 Suppose it now wishes to withdraw that binding. To do so, it may 507 send a BGP UPDATE message with an MP_UNREACH_NLRI attribute. The 508 NLRI field of this attribute is encoded as follows: 510 0 1 2 3 511 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 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Length | Compatibility | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 515 | Prefix ~ 516 ~ | 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 519 Figure 4: NLRI For Withdrawal 521 Upon transmission, the Compatibility field SHOULD be set to 0x800000. 522 Upon reception, the value of the Compatibility field MUST be ignored. 524 This encoding is used for explicitly withdrawing the binding, on a 525 given BGP session, between the specified prefix and whatever label or 526 sequence of labels had previously been bound by the procedures of 527 this document to that prefix on the given session. This encoding is 528 used whether or not the Multiple Labels Capability has been sent or 529 received on the session. Note that label/prefix bindings that were 530 not advertised on the given session cannot be withdrawn by this 531 method. (However, if the bindings were advertised on a previous 532 session with the same peer, and the current session is the result of 533 a "graceful restart" ([RFC4724]) of the previous session, then this 534 withdrawal method may be used.) 536 When using an MP_UNREACH_NLRI attribute to withdraw a route whose 537 NLRI was previously specified in an MP_REACH_NLRI attribute, the 538 lengths and values of the respective prefixes must match, and the 539 respective AFI/SAFIs must match. If the procedures of [RFC7911] are 540 being used, the respective values of the "path identifier" fields 541 must match as well. Note that the prefix length is not the same as 542 the NLRI length; to determine the prefix length of a prefix in an 543 MP_UNREACH_NLRI, the length of the Compatibility field must be 544 subtracted from the length of the NLRI. 546 An explicit withdrawal in a SAFI-x UPDATE on a given BGP session not 547 only withdraws the binding between the prefix and the label(s), it 548 also withdraws the path to that prefix that was previously advertised 549 in a SAFI-x UPDATE on that session. 551 [RFC3107] allowed one to specify a particular label value in the 552 Compatibility field. However, the functionality that required the 553 presence of a particular label value (or sequence of label values) 554 was never implemented, and that functionality is not present in the 555 current document. Hence the value of this field is of no 556 significance; there is never any reason for this field to contain a 557 label value or a sequence of label values. 559 [RFC3107] also allowed one to withdraw a binding without specifying 560 the label explicitly, by setting the Compatibility field to 0x800000. 561 However, some implementations set it to 0x000000. In order to ensure 562 backwards compatibility, it is RECOMMENDED by this document that the 563 Compatibility field be set to 0x800000, but it is REQUIRED that it be 564 ignored upon reception. 566 2.5. Changing the Label that is Bound to a Prefix 568 Suppose a BGP speaker, S1, has received on a given BGP session, a 569 SAFI-4 or SAFI-128 UPDATE, U1, that specifies label (or sequence of 570 labels) L1, prefix P, and next hop N1. As specified above, this 571 indicates that label (or sequence of labels) L1 is bound to prefix P 572 at node N1. Suppose that S1 now receives, on the same session, an 573 UPDATE, U2, of the same AFI/SAFI, that specifies label (or sequence 574 of labels) L2, prefix P, and the same next hop, N1. 576 o If [RFC7911] is not being used, UPDATE U2 MUST be interpreted as 577 meaning that L2 is now bound to P at N1, and that L1 is no longer 578 bound to P at N1. That is, the UPDATE U1 is implicitly withdrawn, 579 and is replaced by UPDATE U2. 581 o Suppose that [RFC7911] is being used, that UPDATE U1 has Path 582 Identifier I1, and that UPDATE U2 has Path Identifier I2. 584 * If I1 is the same as I2, UPDATE U2 MUST be interpreted as 585 meaning that L2 is now bound to P at N1, and that L1 is no 586 longer bound to P at N1. UPDATE U1 is implicitly withdrawn. 588 * If I1 is not the same as I2, U2 MUST be interpreted as meaning 589 that L2 is now bound to P at N1, but MUST NOT be interpreted as 590 meaning that L1 is no longer bound to P at N1. Under certain 591 conditions (specification of which is outside the scope of this 592 document), S1 may choose to load-balance traffic between the 593 path represented by U1 and the path represented by U2. To send 594 traffic on the path represented by U1, S1 uses the label(s) 595 advertised in U1; to send traffic on the path represented by 596 U2, S1 uses the label(s) advertised in U2. (Although these two 597 paths have the same next hop, one must suppose that they 598 diverge further downstream.) 600 Suppose a BGP speaker, S1, has received, on a given BGP session, a 601 SAFI-4 or SAFI-128 UPDATE that specifies label L1, prefix P, and next 602 hop N1. Suppose that S1 now receives, on a different BGP session, an 603 UPDATE, of the same AFI/SAFI, that specifies label L2, prefix P, and 604 the same next hop, N1. BGP speaker S1 SHOULD treat this as 605 indicating that N1 has at least two paths to P, and S1 MAY use this 606 fact to do load-balancing of any traffic that it has to send to P. 608 Note that this section discusses only the case where two UPDATEs have 609 the same next hop. Procedures for the case where two UPDATEs have 610 different next hops are adequately described in [RFC4271]. 612 3. Installing and/or Propagating SAFI-4 or SAFI-128 Routes 614 3.1. Comparability of Routes 616 Suppose a BGP speaker has received two SAFI-4 UPDATEs specifying the 617 same Prefix, and that either: 619 o the two UPDATEs are received on different BGP sessions, or 621 o the two UPDATES are received on the same session, add-paths is 622 used on that session, and the NLRIs of the two updates have 623 different path identifiers. 625 These two routes MUST be considered to be comparable, even if they 626 specify different labels. Thus the BGP bestpath selection procedures 627 (Section 9.1 of [RFC4271]) are applied to select one of them as the 628 better path. If the procedures of [RFC7911] are not being used on a 629 particular BGP session, only the best path is propagated on that 630 session. If the procedures of [RFC7911] are being used on a 631 particular BGP session, then both paths may be propagated on that 632 session, though with different path identifiers. 634 The same applies to SAFI-128 routes. 636 3.2. Modification of Label(s) Field When Propagating 638 3.2.1. When the Next Hop Field is Unchanged 640 When a SAFI-4 or SAFI-128 route is propagated, if the "Network 641 Address of Next Hop" field is left unchanged, the label field(s) MUST 642 also be left unchanged. 644 Note that a given route MUST NOT be propagated to a given peer if the 645 route's NLRI has multiple labels, but the "Multiple Labels" 646 Capability was not negotiated with the peer. Similarly, a given 647 route MUST NOT be propagated to a given peer if the route's NLRI has 648 more labels than the peer has announced (through its "Multiple 649 Labels" Capability) that it can handle. In either case, if a 650 previous route with the same AFI, SAFI, and prefix (but with fewer 651 labels) has already been propagated to the peer, that route MUST be 652 withdrawn from that peer, using the procedure of Section 2.4. 654 3.2.2. When the Next Hop Field is Changed 656 If the "Network Address of Next Hop" field is changed before a SAFI-4 657 or SAFI-128 route is propagated, the label field(s) of the propagated 658 route MUST contain the label(s) that that is (are) bound to the 659 prefix at the new next hop. 661 Suppose BGP speaker S1 has received an UPDATE that binds a particular 662 sequence of one or more labels to a particular prefix. If S1 chooses 663 to propagate this route after changing its next hop, S1 may change 664 the label in any of the following ways, depending upon local policy: 666 o A single label may be replaced by a single label, of the same or 667 different value. 669 o A sequence of multiple labels may be replaced by a single label. 671 o A single label may be replaced by a sequence of multiple labels. 673 o A sequence of multiple labels may be replaced by a sequence of 674 multiple labels; the number of labels may be left the same, or may 675 be changed. 677 Of course, when deciding whether to propagate, to a given BGP peer, 678 an UPDATE binding a sequence of more than one label, a BGP speaker 679 must attend to the information provided by the Multiple Labels 680 Capability (see Section 2.1). A BGP speaker MUST NOT send multiple 681 labels to a peer with which it has not exchanged the "Multiple 682 Labels" Capability, and MUST NOT send more labels to a given peer 683 than the peer has announced (via the "Multiple Labels" Capability) 684 than it can handle. 686 It is possible that a BGP speaker's local policy will tell it to 687 encode N labels in a given route's NLRI before propagating the route, 688 but that one of the BGP speaker's peers cannot handle N labels in the 689 NLRI. In this case, the BGP speaker has two choices: 691 o It can propagate the route to the given peer with fewer than N 692 labels. However, whether this makes sense, and if so, how to 693 choose the labels, is also a matter of local policy. 695 o It can decide not to propagate the route to the given peer. In 696 that case, if a previous route with the same AFI, SAFI, and prefix 697 (but with fewer labels) has already been propagated to that peer, 698 that route MUST be withdrawn from that peer, using the procedure 699 of Section 2.4. 701 4. Data Plane 703 In the following, we will use the phrase "node S tunnels packet P to 704 node N", where packet P is an MPLS packet. By this phrase, we mean 705 that node S encapsulates packet P and causes packet P to be delivered 706 to node N, in such a way that P's label stack before encapsulation 707 will be seen unchanged by N, but will not be seen by the nodes (if 708 any) between S and N. 710 If the tunnel is a Label Switched Path (LSP), encapsulating the 711 packet may be as simple as pushing on another MPLS label. If node N 712 is a layer 2 adjacency of node S, a layer 2 encapsulation may be all 713 that is needed. Other sorts of tunnels (e.g., IP tunnels, GRE 714 tunnels, UDP tunnels) may also be used, depending upon the particular 715 deployment scenario. 717 Suppose BGP speaker S1 receives a SAFI-4 or SAFI-128 BGP UPDATE with 718 an MP_REACH_NLRI specifying label L1, prefix P, and next hop N1, and 719 suppose S1 installs this route as its (or one of its) bestpath(s) 720 towards P. And suppose S1 propagates this route after changing the 721 next hop to itself and changing the label to L2. Suppose further 722 that S1 receives an MPLS data packet, and in the process of 723 forwarding that MPLS data packet, S1 sees label L2 rise to the top of 724 the packet's label stack. Then to forward the packet further, S1 725 must replace L2 with L1 as the top entry in the packet's label stack, 726 and S1 must then tunnel the packet to N1. 728 Suppose that the route received by S1 specified not a single label, 729 but a sequence of k labels , where L11 is the 730 first label appearing in the NLRI, and L1k is the last. And suppose 731 again that S1 propagates this route after changing the next hop to 732 itself and changing the label field to the single label L2. Suppose 733 further that S1 receives an MPLS data packet, and in the process of 734 forwarding that MPLS data packet, S1 sees label L2 rise to the top of 735 the packet's label stack. In this case, instead of simply replacing 736 L2 with L1, S1 removes L2 from the top of the label stack, and then 737 pushes labels L1k through L11 onto the label stack, such that L11 is 738 now at the top of the label stack. Then S1 must tunnel the packet to 739 N1. (Note that L1k will not be at the bottom of the packet's label 740 stack, and hence will not have the "bottom of stack" bit set, unless 741 L2 had previously been at the bottom of the packet's label stack.) 743 The above paragraph assumes that when S1 propagates a SAFI-4 or 744 SAFI-128 route after setting the next hop to itself, it replaces the 745 label or labels specified in the NLRI of that route with a single 746 label. However, it is also possible, as determined by local policy, 747 for a BGP speaker to specify multiple labels when it propagates a 748 SAFI-4 or SAFI-128 route after setting the next hop to itself. 750 Suppose, for example, that S1 supports context labels ([RFC5331]). 751 Let L21 be a context label supported by S1, and let L22 be a label 752 that is in the label space identified (at S1) by L21. Suppose S1 753 receives a SAFI-4 or SAFI-128 UPDATE whose prefix is P, whose label 754 field is , and whose next hop is N1. Before 755 propagating the UPDATE, S1 may set the next hop to itself (by 756 replacing N1 with S1), and may replace the label stack 757 with the pair of labels . 759 In this case, if S1 receives an MPLS data packet whose top label is 760 L21 and whose second label is L22, S1 will remove both L21 and L22 761 from the label stack, and replace them with . Note 762 that the fact that L21 is a context label is known only to S1; other 763 BGP speakers do not know how S1 will interpret L21 (or L22). 765 The ability to replace one or more labels by one or more labels can 766 provide great flexibility, but must be done carefully. Let's suppose 767 again that S1 receives an UPDATE that specifies prefix P, label stack 768 , and next hop N1. And suppose that S1 propagates 769 this UPDATE to BGP speaker S2 after setting next hop self and after 770 replacing the label field with . Finally, suppose 771 that S1 programs its data plane so that when it processes a received 772 MPLS packet whose top label is L21, it replaces L21 with 773 , and then tunnels the packet to N1. 775 In this case, BGP speaker S2 will have received a route with prefix 776 P, label field , and next hop S1. If S2 decides to 777 forward an IP packet according to this route, it will push 778 onto the packet's label stack, and tunnel the packet 779 to S1. S1 will replace L21 with , and will tunnel 780 the packet to N1. N1 will receive the packet with the following 781 label stack: . While this may be useful 782 in certain scenarios, it may provide unintended results in other 783 scenarios. 785 Procedures for choosing, setting up, maintaining, or determining the 786 liveness of a particular tunnel or type of tunnel, are outside the 787 scope of this document. 789 When pushing labels onto a packet's label stack, the Time-to-Live 790 (TTL) field ([RFC3032], [RFC3443]) and the Traffic Class (TC) field 791 ([RFC3032], [RFC5462]) of each label stack entry must of course be 792 set. This document does not specify any set of rules for setting 793 these fields; that is a matter of local policy. 795 This document does not specify any new rules for processing the label 796 stack of an incoming data packet. 798 It is a matter of local policy whether SAFI-4 routes can be used as 799 the basis for forwarding IP packets, or whether SAFI-4 routes can 800 only be used for forwarding MPLS packets. If BGP speaker S1 is 801 forwarding IP packets according to SAFI-4 routes, then consider an IP 802 packet with destination address D, such that P is the "longest prefix 803 match" for D from among the routes that are being used to forward IP 804 packets. And suppose the packet is being forwarded according to a 805 SAFI-4 route whose prefix is P, whose next hop is N1, and whose 806 sequence of labels is L1. To forward the packet according to this 807 route, S1 must create a label stack for the packet, push on the 808 sequence of labels L1, and then tunnel the packet to N1. 810 5. Relationship Between SAFI-4 and SAFI-1 Routes 812 It is possible that a BGP speaker will receive both a SAFI-1 route 813 for prefix P and a SAFI-4 route for prefix P. Different 814 implementations treat this situation in different ways. 816 For example, some implementations may regard SAFI-1 routes and SAFI-4 817 routes as completely independent, and may treat them in a "ships in 818 the night" fashion. In this case, bestpath selection for the two 819 SAFIs is independent, and there will be a best SAFI-1 route to P as 820 well as a best SAFI-4 route to P. Which packets get forwarded 821 according to the routes of which SAFI is then a matter of local 822 policy. 824 Other implementations may treat the SAFI-1 and SAFI-4 routes for a 825 given prefix as comparable, such that the best route to prefix P is 826 either a SAFI-1 route or a SAFI-4 route, but not both. In such 827 implementations, if load-balancing is done among a set of equal cost 828 routes, some of the equal cost routes may be SAFI-1 routes and some 829 may be SAFI-4 routes. Whether this is allowed is again a matter of 830 local policy. 832 Some implementations may allow a single BGP session to carry UPDATES 833 of both SAFI-1 and SAFI-4; other implementations may disallow this. 834 Some implementations that allow both SAFIs on the same session may 835 treat the receipt of a SAFI-1 route for prefix P on a given session 836 as an implicit withdrawal of a previous SAFI-4 route for prefix P on 837 that session, and vice versa. Other implementations may have 838 different behavior. 840 A BGP speaker may receive a SAFI-4 route over a given BGP session, 841 but may have other BGP sessions for which SAFI-4 is not enabled. In 842 this case, the BGP speaker MAY convert the SAFI-4 route to a SAFI-1 843 route and then propagate the result over the session on which SAFI-4 844 is not enabled. Whether this is done is a matter of local policy. 846 These differences in the behavior of different implementations may 847 result in unexpected behavior or lack of interoperability. In some 848 cases, it may be difficult or impossible to achieve the desired 849 policies with certain implementations or combinations of 850 implementations. 852 6. IANA Considerations 854 IANA is requested to assign a codepoint for "Multiple Labels 855 Capability" in the "BGP Capability Codes" registry, with this 856 document as the reference. 858 IANA is requested to modify the "BGP Capability Codes" registry to 859 mark Capability Code 4 ("Multiple routes to a destination") as 860 deprecated, with this document as the reference. 862 IANA is requested to change the reference for SAFI 4 in the 863 "Subsequent Address Family Identifiers (SAFI) Parameters" to this 864 document. IANA is also requested to add this document as a reference 865 for SAFI 128 in that same registry. 867 7. Security Considerations 869 The security considerations of the BGP specification ([RFC4271]) 870 apply. 872 If a BGP implementation, not conformant with the current document, 873 encodes multiple labels in the NLRI but has not sent and received the 874 "Multiple Labels" Capability, a BGP implementation that does conform 875 with the current document will likely reset the BGP session. 877 This document specifies that certain data packets be "tunneled" from 878 one BGP speaker to another. This requires that the packets be 879 encapsulated while in flight. This document does not specify the 880 encapsulation to be used. However, if a particular encapsulation is 881 used, the security considerations of that encapsulation are 882 applicable. 884 If a particular tunnel encapsulation does not provide integrity and 885 authentication, it is possible that a data packet's label stack can 886 be modified, through error or malfeasance, while the packet is in 887 flight. This can result in misdelivery of the packet. It should be 888 noted that the tunnel encapsulation (MPLS) most commonly used in 889 deployments of this specification does not provide integrity or 890 authentication; neither do the other tunnel encapsulations mentioned 891 in Section 4. 893 There are various techniques one can use to constrain the 894 distribution of BGP UPDATE messages. If a BGP UPDATE advertises the 895 binding of a particular (set of) label(s) to a particular address 896 prefix, such techniques can be used to control the set of BGP 897 speakers that are intended to learn of that binding. However, if BGP 898 sessions do not provide privacy, other routers may learn of that 899 binding. 901 When a BGP speaker processes a received MPLS data packet whose top 902 label it advertised, there is no guarantee that the label in question 903 was put on the packet by a router that was intended to know about 904 that label binding. If a BGP speaker is using the procedures of this 905 document, it may be useful for that speaker to distinguish its 906 "internal" interfaces from its "external" interfaces, and to avoid 907 advertising the same labels to BGP speakers reached on internal 908 interfaces as to BGP speakers reached on external interfaces. Then a 909 data packet can be discarded if its top label was not advertised over 910 the type of interface from which the packet was received. This 911 reduces the likelihood of forwarding packets whose labels have been 912 "spoofed" by untrusted sources. 914 8. Acknowledgements 916 This draft obsoletes RFC 3107. We wish to thank Yakov Rekhter, co- 917 author of RFC 3107, for his work on that document. We also wish to 918 thank Ravi Chandra, Enke Chen, Srihari R. Sangli, Eric Gray, and 919 Liam Casey for their review of and comments on that document. 921 We thank Alexander Okonnikov and David Lamparter for pointing out a 922 number of the errors in RFC 3107. 924 We wish to thank Lili Wang and Kaliraj Vairavakkalai for their help 925 and advice during the preparation of this document. 927 We also thank Mach Chen, Bruno Decraene, Jie Dong, Adrian Farrel, 928 Jeff Haas, Jonathan Hardwick, Jakob Heitz, Alexander Okonnikov, Keyur 929 Patel, Kevin Wang, and Lucy Yong for their review of and comments on 930 this document. 932 9. References 934 9.1. Normative References 936 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 937 Requirement Levels", BCP 14, RFC 2119, 938 DOI 10.17487/RFC2119, March 1997, . 941 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 942 Label Switching Architecture", RFC 3031, 943 DOI 10.17487/RFC3031, January 2001, . 946 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 947 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack 948 Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, 949 . 951 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 952 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 953 . 955 [RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing 956 in Multi-Protocol Label Switching (MPLS) Networks", 957 RFC 3443, DOI 10.17487/RFC3443, January 2003, 958 . 960 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 961 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 962 DOI 10.17487/RFC4271, January 2006, . 965 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 966 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 967 2006, . 969 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 970 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 971 IPv6 VPN", RFC 4659, DOI 10.17487/RFC4659, September 2006, 972 . 974 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 975 "Multiprotocol Extensions for BGP-4", RFC 4760, 976 DOI 10.17487/RFC4760, January 2007, . 979 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 980 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 981 Provider Edge Routers (6PE)", RFC 4798, 982 DOI 10.17487/RFC4798, February 2007, . 985 [RFC5462] Andersson, L. and R. Asati, "Multiprotocol Label Switching 986 (MPLS) Label Stack Entry: "EXP" Field Renamed to "Traffic 987 Class" Field", RFC 5462, DOI 10.17487/RFC5462, February 988 2009, . 990 [RFC5492] Scudder, J. and R. Chandra, "Capabilities Advertisement 991 with BGP-4", RFC 5492, DOI 10.17487/RFC5492, February 992 2009, . 994 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 995 Layer Reachability Information with an IPv6 Next Hop", 996 RFC 5549, DOI 10.17487/RFC5549, May 2009, 997 . 999 [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. 1000 Patel, "Revised Error Handling for BGP UPDATE Messages", 1001 RFC 7606, DOI 10.17487/RFC7606, August 2015, 1002 . 1004 9.2. Informative References 1006 [Enhanced-GR] 1007 Patel, K., Chen, E., Fernando, R., and J. Scudder, 1008 "Accelerated Routing Convergence for BGP Graceful 1009 Restart", internet-draft draft-ietf-idr-enhanced-gr-06, 1010 June 2016. 1012 [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y. 1013 Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724, 1014 DOI 10.17487/RFC4724, January 2007, . 1017 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 1018 Label Assignment and Context-Specific Label Space", 1019 RFC 5331, DOI 10.17487/RFC5331, August 2008, 1020 . 1022 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 1023 Encodings and Procedures for Multicast in MPLS/BGP IP 1024 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 1025 . 1027 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 1028 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 1029 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 1030 2015, . 1032 [RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder, 1033 "Advertisement of Multiple Paths in BGP", RFC 7911, 1034 DOI 10.17487/RFC7911, July 2016, . 1037 [TUNNEL-ENCAPS] 1038 Rosen, E., Patel, K., and G. Vandevelde, "The BGP Tunnel 1039 Encapulation Attribute", internet-draft draft-ietf-idr- 1040 tunnel-encaps-07, July 2017. 1042 Author's Address 1044 Eric C. Rosen 1045 Juniper Networks, Inc. 1046 10 Technology Park Drive 1047 Westford, Massachusetts 01886 1048 United States 1050 Email: erosen@juniper.net