idnits 2.17.00 (12 Aug 2021) /tmp/idnits11254/draft-ietf-bess-mvpn-evpn-aggregation-label-06.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 (April 16, 2021) is 400 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) == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-05) exists of draft-ietf-bier-evpn-04 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: October 18, 2021 W. Lin 7 Juniper Networks 8 Z. Li 9 Huawei Technologies 10 I. Wijnands 11 Individual 12 April 16, 2021 14 MVPN/EVPN Tunnel Aggregation with Common Labels 15 draft-ietf-bess-mvpn-evpn-aggregation-label-06 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 26 upstream-assigned is needed for each flow.) Since each ingress 27 router 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 October 18, 2021. 65 Copyright Notice 67 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . 9 91 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 92 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 94 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 95 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 96 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 98 8.2. Informative References . . . . . . . . . . . . . . . . . 13 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 context label space, and the ingress PEs do not coordinate their 178 label assignments, each egress PE must be prepared to interpret 179 1,000,000 upstream-assigned labels. This is an evident scaling 180 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 Segment route for the ES. 203 The PE imposes the label when it sends frames received from the ES to 204 other PEs via a P2MP/BIER tunnel. A receiving PE that is attached to 205 the source ES will know from the ESI label that the packet originated 206 on the source ES, and thus will not transmit the packet on its local 207 attachment circuit to that ES. From the receiving PE's point of 208 view, the ESI label is (upstream-)allocated from the source PE's 209 label space, so the receiving PE needs to maintain context label 210 tables, one for each source PE, just like the VRF/BD label case 211 above. If there are 1,001 PEs, each attached to 1,000 ESes, this can 212 require each PE to understand 1,000,000 ESI labels. Notice that the 213 issue exists even when no P2MP tunnel aggregation (i.e. one tunnel 214 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. The definition of "domain" is loose - it simply 235 includes all the routers that share the same DCB. In this document, 236 it only needs to includes all PEs of an MVPN/EVPN network. (Though 237 if tunnel segmentation [RFC6514] is used, each segmentation region 238 could have its own DCB. This will be explained in more detail 239 later.) 240 The "domain" could also include all routers in the provider network, 241 making it not much different from a common SRGB across all the 242 routers. However, that is not necessarily as the labels used by PEs 243 for the purposes defined in this document will only rise to the top 244 of the label stack when traffic arrives the PEs. Therefore, it is 245 better to not include internal P routers in the "domain". That way 246 they do not have to aside the same DCB used for the purposes in this 247 document. 249 In some deployments, it may be impractical to allocate a DCB that is 250 large enough to contain labels for all the VPNs/BDs/ESes. In this 251 case, it may be necessary to allocate those labels from a context 252 label space. However, it is not necessary for each ingress PE to 253 have its own context label space. Instead, one (or some small 254 number) of context label spaces can be dedicated to such labels. 255 Each ingress PE would be provisioned to know both the context label 256 space identifier and the label for each VPN/BD/ES. 258 The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes 259 that certain MPLS labels are allocated from a context label space 260 owned by a particular ingress PE. In this document, we augment the 261 signaling procedures so that it is possible to signal that a 262 particular label is from the DCB, rather than from an ingress PE's 263 context label space. We also augment the signaling so that it is 264 possible to indicate that a particular label is from an identified 265 context label space that is different than the ingress PE's own 266 context label space. 268 Notice that, the VPN/BD/ES-identifying labels from the DCB or from 269 those few context label spaces are very similar to VNIs in VXLAN. 270 Allocating a label from the DCB or from those a few context label 271 spaces and communicating them to all PEs should not be different from 272 allocating VNIs, and should be feasible in today's networks since 273 controllers are used more and more widely. 275 2.2.1. MP2MP Tunnels 277 MP2MP tunnels present the same problem that can be solved the same 278 way. 280 Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP 281 tunnels are used for MVPN, the root of the MP2MP tunnel may need to 282 allocate and advertise "PE Distinguisher Labels". RFC 7582 states 283 that these labels are upstream-assigned, from the label space used by 284 the root node for its upstream-assigned labels. 286 It is REQUIRED by this document that the PE Distinguisher labels 287 allocated by a particular node come from the same source that the 288 node uses to allocate its VPN-identifying labels. 290 2.2.2. Segmented Tunnels 292 There are some additional issues to be considered when MVPN or EVPN 293 is using "tunnel segmentation" (see [RFC6514], [RFC7524], and 294 [I-D.ietf-bess-evpn-bum-procedure-updates] Sections 5 and 6). 296 2.2.2.1. Selective Tunnels 298 For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and 299 [I-D.ietf-bess-evpn-bum-procedure-updates] Section 4), the procedures 300 outlined above work only if tunnel segmentation is not used. 302 A selective tunnel carries one or more particular sets of flows to a 303 particular subset of the PEs that attach to a given VPN or BD. Each 304 set of flows is identified by a Selective PMSI A-D route [RFC6514]. 305 The PTA of the S-PMSI route identifies the tunnel used to carry the 306 corresponding set of flows. Multiple S-PMSI routes can identify the 307 same tunnel. 309 When tunnel segmentation is applied to a S-PMSI, certain nodes are 310 "segmentation points". A segmentation point is a node at the 311 boundary between two "segmentation regions". Let's call these 312 "region A" and "region B". A segmentation point is an egress node 313 for one or more selective tunnels in region A, and an ingress node 314 for one or more selective tunnels in region B. A given segmentation 315 point must be able to receive traffic on a selective tunnel from 316 region A, and label switch the traffic to the proper selective tunnel 317 in region B. 319 Suppose one selective tunnel (call it T1) in region A is carrying two 320 flows, Flow-1 and Flow-2, identified by S-PMSI route Route-1 and 321 Route-2 respectively. However, it is possible that, in region B, 322 Flow-1 is not carried by the same selective tunnel that carries Flow- 323 2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 324 and Flow-2 by tunnel T3. Then when the segmentation point receives 325 traffic from T1, it must be able to label switch Flow-1 from T1 to 326 T2, while also label switching Flow-2 from T1 to T3. This implies 327 that Route-1 and Route-2 must signal different labels in the PTA. 329 In this case, it is not practical to have a central authority assign 330 domain-wide unique labels to individual S-PMSI routes. To address 331 this problem, all PEs can be assigned disjoint label blocks in those 332 few context label spaces, and each will allocate labels for segmented 333 S-PMSI independently from its assigned label block that is different 334 from any other PE's. For example, PE1 allocates from label block 335 [101~200], PE2 allocates from label block [201~300], and so on. 337 Allocating from disjoint label blocks can be used for VPN/BD/ES 338 labels as well, though it does not address the original scaling 339 issue, because there would be one million labels allocated from those 340 a few context label spaces in the original example, instead of just 341 one thousand common labels. 343 2.2.2.2. Per-PE/Region Tunnels 345 Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) 346 or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) 347 tunnels, labels need to be allocated per PMSI route. In case of per- 348 PE PMSI route, the labels should be allocated from the label block 349 allocated to the advertising PE. In case of per-AS/region PMSI 350 route, different ASBR/RBRs attached to the same source AS/region will 351 advertise the same PMSI route. The same label could be used when the 352 same route is advertised by different ASBRs/RBRs, though a simpler 353 way is for each ASBR/RBR to allocate its own label from the label 354 block allocated to itself. 356 In the rest of the document, we call the label allocated for a 357 particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES 358 labels. Notice that using per-PMSI label in case of per-PE PMSI 359 still has the original scaling issue associated with the upstream 360 allocated label, so per-region PMSIs should be preferred. Within 361 each AS/region, per-PE PMSIs are still used though they do not go 362 across border and per-VPN/BD labels can still be used. 364 Note that, when a segmentation point re-advertise a PMSI route to the 365 next segment, it does not need to re-advertise a new label unless the 366 upstream or downstream segment uses Ingress Replication. [note - 367 future revision may extend the applicability of this document to 368 Ingress Replication as well] 370 2.2.2.3. Alternative to the per-PMSI Label Allocation 372 The per-PMSI label allocation in case of segmentation, whether for 373 S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to 374 be able to label switch traffic w/o having to do IP or MAC lookup in 375 VRFs (the segmentation points typically do not have those VRFs at 376 all). If the label scaling becomes a concern, alternatively the 377 segmentation points could use (C-S,C-G) lookup in VRFs for flows 378 identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/ 379 BD to share the a VPN/BD-identifying label that leads to lookup in 380 the VRFs. That label should be different from the label used in the 381 per-PE/region I-PMSIs though, so that the segmentation points can 382 label switch other traffic (not identified by those S-PMSIs). 383 However, this moves the scaling problem from the number of labels to 384 the number of (C-S/*,C-G) routes in VRFs on the segmentation points. 386 2.2.3. Summary of Label Allocation Methods 388 In summary, labels can be allocated and advertised the following 389 ways: 391 1. A central authority allocates per-VPN/BD/ES labels from the DCB. 392 PEs advertise the labels with an indication that they are from 393 the DCB. 395 2. A central authority allocates per-VPN/BD/ES labels from a few 396 common context label spaces, and allocate labels from the DCB to 397 identify those context label spaces. PEs advertise the VPN/BD 398 labels along with the context-identifying labels. 400 3. A central authority assigns disjoint label blocks from those a 401 few context label spaces to each PE, and allocate labels from the 402 DCB to identify the context label spaces. Each PE allocates 403 labels from its assigned label block independently for its 404 segmented S-PMSI, along with the context-identifying labels. 406 Option 1 is simplest, but it requires that all the PEs set aside a 407 common label block for the DCB that is large enough for all the 408 VPNs/BDs/ESes combined. Option 3 is needed only for segmented 409 selective tunnels that are set up dynamically. Multiple options 410 could be used in any combination depending on the deployment 411 situation. 413 3. Specification 415 3.1. Context Label Space ID Extended Community 417 Context Label Space ID Extended Community is a new Transitive Opaque 418 EC with the following structure (Sub-Type value to be assigned by 419 IANA): 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | 0x03 or 0x43 | Sub-Type | ID-Type | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | ID-Value | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 o ID-Type: A 2-octet field that specifies the type of Label Space 430 ID. In this document, the ID-Type is 0, indicating that the ID- 431 Value field is a label. 433 o ID-Value: A 4-octet field that specifies the value of Label Space 434 ID. When it is a label (with ID-Value 0), the most significant 435 20-bit is set to the label value. 437 This document introduces a DCB-bit (to be assigned by IANA) in the 438 "Additional PMSI Tunnel Attribute Flags" BGP Extended Community 439 [RFC7902]. 441 In the remainder of the document, when we say a BGP-MVPN/EVPN A-D 442 route "carries DCB-flag" or "has DCB-flag attached" we mean the 443 following: 445 o The route carries a PMSI Tunnel Attribute (PTA) and its Flags 446 field has the Extension bit set 448 o The route carries an "Additional PMSI Tunnel Attribute Flags" EC 449 and its DCB-bit is set 451 3.2. Procedures 453 The protocol and procedures specified in this section need not be 454 applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used 455 for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi- 456 homing. 458 By means outside the scope of this document, each VPN/BD/ES is 459 assigned a label from the DCB or one of those few context label 460 spaces, and every PE that is part of the VPN/BD/ES is aware of the 461 assignment. The ES label and the BD label MUST be assigned from the 462 same source. If PE Distinguisher labels are used [RFC7582], they 463 MUST be allocated from the same source as well. 465 In case of tunnel segmentation, each PE is also assigned a disjoint 466 label block from one of those few context label spaces and it 467 allocates labels for its segmented PMSI routes from its assigned 468 label block. 470 When a PE originates/re-advertises an x-PMSI/IMET route, the route 471 MUST carry a DCB-flag if and only if the label in its PTA is assigned 472 from the DCB. 474 If the VPN/BD/PMSI label is assigned from one of those few context 475 label spaces, a Context Label Space ID Extended Community is attached 476 to the route. The ID-Type in the EC is set to 0 and the ID-Value is 477 set to a label allocated from the DCB and identifies the context 478 label space. When an ingress PE sends traffic, it imposes the DCB 479 label that identifies the context label space after it imposes the 480 label (that is advertised in the PTA's Label field of the x-PMSI/IMET 481 route) for the VPN/BD and/or the label (that is advertised in the ESI 482 Label EC) for the ESI, and then imposes the encapsulation for the 483 transport tunnel. 485 When a PE receives an x-PMSI/IMET route with the Context Label Space 486 ID EC, it MUST program its default MPLS forwarding table to map the 487 label in the EC that identifies the context label space to a 488 corresponding context label table in which the next label lookup is 489 done for traffic that this PE receives. 491 Then, the receiving PE MUST program the label in the PTA or ESI Label 492 EC into either the default mpls forwarding table (if the route 493 carries the DCB-flag) or the context label table (if the Context 494 Label Space ID EC is present) according to the x-PMSI/IMET route. 496 A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and 497 attach the Context Label Space ID EC in the route. A PE MUST ignore 498 a received route with both the DCB-flag and the Context Label Space 499 ID EC attached, treating as if it was not received. If neither the 500 DCB-flag nor the Context Label Space ID EC is attached, the label in 501 the PTA or ESI Label EC MUST be treated as the upstream allocated 502 from the source PE's label space, and procedures in 503 [RFC6514][RFC7432] MUST be followed. 505 In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the 506 same tunnel, one of the following conditions MUST be met, so that a 507 receiving PE can correctly interpret the label that follows the 508 tunnel label in the right context. 510 o They MUST all have the DCB-flag, or, 512 o They MUST all carry the Context Label Space ID EC, or, 514 o None of them has the DCB-flag, or, 516 o None of them carry the Context Label Space ID EC. 518 4. Security Considerations 520 This document allows three methods (Section 2.2.3) of label 521 allocation for MVPN/EVPN PEs and specifies corresponding signaling 522 and procedures. The first method is the equivalent of using common 523 SRGBs from the regular per platform label space. The second one is 524 the equivalent of using common SRGBs from a third party's label 525 space, which is also considered as an upstream-assigned label 526 allocation [RFC5331]. The third method is is a variation of the 527 second, in that the third party's label space is divided into 528 disjoint blocks for use by different PEs, who will use labels from 529 their respective block to send traffic. In all cases, a receiving PE 530 is able to identify one of a few LFIBs to forward incoming labeled 531 traffic. 533 Therefore, this document does not introduce new security issues 534 besides what have been discussed in existing specifications [RFC5331] 535 [RFC6514] [RFC7432] [RFC8402]. 537 5. IANA Considerations 539 IANA is requested for the following assignments: 541 o Bit 47 (DCB-Bit) from the "Additional PMSI Tunnel Attribute Flags" 542 registry 544 Bit Name Reference 545 ---- ---------------------- ------------- 546 47 DCB-bit This document 548 o Sub-type 0x08 for "Context Label Space ID Extended Community" from 549 the "Transitive Opaque Extended Community Sub-Types" registry 551 Bit Name Reference 552 ---- ---------------------- ------------- 553 0x08 Context Label Space ID This document 555 6. Acknowledgements 557 The authors thank Stephane Litkowski, Ali Sajassi and Jingrong Xie 558 for their review of, comments on and suggestions for this document. 560 7. Contributors 562 The following also contributed to this document. 564 Selvakumar Sivaraj 565 Juniper Networks 567 Email: ssivaraj@juniper.net 569 8. References 571 8.1. Normative References 573 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 574 Requirement Levels", BCP 14, RFC 2119, 575 DOI 10.17487/RFC2119, March 1997, 576 . 578 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 579 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 580 2012, . 582 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 583 Encodings and Procedures for Multicast in MPLS/BGP IP 584 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 585 . 587 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 588 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 589 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 590 2015, . 592 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 593 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 594 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 595 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 596 . 598 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 599 "Multicast Virtual Private Network (MVPN): Using 600 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 601 July 2015, . 603 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 604 P-Multicast Service Interface Tunnel Attribute Flags", 605 RFC 7902, DOI 10.17487/RFC7902, June 2016, 606 . 608 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 609 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 610 May 2017, . 612 8.2. Informative References 614 [I-D.ietf-bess-evpn-bum-procedure-updates] 615 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 616 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 617 bess-evpn-bum-procedure-updates-08 (work in progress), 618 November 2019. 620 [I-D.ietf-bier-evpn] 621 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 622 "EVPN BUM Using BIER", draft-ietf-bier-evpn-04 (work in 623 progress), December 2020. 625 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 626 Label Assignment and Context-Specific Label Space", 627 RFC 5331, DOI 10.17487/RFC5331, August 2008, 628 . 630 [RFC8279] Wijnands, IJ., Ed., Rosen, E., Ed., Dolganow, A., 631 Przygienda, T., and S. Aldrin, "Multicast Using Bit Index 632 Explicit Replication (BIER)", RFC 8279, 633 DOI 10.17487/RFC8279, November 2017, 634 . 636 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 637 Decraene, B., Litkowski, S., and R. Shakir, "Segment 638 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 639 July 2018, . 641 [RFC8556] Rosen, E., Ed., Sivakumar, M., Przygienda, T., Aldrin, S., 642 and A. Dolganow, "Multicast VPN Using Bit Index Explicit 643 Replication (BIER)", RFC 8556, DOI 10.17487/RFC8556, April 644 2019, . 646 Authors' Addresses 648 Zhaohui Zhang 649 Juniper Networks 651 EMail: zzhang@juniper.net 653 Eric Rosen 654 Individual 656 EMail: erosen52@gmail.com 657 Wen Lin 658 Juniper Networks 660 EMail: wlin@juniper.net 662 Zhenbin Li 663 Huawei Technologies 665 EMail: lizhenbin@huawei.com 667 IJsbrand Wijnands 668 Individual 670 EMail: ice@braindump.be