idnits 2.17.1 draft-ietf-bess-mvpn-evpn-aggregation-label-08.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 (Using the creation date from RFC6514, updated by this document, for RFC5378 checks: 2006-08-01) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 20, 2022) is 825 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1000' on line 236 -- Looks like a reference, but probably isn't: '2000' on line 236 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-05 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft Juniper Networks 4 Updates: 7432, 6514, 7582 (if approved) E. Rosen 5 Intended status: Standards Track Individual 6 Expires: July 24, 2022 W. Lin 7 Juniper Networks 8 Z. Li 9 Huawei Technologies 10 I. Wijnands 11 Individual 12 January 20, 2022 14 MVPN/EVPN Tunnel Aggregation with Common Labels 15 draft-ietf-bess-mvpn-evpn-aggregation-label-08 17 Abstract 19 The MVPN specifications allow a single Point-to-Multipoint (P2MP) 20 tunnel to carry traffic of multiple VPNs. The EVPN specifications 21 allow a single P2MP tunnel to carry traffic of multiple Broadcast 22 Domains (BDs). These features require the ingress router of the P2MP 23 tunnel to allocate an upstream-assigned MPLS label for each VPN or 24 for each BD. A packet sent on a P2MP tunnel then carries the label 25 that is mapped to its VPN or BD (in some cases, a distinct upstream- 26 assigned label is needed for each flow.) Since each ingress router 27 allocates labels independently, with no coordination among the 28 ingress routers, the egress routers may need to keep track of a large 29 number of labels. The number of labels may need to be as large (or 30 larger) than the product of the number of ingress routers times the 31 number of VPNs or BDs. However, the number of labels can be greatly 32 reduced if the association between a label and a VPN or BD is made by 33 provisioning, so that all ingress routers assign the same label to a 34 particular VPN or BD. New procedures are needed in order to take 35 advantage of such provisioned labels. These new procedures also 36 apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document 37 updates RFCs 6514, 7432 and 7582 by specifying the necessary 38 procedures. 40 Requirements Language 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 44 "OPTIONAL" in this document are to be interpreted as described in BCP 45 14 [RFC2119] [RFC8174] when, and only when, they appear in all 46 capitals, as shown here. 48 Status of This Memo 50 This Internet-Draft is submitted in full conformance with the 51 provisions of BCP 78 and BCP 79. 53 Internet-Drafts are working documents of the Internet Engineering 54 Task Force (IETF). Note that other groups may also distribute 55 working documents as Internet-Drafts. The list of current Internet- 56 Drafts is at https://datatracker.ietf.org/drafts/current/. 58 Internet-Drafts are draft documents valid for a maximum of six months 59 and may be updated, replaced, or obsoleted by other documents at any 60 time. It is inappropriate to use Internet-Drafts as reference 61 material or to cite them other than as "work in progress." 63 This Internet-Draft will expire on July 24, 2022. 65 Copyright Notice 67 Copyright (c) 2022 IETF Trust and the persons identified as the 68 document authors. All rights reserved. 70 This document is subject to BCP 78 and the IETF Trust's Legal 71 Provisions Relating to IETF Documents 72 (https://trustee.ietf.org/license-info) in effect on the date of 73 publication of this document. Please review these documents 74 carefully, as they describe your rights and restrictions with respect 75 to this document. Code Components extracted from this document must 76 include Simplified BSD License text as described in Section 4.e of 77 the Trust Legal Provisions and are provided without warranty as 78 described in the Simplified BSD License. 80 Table of Contents 82 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 83 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 84 2.1. Problem Description . . . . . . . . . . . . . . . . . . . 4 85 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 5 86 2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 7 87 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 7 88 2.2.3. Summary of Label Allocation Methods . . . . . . . . . 9 89 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 90 3.1. Context Label Space ID Extended Community . . . . . . . . 10 91 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 95 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 13 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 98 8.2. Informative References . . . . . . . . . . . . . . . . . 14 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Terminologies 103 Familiarity with MVPN/EVPN protocols and procedures is assumed. Some 104 terminologies are listed below for convenience. 106 o BUM: Broadcast, Unknown Unicast, or Multicast (traffic). 108 o BD: Broadcast Domain. 110 o PMSI: Provider Multicast Service Interface - a pseudo interface 111 for a PE to send overlay/customer multicast traffic via underlay/ 112 provider tunnels. Includes I/S-PMSI (often referred to as x-PMSI) 113 for Inclusive/Selective-PMSI. 115 o IMET: Inclusive Multicast Ethernet Tag route. An EVPN specific 116 name for I-PMSI A-D route. 118 o PTA: PMSI Tunnel Attribute. A BGP attribute that may be attached 119 to an BGP-MVPN/EVPN A-D routes. 121 o ESI: Ethernet Segment Identifier. 123 2. Introduction 125 MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to 126 transport customer multicast traffic across a service provider's 127 backbone network. Often, a given P2MP tunnel carries the traffic of 128 only a single VPN. There are however procedures defined that allow a 129 single P2MP tunnel to carry traffic of multiple VPNs. In this case, 130 the P2MP tunnel is called an "aggregate tunnel". The PE router that 131 is the ingress node of an aggregate P2MP tunnel allocates an 132 "upstream-assigned MPLS label" [RFC5331] for each VPN, and each 133 packet sent on the P2MP tunnel carries the upstream-assigned MPLS 134 label that the ingress PE has bound to the packet's VPN. 136 Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or 137 PIM) to transport BUM traffic (Broadcast traffic, Unicast traffic 138 with an Unknown address, or Multicast traffic), across the provider 139 network. Often a P2MP tunnel carries the traffic of only a single 140 BD. However, there are procedures defined that allow a single P2MP 141 tunnel to be an "aggregate tunnel" that carries traffic of multiple 142 BDs. The procedures are analogous to the MVPN procedures -- the PE 143 router that is the ingress node of an aggregate P2MP tunnel allocates 144 an upstream-assigned MPLS label for each BD, and each packet sent on 145 the P2MP tunnel carries the upstream-assigned MPLS label that the 146 ingress PE has bound to the packet's BD. 148 MVPN and EVPN can also use BIER [RFC8279] to transmit multicast 149 traffic or BUM traffic [RFC8556] [I-D.ietf-bier-evpn]. Although BIER 150 does not explicitly set up P2MP tunnels, from the perspective of 151 MVPN/EVPN, the use of BIER transport is very similar to the use of 152 aggregate P2MP tunnels. When BIER is used, the PE transmitting a 153 packet (the "BFIR" [RFC8279]) must allocate an upstream-assigned MPLS 154 label for each VPN or BD, and the packets transmitted using BIER 155 transport always carry the label that identifies their VPN or BD. 156 (See [RFC8556] and [I-D.ietf-bier-evpn] for the details.) In the 157 remainder of this document, we will use the term "aggregate tunnels" 158 to include both P2MP tunnels and BIER transport. 160 When an egress PE receives a packet from an aggregate tunnel, it must 161 look at the upstream-assigned label carried by the packet, and must 162 interpret that label in the context of the ingress PE. Essentially, 163 each ingress PE has its own "context label space" [RFC5331] from 164 which it allocates its upstream-assigned labels. When an egress PE 165 looks up the upstream-assigned label carried by a given packet, it 166 looks it up in the context label space owned by the packet's ingress 167 PE. How an egress PE identifies the ingress PE of a given packet 168 depends on the tunnel type. 170 2.1. Problem Description 172 Note that these procedures may require a very large number of labels. 173 Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 174 VPN/BDs. Each ingress PE has to assign 1000 labels, and each egress 175 PE has to be prepared to interpret 1000 labels from each of the 176 ingress PEs. Since each ingress PE allocates labels from its own 177 label space and does not coordinate label assignments with others, 178 each egress PE must be prepared to interpret 1,000,000 upstream- 179 assigned labels (across 1000 context label spaces - one for each 180 ingress PE). This is an evident scaling problem. 182 At the present time, few if any MVPN/EVPN deployments use aggregate 183 tunnels, so this problem has not surfaced. However, the use of 184 aggregate tunnels is likely to increase due to the following two 185 factors: 187 o In EVPN, a single customer ("tenant") may have a large number of 188 BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may 189 become important, since each tunnel creates state at the 190 intermediate nodes. 192 o The use of BIER as transport for MVPN/EVPN is becoming more and 193 more attractive and feasible. 195 Note there are pros and cons with traditional P2MP tunnel aggregation 196 (vs. BIER), which are already discussed in Section 2.1.1 of 197 [RFC6513]. This document simply specifies a way to increase label 198 scaling when tunnel aggregation is used. 200 A similar problem also exists with EVPN ESI labels used for multi- 201 homing. A PE attached to a multi-homed Ethernet Segment (ES) 202 advertises an ESI label in its Ethernet A-D per Ethernet Segment 203 Route. The PE imposes the label when it sends frames received from 204 the ES to other PEs via a P2MP/BIER tunnel. A receiving PE that is 205 attached to the source ES will know from the ESI label that the 206 packet originated on the source ES, and thus will not transmit the 207 packet on its local attachment circuit to that ES. From the 208 receiving PE's point of view, the ESI label is (upstream-)allocated 209 from the source PE's label space, so the receiving PE needs to 210 maintain context label tables, one for each source PE, just like the 211 VRF/BD label case above. If there are 1,001 PEs, each attached to 212 1,000 ESes, this can require each PE to understand 1,000,000 ESI 213 labels. Notice that the issue exists even when no P2MP tunnel 214 aggregation (i.e. one tunnel used for multiple BDs) is used. 216 2.2. Proposed Solution 218 The number of labels could be greatly reduced if a central authority 219 assigned a label to each VPN, BD, or ES, and if all PEs used that 220 same label to represent a given VPN , BD, or ES. Then the number of 221 total number of labels needed would just be the sum of the number of 222 VPNs, BD, and/or ESes. 224 One method of achieving this is to reserve a portion of the label 225 space for assignment by a central authority. We refer to this 226 reserved portion as the "Domain-wide Common Block" (DCB) of labels. 227 This is analogous to the "Segment Routing Global Block" (SRGB) that 228 is described in [RFC8402]. The DCB is taken from the same label 229 space that is used for downstream-assigned labels, but each PE would 230 know not to allocate labels from that block for other purposes (e.g., 231 as a local label or for SRGB). A PE that is attached (via L3VPN VRF 232 interfaces or EVPN Access Circuits) would know by provisioning which 233 label from the DCB corresponds to which of its locally attached VPNs, 234 BDs, or ESes. 236 For example, all PEs could reserve a DCB [1000, 2000] and they are 237 all provisioned that label 1000 is for VPN 0, 1001 for VPN 1, and so 238 on so forth. Now only 1000 label instead of 1,000,000 labels are 239 needed for 1000 VPNs. 241 The definition of "domain" is loose - it simply includes all the 242 routers that share the same DCB. In this document, it only needs to 243 include all PEs of an MVPN/EVPN network. (Though if tunnel 244 segmentation [RFC6514] is used, each segmentation region could have 245 its own DCB. This will be explained in more detail later.) 247 The "domain" could also include all routers in the provider network, 248 making it not much different from a common SRGB across all the 249 routers. However, that is not necessarily as the labels used by PEs 250 for the purposes defined in this document will only rise to the top 251 of the label stack when traffic arrives the PEs. Therefore, it is 252 better to not include internal P routers in the "domain". That way 253 they do not have to aside the same DCB used for the purposes in this 254 document. 256 In some deployments, it may be impractical to allocate a DCB that is 257 large enough to contain labels for all the VPNs/BDs/ESes. In this 258 case, it may be necessary to allocate those labels from one or a few 259 separate context label spaces independent of each PE's default label 260 space (that the DCB belongs to). For example, if it is difficult to 261 have a DCB of 10,000 labels across all PEs for all the VPNs/BDs/ESes 262 that need to be supported, a separate context label space can be 263 dedicated to those 10,000 labels. Each separate context label space 264 is identified in the forwarding plane by a label from the DCB (which 265 does not need to be large). Each PE is provisioned with the label- 266 space-identifying DCB label and the common VPN/BD/ES labels allocated 267 from that context label space. When sending traffic, an ingress PE 268 imposes all necessary service labels (for the VPN/BD/ES) first, then 269 imposes the label-space-identifying DCB label. From the label-space- 270 identifying DCB label an egress PE can determine the label space 271 where the inner VPN/BD/ES label is looked up. 273 The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes 274 that certain MPLS labels are allocated from a context label space 275 owned by a particular ingress PE. In this document, we augment the 276 signaling procedures so that it is possible to signal that a 277 particular label is from the DCB, rather than from an ingress PE's 278 context label space. We also augment the signaling so that it is 279 possible to indicate that a particular label is from an identified 280 context label space that is different than the ingress PE's own 281 context label space. 283 Notice that, the VPN/BD/ES-identifying labels from the DCB or from 284 those few context label spaces are very similar to VNIs in VXLAN. 285 Allocating a label from the DCB or from those a few context label 286 spaces and communicating them to all PEs should not be different from 287 allocating VNIs, and should be feasible in today's networks since 288 controllers are used more and more widely. 290 2.2.1. MP2MP Tunnels 292 MP2MP tunnels present the same problem that can be solved the same 293 way. 295 Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP 296 tunnels are used for MVPN, the root of the MP2MP tunnel may need to 297 allocate and advertise "PE Distinguisher Labels". RFC 7582 states 298 that these labels are upstream-assigned, from the label space used by 299 the root node for its upstream-assigned labels. 301 It is REQUIRED by this document that the PE Distinguisher labels 302 allocated by a particular node come from the same label space that 303 the node uses to allocate its VPN-identifying labels. 305 2.2.2. Segmented Tunnels 307 There are some additional issues to be considered when MVPN or EVPN 308 is using "tunnel segmentation" (see [RFC6514], [RFC7524], and 309 [I-D.ietf-bess-evpn-bum-procedure-updates] Sections 5 and 6). 311 2.2.2.1. Selective Tunnels 313 For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and 314 [I-D.ietf-bess-evpn-bum-procedure-updates] Section 4), the procedures 315 outlined above work only if tunnel segmentation is not used. 317 A selective tunnel carries one or more particular sets of flows to a 318 particular subset of the PEs that attach to a given VPN or BD. Each 319 set of flows is identified by a Selective PMSI A-D route [RFC6514]. 320 The PTA of the S-PMSI route identifies the tunnel used to carry the 321 corresponding set of flows. Multiple S-PMSI routes can identify the 322 same tunnel. 324 When tunnel segmentation is applied to a S-PMSI, certain nodes are 325 "segmentation points". A segmentation point is a node at the 326 boundary between two "segmentation regions". Let's call these 327 "region A" and "region B". A segmentation point is an egress node 328 for one or more selective tunnels in region A, and an ingress node 329 for one or more selective tunnels in region B. A given segmentation 330 point must be able to receive traffic on a selective tunnel from 331 region A, and label switch the traffic to the proper selective tunnel 332 in region B. 334 Suppose one selective tunnel (call it T1) in region A is carrying two 335 flows, Flow-1 and Flow-2, identified by S-PMSI route Route-1 and 336 Route-2 respectively. However, it is possible that, in region B, 337 Flow-1 is not carried by the same selective tunnel that carries Flow- 338 2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 339 and Flow-2 by tunnel T3. Then when the segmentation point receives 340 traffic from T1, it must be able to label switch Flow-1 from T1 to 341 T2, while also label switching Flow-2 from T1 to T3. This implies 342 that Route-1 and Route-2 must signal different labels in the PTA. 343 For comparison, when segmentation is not used, they can all use the 344 common per-VPN/BD DCB label. 346 In this case, it is not practical to have a central authority assign 347 domain-wide unique labels to individual S-PMSI routes. To address 348 this problem, all PEs can be assigned disjoint label blocks in those 349 few context label spaces, and each will allocate labels for segmented 350 S-PMSI independently from its assigned label block that is different 351 from any other PE's. For example, PE1 allocates from label block 352 [101~200], PE2 allocates from label block [201~300], and so on. 354 Allocating from disjoint label blocks can be used for VPN/BD/ES 355 labels as well, though it does not address the original scaling 356 issue, because there would be one million labels allocated from those 357 a few context label spaces in the original example, instead of just 358 one thousand common labels. 360 2.2.2.2. Per-PE/Region Tunnels 362 Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) 363 or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) 364 tunnels, labels need to be allocated per PMSI route. In case of per- 365 PE PMSI route, the labels should be allocated from the label block 366 allocated to the advertising PE. In case of per-AS/region PMSI 367 route, different ASBR/RBRs attached to the same source AS/region will 368 advertise the same PMSI route. The same label could be used when the 369 same route is advertised by different ASBRs/RBRs, though a simpler 370 way is for each ASBR/RBR to allocate its own label from the label 371 block allocated to itself. 373 In the rest of the document, we call the label allocated for a 374 particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES 375 labels. Notice that using per-PMSI label in case of per-PE PMSI 376 still has the original scaling issue associated with the upstream 377 allocated label, so per-region PMSIs should be preferred. Within 378 each AS/region, per-PE PMSIs are still used though they do not go 379 across border and per-VPN/BD labels can still be used. 381 Note that, when a segmentation point re-advertise a PMSI route to the 382 next segment, it does not need to re-advertise a new label unless the 383 upstream or downstream segment uses Ingress Replication. [note - 384 future revision may extend the applicability of this document to 385 Ingress Replication as well] 387 2.2.2.3. Alternative to the per-PMSI Label Allocation 389 The per-PMSI label allocation in case of segmentation, whether for 390 S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to 391 be able to label switch traffic w/o having to do IP or MAC lookup in 392 VRFs (the segmentation points typically do not have those VRFs at 393 all). If the label scaling becomes a concern, alternatively the 394 segmentation points could use (C-S,C-G) lookup in VRFs for flows 395 identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/ 396 BD to share the a VPN/BD-identifying label that leads to lookup in 397 the VRFs. That label should be different from the label used in the 398 per-PE/region I-PMSIs though, so that the segmentation points can 399 label switch other traffic (not identified by those S-PMSIs). 400 However, this moves the scaling problem from the number of labels to 401 the number of (C-S/*,C-G) routes in VRFs on the segmentation points. 403 2.2.3. Summary of Label Allocation Methods 405 In summary, labels can be allocated and advertised the following 406 ways: 408 1. A central authority allocates per-VPN/BD/ES labels from the DCB. 409 PEs advertise the labels with an indication that they are from 410 the DCB. 412 2. A central authority allocates per-VPN/BD/ES labels from a few 413 common context label spaces, and allocate labels from the DCB to 414 identify those context label spaces. PEs advertise the VPN/BD 415 labels along with the context-identifying labels. 417 3. A central authority assigns disjoint label blocks from those a 418 few context label spaces to each PE, and allocate labels from the 419 DCB to identify the context label spaces. Each PE allocates 420 labels from its assigned label block independently for its 421 segmented S-PMSI, along with the context-identifying labels. 423 Option 1 is simplest, but it requires that all the PEs set aside a 424 common label block for the DCB that is large enough for all the 425 VPNs/BDs/ESes combined. Option 3 is needed only for segmented 426 selective tunnels that are set up dynamically. Multiple options 427 could be used in any combination depending on the deployment 428 situation. 430 3. Specification 431 3.1. Context Label Space ID Extended Community 433 Context Label Space ID Extended Community is a new Transitive Opaque 434 EC with the following structure (Sub-Type value to be assigned by 435 IANA): 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 | 0x03 or 0x43 | Sub-Type | ID-Type | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | ID-Value | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 o ID-Type: A 2-octet field that specifies the type of Label Space 446 ID. In this document, the ID-Type is 0, indicating that the ID- 447 Value field is a label. 449 o ID-Value: A 4-octet field that specifies the value of Label Space 450 ID. When it is a label (with ID-Value 0), the most significant 451 20-bit is set to the label value. 453 This document introduces a DCB flag (to be assigned by IANA) in the 454 "Additional PMSI Tunnel Attribute Flags" BGP Extended Community 455 [RFC7902]. 457 In the remainder of the document, when we say a BGP-MVPN/EVPN A-D 458 route "carries DCB-flag" or "has DCB-flag attached" we mean the 459 following: 461 o The route carries a PMSI Tunnel Attribute (PTA) and its Flags 462 field has the Extension bit set 464 o The route carries an "Additional PMSI Tunnel Attribute Flags" EC 465 and its DCB flag is set 467 3.2. Procedures 469 The protocol and procedures specified in this section need not be 470 applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used 471 for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi- 472 homing. 474 By means outside the scope of this document, each VPN/BD/ES is 475 assigned a label from the DCB or one of those few context label 476 spaces, and every PE that is part of the VPN/BD/ES is aware of the 477 assignment. The ES label and the BD label MUST be assigned from the 478 same label space. If PE Distinguisher labels are used [RFC7582], 479 they MUST be allocated from the same label space as well. 481 In case of tunnel segmentation, each PE is also assigned a disjoint 482 label block from one of those few context label spaces and it 483 allocates labels for its segmented PMSI routes from its assigned 484 label block. 486 When a PE originates/re-advertises an x-PMSI/IMET route, the route 487 MUST carry a DCB-flag if and only if the label in its PTA is assigned 488 from the DCB. 490 If the VPN/BD/ES/PMSI label is assigned from one of those few context 491 label spaces, a Context Label Space ID Extended Community is attached 492 to the route. The ID-Type in the EC is set to 0 and the ID-Value is 493 set to a label allocated from the DCB and identifies the context 494 label space. When an ingress PE sends traffic, it imposes the DCB 495 label that identifies the context label space after it imposes the 496 label (that is advertised in the PTA's Label field of the x-PMSI/IMET 497 route) for the VPN/BD and/or the label (that is advertised in the ESI 498 Label EC) for the ESI, and then imposes the encapsulation for the 499 transport tunnel. 501 When a PE receives an x-PMSI/IMET route with the Context Label Space 502 ID EC, it MUST program its default MPLS forwarding table to map the 503 label in the EC that identifies the context label space to a 504 corresponding context label table in which the next label lookup is 505 done for traffic that this PE receives. 507 Then, the receiving PE MUST program the label in the PTA or ESI Label 508 EC into either the default mpls forwarding table (if the route 509 carries the DCB-flag) or the context label table (if the Context 510 Label Space ID EC is present) according to the x-PMSI/IMET route. 512 A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and 513 attach the Context Label Space ID EC in the route. A PE MUST ignore 514 a received route with both the DCB-flag and the Context Label Space 515 ID EC attached, treating as if it was not received. If neither the 516 DCB-flag nor the Context Label Space ID EC is attached, the label in 517 the PTA or ESI Label EC MUST be treated as the upstream allocated 518 from the source PE's label space, and procedures in 519 [RFC6514][RFC7432] MUST be followed. 521 In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the 522 same tunnel, one of the following conditions MUST be met, so that a 523 receiving PE can correctly interpret the label that follows the 524 tunnel label in the right context. 526 o They MUST all have the DCB-flag, or, 528 o They MUST all carry the Context Label Space ID EC, or, 530 o None of them has the DCB-flag, or, 532 o None of them carry the Context Label Space ID EC. 534 4. Security Considerations 536 This document allows three methods (Section 2.2.3) of label 537 allocation for MVPN/EVPN PEs and specifies corresponding signaling 538 and procedures. The first method is the equivalent of using common 539 SRGBs from the regular per platform label space. The second one is 540 the equivalent of using common SRGBs from a third party's label 541 space, which is also considered as an upstream-assigned label 542 allocation [RFC5331]. The third method is a variation of the second, 543 in that the third party's label space is divided into disjoint blocks 544 for use by different PEs, who will use labels from their respective 545 block to send traffic. In all cases, a receiving PE is able to 546 identify one of a few LFIBs to forward incoming labeled traffic. 548 Therefore, this document does not introduce new security issues 549 besides what have been discussed in existing specifications [RFC5331] 550 [RFC6514] [RFC7432] [RFC8402]. 552 5. IANA Considerations 554 IANA has made the following assignments: 556 o Bit 47 (DCB) from the "Additional PMSI Tunnel Attribute Flags" 557 registry 559 Bit Flag Name Reference 560 -------- ---------------------- ------------- 561 47 DCB (temporary) This document 563 o Sub-type 0x08 for "Context Label Space ID Extended Community" from 564 the "Transitive Opaque Extended Community Sub-Types" registry 566 Sub-Type Value Name Reference 567 -------------- ---------------------- ------------- 568 0x08 Context Label Space ID This document 569 Extended Community 571 6. Acknowledgements 573 The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie 574 for their review of, comments on and suggestions for this document. 576 7. Contributors 578 The following also contributed to this document. 580 Selvakumar Sivaraj 581 Juniper Networks 583 Email: ssivaraj@juniper.net 585 8. References 587 8.1. Normative References 589 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 590 Requirement Levels", BCP 14, RFC 2119, 591 DOI 10.17487/RFC2119, March 1997, 592 . 594 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 595 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 596 2012, . 598 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 599 Encodings and Procedures for Multicast in MPLS/BGP IP 600 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 601 . 603 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 604 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 605 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 606 2015, . 608 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 609 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 610 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 611 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 612 . 614 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 615 "Multicast Virtual Private Network (MVPN): Using 616 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 617 July 2015, . 619 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 620 P-Multicast Service Interface Tunnel Attribute Flags", 621 RFC 7902, DOI 10.17487/RFC7902, June 2016, 622 . 624 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 625 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 626 May 2017, . 628 8.2. Informative References 630 [I-D.ietf-bess-evpn-bum-procedure-updates] 631 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 632 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 633 bess-evpn-bum-procedure-updates-14 (work in progress), 634 November 2021. 636 [I-D.ietf-bier-evpn] 637 Zhang, Z., Przygienda, A., Sajassi, A., and J. Rabadan, 638 "EVPN BUM Using BIER", draft-ietf-bier-evpn-05 (work in 639 progress), December 2021. 641 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 642 Label Assignment and Context-Specific Label Space", 643 RFC 5331, DOI 10.17487/RFC5331, August 2008, 644 . 646 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 647 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 648 Explicit Replication (BIER)", RFC 8279, 649 DOI 10.17487/RFC8279, November 2017, 650 . 652 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 653 Decraene, B., Litkowski, S., and R. Shakir, "Segment 654 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 655 July 2018, . 657 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 658 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 659 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 660 2019, . 662 Authors' Addresses 663 Zhaohui Zhang 664 Juniper Networks 666 EMail: zzhang@juniper.net 668 Eric Rosen 669 Individual 671 EMail: erosen52@gmail.com 673 Wen Lin 674 Juniper Networks 676 EMail: wlin@juniper.net 678 Zhenbin Li 679 Huawei Technologies 681 EMail: lizhenbin@huawei.com 683 IJsbrand Wijnands 684 Individual 686 EMail: ice@braindump.be