idnits 2.17.1 draft-ietf-bess-mvpn-evpn-aggregation-label-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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: One method of achieving this is to reserve a portion of the label space for assignment by a central authority. We refer to this reserved portion as the "Domain-wide Common Block" (DCB) of labels. This is analogous to the "Segment Routing Global Block" (SRGB) that is described in [I-D.ietf-spring-segment-routing]. The DCB is taken from the same label space that is used for downstream-assigned labels, but each PE would know not to allocate local labels from that space. A PE that is attached (via L3VPN VRF interfaces or EVPN Access Circuits) would know by provisioning which label from the DCB corresponds to which of its locally attached VPNs, BDs, or ESes. The definition of "domain" is loose - it simply includes all the routers that share the same DCB. In this document, it includes all PEs of an MVPN/EVPN network. (Though if tunnel segmentation [RFC 6514] is used, each segmentation region could have its own DCB. This will be explained in more detail later.) If these PEs share other common label blocks (e.g. SRGB) with other routers, the DCB MUST not intersect with those common label blocks or those routers MUST be considered as part of the "domain". However, the labels advertised by PEs for the purposes defined in this document will only rise to the top of the label stack when traffic arrives the PEs. (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 (November 15, 2020) is 1229 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) == Missing Reference: 'RFC 8279' is mentioned on line 150, but not defined == Missing Reference: 'BIER-MVPN' is mentioned on line 153, but not defined == Missing Reference: 'BIER-EVPN' is mentioned on line 153, but not defined == Missing Reference: 'RFC 6514' is mentioned on line 233, but not defined == Missing Reference: 'EVPN-BUM' is mentioned on line 292, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-bum-procedure-updates' is defined on line 578, but no explicit reference was found in the text == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-14) exists of draft-ietf-bier-evpn-03 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft E. Rosen 4 Updates: 7432, 6514, 7582 (if approved) W. Lin 5 Intended status: Standards Track Juniper Networks 6 Expires: May 19, 2021 Z. Li 7 Huawei Technologies 8 I. Wijnands 9 Cisco Systems 10 November 15, 2020 12 MVPN/EVPN Tunnel Aggregation with Common Labels 13 draft-ietf-bess-mvpn-evpn-aggregation-label-04 15 Abstract 17 The MVPN specifications allow a single Point-to-Multipoint (P2MP) 18 tunnel to carry traffic of multiple VPNs. The EVPN specifications 19 allow a single P2MP tunnel to carry traffic of multiple Broadcast 20 Domains (BDs). These features require the ingress router of the P2MP 21 tunnel to allocate an upstream-assigned MPLS label for each VPN or 22 for each BD. A packet sent on a P2MP tunnel then carries the label 23 that is mapped to its VPN or BD. (In some cases, a distinct 24 upstream-assigned is needed for each flow.) Since each ingress 25 router allocates labels independently, with no coordination among the 26 ingress routers, the egress routers may need to keep track of a large 27 number of labels. The number of labels may need to be as large (or 28 larger) than the product of the number of ingress routers times the 29 number of VPNs or BDs. However, the number of labels can be greatly 30 reduced if the association between a label and a VPN or BD is made by 31 provisioning, so that all ingress routers assign the same label to a 32 particular VPN or BD. New procedures are needed in order to take 33 advantage of such provisioned labels. These new procedures also 34 apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document 35 updates RFCs 6514, 7432 and 7582 by specifying the necessary 36 procedures. 38 Requirements Language 40 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 41 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 42 "OPTIONAL" in this document are to be interpreted as described in BCP 43 14 [RFC2119] [RFC8174] when, and only when, they appear in all 44 capitals, as shown here. 46 Status of This Memo 48 This Internet-Draft is submitted in full conformance with the 49 provisions of BCP 78 and BCP 79. 51 Internet-Drafts are working documents of the Internet Engineering 52 Task Force (IETF). Note that other groups may also distribute 53 working documents as Internet-Drafts. The list of current Internet- 54 Drafts is at https://datatracker.ietf.org/drafts/current/. 56 Internet-Drafts are draft documents valid for a maximum of six months 57 and may be updated, replaced, or obsoleted by other documents at any 58 time. It is inappropriate to use Internet-Drafts as reference 59 material or to cite them other than as "work in progress." 61 This Internet-Draft will expire on May 19, 2021. 63 Copyright Notice 65 Copyright (c) 2020 IETF Trust and the persons identified as the 66 document authors. All rights reserved. 68 This document is subject to BCP 78 and the IETF Trust's Legal 69 Provisions Relating to IETF Documents 70 (https://trustee.ietf.org/license-info) in effect on the date of 71 publication of this document. Please review these documents 72 carefully, as they describe your rights and restrictions with respect 73 to this document. Code Components extracted from this document must 74 include Simplified BSD License text as described in Section 4.e of 75 the Trust Legal Provisions and are provided without warranty as 76 described in the Simplified BSD License. 78 Table of Contents 80 1. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 3 81 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 82 2.1. Problem Description . . . . . . . . . . . . . . . . . . . 4 83 2.2. Proposed Solution . . . . . . . . . . . . . . . . . . . . 5 84 2.2.1. MP2MP Tunnels . . . . . . . . . . . . . . . . . . . . 6 85 2.2.2. Segmented Tunnels . . . . . . . . . . . . . . . . . . 7 86 2.2.3. Summary of Label Allocation Methods . . . . . . . . . 9 87 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 9 88 3.1. Context Label Space ID Extended Community . . . . . . . . 9 89 3.2. Procedures . . . . . . . . . . . . . . . . . . . . . . . 10 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 91 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 92 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 95 7.2. Informative References . . . . . . . . . . . . . . . . . 13 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 98 1. Terminologies 100 Familiarity with MVPN/EVPN protocols and procedures is assumed. Some 101 terminologies are listed below for convenience. 103 o BUM: Broadcast, Unknown Unicast, or Multicast (traffic). 105 o BD: Broadcast Domain. 107 o PMSI: Provider Multicast Service Interface - a pseudo interface 108 for a PE to send overlay/customer multicast traffic via underlay/ 109 provider tunnels. Includes I/S-PMSI (often referred to as x-PMSI) 110 for Inclusive/Selective-PMSI. 112 o IMET: Inclusive Multicast Ethernet Tag route. An EVPN specific 113 name for I-PMSI A-D route. 115 o PTA: PMSI Tunnel Attribute. A BGP attribute that may be attached 116 to an BGP-MVPN/EVPN A-D routes. 118 o ESI: Ethernet Segment Identifier. 120 2. Introduction 122 MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to 123 transport customer multicast traffic across a service provider's 124 backbone network. Often, a given P2MP tunnel carries the traffic of 125 only a single VPN. There are however procedures defined that allow a 126 single P2MP tunnel to carry traffic of multiple VPNs. In this case, 127 the P2MP tunnel is called an "aggregate tunnel". The PE router that 128 is the ingress node of an aggregate P2MP tunnel allocates an 129 "upstream-assigned MPLS label" [RFC5331] for each VPN, and each 130 packet sent on the P2MP tunnel carries the upstream-assigned MPLS 131 label that the ingress PE has bound to the packet's VPN. 133 Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or 134 PIM) to transport BUM traffic (Broadcast traffic, Unicast traffic 135 with an Unknown address, or Multicast traffic), across the provider 136 network. Often a P2MP tunnel carries the traffic of only a single 137 BD. However, there are procedures defined that allow a single P2MP 138 tunnel to be an "aggregate tunnel" that carries traffic of multiple 139 BDs. The procedures are analogous to the MVPN procedures -- the PE 140 router that is the ingress node of an aggregate P2MP tunnel allocates 141 an upstream-assigned MPLS label for each BD, and each packet sent on 142 the P2MP tunnel carries the upstream-assigned MPLS label that the 143 ingress PE has bound to the packet's BD. 145 MVPN and EVPN can also use BIER [RFC 8279] to transmit multicast 146 traffic or BUM traffic [I-D.ietf-bier-mvpn] [I-D.ietf-bier-evpn]. 147 Although BIER does not explicitly set up P2MP tunnels, from the 148 perspective of MVPN/EVPN, the use of BIER transport is very similar 149 to the use of aggregate P2MP tunnels. When BIER is used, the PE 150 transmitting a packet (the "BFIR" [RFC 8279]) must allocate an 151 upstream-assigned MPLS label for each VPN or BD, and the packets 152 transmitted using BIER transport always carry the label that 153 identifies their VPN or BD. (See [BIER-MVPN] and [BIER-EVPN] for the 154 details.) In the remainder of this document, we will use the term 155 "aggregate tunnels" to include both P2MP tunnels and BIER transport. 157 When an egress PE receives a packet from an aggregate tunnel, it must 158 look at the upstream-assigned label carried by the packet, and must 159 interpret that label in the context of the ingress PE. Essentially, 160 each ingress PE has its own "context label space" [RFC5331] from 161 which it allocates its upstream-assigned labels. When an egress PE 162 looks up the upstream-assigned label carried by a given packet, it 163 looks it up in the context label space owned by the packet's ingress 164 PE. How an egress PE identifies the ingress PE of a given packet 165 depends on the tunnel type. 167 2.1. Problem Description 169 Note that these procedures may require a very large number of labels. 170 Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 171 VPN/BDs. Each ingress PE has to assign 1000 labels, and each egress 172 PE has to be prepared to interpret 1000 labels from each of the 173 ingress PEs. Since each ingress PE allocates labels from its own 174 context label space, and the ingress PEs do not coordinate their 175 label assignments, each egress PE must be prepared to interpret 176 1,000,000 upstream-assigned labels. This is an evident scaling 177 problem. 179 At the present time, few if any MVPN/EVPN deployments use aggregate 180 tunnels, so this problem has not surfaced. However, the use of 181 aggregate tunnels is likely to increase due to the following two 182 factors: 184 o In EVPN, a single customer ("tenant") may have a large number of 185 BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may 186 become important, since each tunnel creates state at the 187 intermediate nodes. 189 o The use of BIER as transport for MVPN/EVPN is becoming more and 190 more attractive and feasible. 192 Note there are pros and cons with traditional P2MP tunnel aggregation 193 (vs. BIER), which are already discussed in Section 2.1.1 of 194 [RFC6513]. This document simply specifies a way to increase label 195 scaling when tunnel aggregation is used. 197 A similar problem also exists with EVPN ESI labels used for multi- 198 homing. A PE attached to a multi-homed Ethernet Segment (ES) 199 advertises an ESI label in its Ethernet Segment route for the ES. 200 The PE imposes the label when it sends frames received from the ES to 201 other PEs via a P2MP/BIER tunnel. A receiving PE that is attached to 202 the source ES will know from the ESI label that the packet originated 203 on the source ES, and thus will not transmit the packet on its local 204 attachment circuit to that ES. From the receiving PE's point of 205 view, the ESI label is (upstream-)allocated from the source PE's 206 label space, so the receiving PE needs to maintain context label 207 tables, one for each source PE, just like the VRF/BD label case 208 above. If there are 1,001 PEs, each attached to 1,000 ESes, this can 209 require each PE to understand 1,000,000 ESI labels. Notice that the 210 issue exists even when no P2MP tunnel aggregation (i.e. one tunnel 211 used for multiple BDs) is used. 213 2.2. Proposed Solution 215 The number of labels could be greatly reduced if a central authority 216 assigned a label to each VPN, BD, or ES, and if all PEs used that 217 same label to represent a given VPN , BD, or ES. Then the number of 218 total number of labels needed would just be the sum of the number of 219 VPNs, BD, and/or ESes. 221 One method of achieving this is to reserve a portion of the label 222 space for assignment by a central authority. We refer to this 223 reserved portion as the "Domain-wide Common Block" (DCB) of labels. 224 This is analogous to the "Segment Routing Global Block" (SRGB) that 225 is described in [I-D.ietf-spring-segment-routing]. The DCB is taken 226 from the same label space that is used for downstream-assigned 227 labels, but each PE would know not to allocate local labels from that 228 space. A PE that is attached (via L3VPN VRF interfaces or EVPN 229 Access Circuits) would know by provisioning which label from the DCB 230 corresponds to which of its locally attached VPNs, BDs, or ESes. The 231 definition of "domain" is loose - it simply includes all the routers 232 that share the same DCB. In this document, it includes all PEs of an 233 MVPN/EVPN network. (Though if tunnel segmentation [RFC 6514] is 234 used, each segmentation region could have its own DCB. This will be 235 explained in more detail later.) If these PEs share other common 236 label blocks (e.g. SRGB) with other routers, the DCB MUST not 237 intersect with those common label blocks or those routers MUST be 238 considered as part of the "domain". However, the labels advertised 239 by PEs for the purposes defined in this document will only rise to 240 the top of the label stack when traffic arrives the PEs. 242 In some deployments, it may be impractical to allocate a DCB that is 243 large enough to contain labels for all the VPNs/BDs/ESes. In this 244 case, it may be necessary to allocate those labels from a context 245 label space. However, it is not necessary for each ingress PE to 246 have its own context label space. Instead, one (or some small 247 number) of context label spaces can be dedicated to such labels. 248 Each ingress PE would be provisioned to know both the context label 249 space identifier and the label for each VPN/BD/ES. 251 The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes 252 that certain MPLS labels are allocated from a context label space 253 owned by a particular ingress PE. In this document, we augment the 254 signaling procedures so that it is possible to signal that a 255 particular label is from the DCB, rather than from an ingress PE's 256 context label space. We also augment the signaling so that it is 257 possible to indicate that a particular label is from an identified 258 context label space that is different than the ingress PE's own 259 context label space. 261 Notice that, the VPN/BD/ES-identifying labels from the DCB or from 262 those few context label spaces are very similar to VNIs in VXLAN. 263 Allocating a label from the DCB or from those a few context label 264 spaces and communicating them to all PEs should not be different from 265 allocating VNIs, and should be feasible in today's networks since 266 controllers are used more and more widely. 268 2.2.1. MP2MP Tunnels 270 MP2MP tunnels present the same problem that can be solved the same 271 way. 273 Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP 274 tunnels are used for MVPN, the root of the MP2MP tunnel may need to 275 allocate and advertise "PE Distinguisher Labels". RFC 7582 states 276 that these labels are upstream-assigned, from the label space used by 277 the root node for its upstream-assigned labels. 279 It is REQUIRED by this document that the PE Distinguisher labels 280 allocated by a particular node come from the same source that the 281 node uses to allocate its VPN-identifying labels. 283 2.2.2. Segmented Tunnels 285 There are some additional issues to be considered when MVPN or EVPN 286 is using "tunnel segmentation" (see [RFC6514], [RFC7524], and [EVPN- 287 BUM] Sections 5 and 6). 289 2.2.2.1. Selective Tunnels 291 For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and 292 [EVPN-BUM] Section 4), the procedures outlined above work only if 293 tunnel segmentation is not used. 295 A selective tunnel carries one or more particular sets of flows to a 296 particular subset of the PEs that attach to a given VPN or BD. Each 297 set of flows is identified by a Selective PMSI A-D route [RFC6514]. 298 The PTA of the S-PMSI route identifies the tunnel used to carry the 299 corresponding set of flows. Multiple S-PMSI routes can identify the 300 same tunnel. 302 When tunnel segmentation is applied to a S-PMSI, certain nodes are 303 "segmentation points". A segmentation point is a node at the 304 boundary between two "segmentation regions". Let's call these 305 "region A" and "region B". A segmentation point is an egress node 306 for one or more selective tunnels in region A, and an ingress node 307 for one or more selective tunnels in region B. A given segmentation 308 point must be able to receive traffic on a selective tunnel from 309 region A, and label switch the traffic to the proper selective tunnel 310 in region B. 312 Suppose one selective tunnel (call it T1) in region A is carrying two 313 flows, Flow-1 and Flow-2, identified by S-PMSI route Route-1 and 314 Route-2 respectively. However, it is possible that, in region B, 315 Flow-1 is not carried by the same selective tunnel that carries Flow- 316 2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 317 and Flow-2 by tunnel T3. Then when the segmentation point receives 318 traffic from T1, it must be able to label switch Flow-1 from T1 to 319 T2, while also label switching Flow-2 from T1 to T3. This implies 320 that Route-1 and Route-2 must signal different labels in the PTA. 322 In this case, it is not practical to have a central authority assign 323 domain-wide unique labels to individual S-PMSI routes. To address 324 this problem, all PEs can be assigned disjoint label blocks in those 325 few context label spaces, and each will allocate labels for segmented 326 S-PMSI independently from its assigned label block that is different 327 from any other PE's. For example, PE1 allocates from label block 328 [101~200], PE2 allocates from label block [201~300], and so on. 330 Allocating from disjoint label blocks can be used for VPN/BD/ES 331 labels as well, though it does not address the original scaling 332 issue, because there would be one million labels allocated from those 333 a few context label spaces in the original example, instead of just 334 one thousand common labels. 336 2.2.2.2. Per-PE/Region Tunnels 338 Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) 339 or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) 340 tunnels, labels need to be allocated per PMSI route. In case of per- 341 PE PMSI route, the labels should be allocated from the label block 342 allocated to the advertising PE. In case of per-AS/region PMSI 343 route, different ASBR/RBRs attached to the same source AS/region will 344 advertise the same PMSI route. The same label could be used when the 345 same route is advertised by different ASBRs/RBRs, though a simpler 346 way is for each ASBR/RBR to allocate its own label from the label 347 block allocated to itself. 349 In the rest of the document, we call the label allocated for a 350 particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES 351 labels. Notice that using per-PMSI label in case of per-PE PMSI 352 still has the original scaling issue associated with the upstream 353 allocated label, so per-region PMSIs should be preferred. Within 354 each AS/region, per-PE PMSIs are still used though they do not go 355 across border and per-VPN/BD labels can still be used. 357 Note that, when a segmentation point re-advertise a PMSI route to the 358 next segment, it does not need to re-advertise a new label unless the 359 upstream or downstream segment uses Ingress Replication. [note - 360 future revision may extend the applicability of this document to 361 Ingress Replication as well] 363 2.2.2.3. Alternative to the per-PMSI Label Allocation 365 The per-PMSI label allocation in case of segmentation, whether for 366 S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to 367 be able to label switch traffic w/o having to do IP or MAC lookup in 368 VRFs (the segmentation points typically do not have those VRFs at 369 all). If the label scaling becomes a concern, alternatively the 370 segmentation points could use (C-S,C-G) lookup in VRFs for flows 371 identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/ 372 BD to share the a VPN/BD-identifying label that leads to lookup in 373 the VRFs. That label should be different from the label used in the 374 per-PE/region I-PMSIs though, so that the segmentation points can 375 label switch other traffic (not identified by those S-PMSIs). 376 However, this moves the scaling problem from the number of labels to 377 the number of (C-S/*,C-G) routes in VRFs on the segmentation points. 379 2.2.3. Summary of Label Allocation Methods 381 In summary, labels can be allocated and advertised the following 382 ways: 384 1. A central authority allocates per-VPN/BD/ES labels from the DCB. 385 PEs advertise the labels with an indication that they are from 386 the DCB. 388 2. A central authority allocates per-VPN/BD/ES labels from a few 389 common context label spaces, and allocate labels from the DCB to 390 identify those context label spaces. PEs advertise the VPN/BD 391 labels along with the context-identifying labels. 393 3. A central authority assigns disjoint label blocks from those a 394 few context label spaces to each PE, and allocate labels from the 395 DCB to identify the context label spaces. Each PE allocates 396 labels from its assigned label block independently for its 397 segmented S-PMSI, along with the context-identifying labels. 399 Option 1 is simplest, but it requires that all the PEs set aside a 400 common label block for the DCB that is large enough for all the 401 VPNs/BDs/ESes combined. Option 3 is needed only for segmented 402 selective tunnels that are set up dynamically. Multiple options 403 could be used in any combination depending on the deployment 404 situation. 406 3. Specification 408 3.1. Context Label Space ID Extended Community 410 Context Label Space ID Extended Community is a new Transitive Opaque 411 EC with the following structure (Sub-Type value to be assigned by 412 IANA): 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | 0x03 or 0x43 | Sub-Type | ID-Type | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | ID-Value | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 o ID-Type: A 2-octet field that specifies the type of Label Space 423 ID. In this document, the ID-Type is 0, indicating that the ID- 424 Value field is a label. 426 o ID-Value: A 4-octet field that specifies the value of Label Space 427 ID. When it is a label (with ID-Value 0), the most significant 428 20-bit is set to the label value. 430 This document introduces a DCB-bit (to be assigned by IANA) in the 431 "Additional PMSI Tunnel Attribute Flags" BGP Extended Community 432 [RFC7902]. 434 In the remainder of the document, when we say a BGP-MVPN/EVPN A-D 435 route "carries DCB-flag" or "has DCB-flag attached" we mean the 436 following: 438 o The route carries a PMSI Tunnel Attribute (PTA) and its Flags 439 field has the Extension bit set 441 o The route carries an "Additional PMSI Tunnel Attribute Flags" EC 442 and its DCB-bit is set 444 3.2. Procedures 446 The protocol and procedures specified in this section need not be 447 applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used 448 for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi- 449 homing. 451 By means outside the scope of this document, each VPN/BD/ES is 452 assigned a label from the DCB or one of those few context label 453 spaces, and every PE that is part of the VPN/BD/ES is aware of the 454 assignment. The ES label and the BD label MUST be assigned from the 455 same source. If PE Distinguisher labels are used [RFC7582], they 456 must be allocated from the same source as well. 458 In case of tunnel segmentation, each PE is also assigned a disjoint 459 label block from one of those few context label spaces and it 460 allocates labels for its segmented PMSI routes from its assigned 461 label block. 463 When a PE originates/re-advertises an x-PMSI/IMET route, the route 464 MUST carry a DCB-flag if and only if the label in its PTA is assigned 465 from the DCB. 467 If the VPN/BD/PMSI label is assigned from one of those few context 468 label spaces, a Context Label Space ID Extended Community is attached 469 to the route. The ID-Type in the EC is set to 0 and the ID-Value is 470 set to a label allocated from the DCB and identifies the context 471 label space. When an ingress PE sends traffic, it imposes the DCB 472 label that identifies the context label space after it imposes the 473 label (that is advertised in the PTA's Label field of the x-PMSI/IMET 474 route) for the VPN/BD and/or the label (that is advertised in the ESI 475 Label EC) for the ESI, and then imposes the encapsulation for the 476 transport tunnel. 478 When a PE receives an x-PMSI/IMET route with the Context Label Space 479 ID EC, it programs its default MPLS forwarding table to map the label 480 in the EC that identifies the context label space to a corresponding 481 context label table in which the next label lookup is done for 482 traffic that this PE receives. 484 The receiving PE then programs the label in the PTA or ESI Label EC 485 into either the default mpls forwarding table (if the route carries 486 the DCB-flag) or the context label table (if the Context Label Space 487 ID EC is present) according to the x-PMSI/IMET route. 489 A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and 490 attach the Context Label Space ID EC in the route. A PE MUST ignore 491 a received route with both the DCB-flag and the Context Label Space 492 ID EC attached. If neither the DCB-flag nor the Context Label Space 493 ID EC is attached, the label in the PTA or ESI Label EC is treated as 494 the upstream allocated from the source PE's label space, and 495 procedures in [RFC6514][RFC7432] must be followed. 497 In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the 498 same tunnel, one of the following conditions MUST be met, so that a 499 receiving PE can correctly interpret the label that follows the 500 tunnel label in the right context. 502 o They MUST all have the DCB-flag, or, 504 o They MUST all carry the Context Label Space ID EC, or, 506 o None of them has the DCB-flag, or, 508 o None of them carry the Context Label Space ID EC. 510 4. IANA Considerations 512 This document introduces a DCB-bit in the "Additional PMSI Tunnel 513 Attribute Flags" BGP Extended Community. An IANA request will be 514 submitted for the DCB-bit in the Additional PMSI Tunnel Attribute 515 Flags registry. 517 This document introduces a new Transitive Opaque Extended Community 518 "Context Label Space ID Extended Community". An IANA request will be 519 submitted for a sub-type value in the BGP Transitive Opaque Extended 520 Community Sub-Types registry. 522 5. Acknowledgements 524 6. Contributors 526 The following also contributed to this document. 528 Selvakumar Sivaraj 529 Juniper Networks 531 Email: ssivaraj@juniper.net 533 7. References 535 7.1. Normative References 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 543 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 544 2012, . 546 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 547 Encodings and Procedures for Multicast in MPLS/BGP IP 548 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 549 . 551 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 552 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 553 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 554 2015, . 556 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 557 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 558 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 559 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 560 . 562 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 563 "Multicast Virtual Private Network (MVPN): Using 564 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 565 July 2015, . 567 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 568 P-Multicast Service Interface Tunnel Attribute Flags", 569 RFC 7902, DOI 10.17487/RFC7902, June 2016, 570 . 572 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 573 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 574 May 2017, . 576 7.2. Informative References 578 [I-D.ietf-bess-evpn-bum-procedure-updates] 579 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 580 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 581 bess-evpn-bum-procedure-updates-08 (work in progress), 582 November 2019. 584 [I-D.ietf-bier-evpn] 585 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 586 "EVPN BUM Using BIER", draft-ietf-bier-evpn-03 (work in 587 progress), April 2020. 589 [I-D.ietf-bier-mvpn] 590 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 591 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 592 mvpn-11 (work in progress), March 2018. 594 [I-D.ietf-spring-segment-routing] 595 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 596 Litkowski, S., and R. Shakir, "Segment Routing 597 Architecture", draft-ietf-spring-segment-routing-15 (work 598 in progress), January 2018. 600 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 601 Label Assignment and Context-Specific Label Space", 602 RFC 5331, DOI 10.17487/RFC5331, August 2008, 603 . 605 Authors' Addresses 607 Zhaohui Zhang 608 Juniper Networks 610 EMail: zzhang@juniper.net 611 Eric Rosen 612 Juniper Networks 614 EMail: erosen@juniper.net 616 Wen Lin 617 Juniper Networks 619 EMail: wlin@juniper.net 621 Zhenbin Li 622 Huawei Technologies 624 EMail: lizhenbin@huawei.com 626 IJsbrand Wijnands 627 Cisco Systems 629 EMail: ice@cisco.com