idnits 2.17.1 draft-ietf-bess-mvpn-evpn-aggregation-label-05.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 (January 11, 2021) is 1172 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 152, but not defined == Missing Reference: 'BIER-MVPN' is mentioned on line 155, but not defined == Missing Reference: 'BIER-EVPN' is mentioned on line 155, but not defined == Missing Reference: 'RFC 6514' is mentioned on line 235, but not defined == Missing Reference: 'EVPN-BUM' is mentioned on line 294, but not defined == Unused Reference: 'I-D.ietf-bess-evpn-bum-procedure-updates' is defined on line 580, 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-04 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 Juniper Networks 4 Updates: 7432, 6514, 7582 (if approved) E. Rosen 5 Intended status: Standards Track Individual 6 Expires: July 15, 2021 W. Lin 7 Juniper Networks 8 Z. Li 9 Huawei Technologies 10 I. Wijnands 11 Individual 12 January 11, 2021 14 MVPN/EVPN Tunnel Aggregation with Common Labels 15 draft-ietf-bess-mvpn-evpn-aggregation-label-05 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 July 15, 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. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 93 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 94 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 12 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 96 7.1. Normative References . . . . . . . . . . . . . . . . . . 12 97 7.2. Informative References . . . . . . . . . . . . . . . . . 13 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 100 1. Terminologies 102 Familiarity with MVPN/EVPN protocols and procedures is assumed. Some 103 terminologies are listed below for convenience. 105 o BUM: Broadcast, Unknown Unicast, or Multicast (traffic). 107 o BD: Broadcast Domain. 109 o PMSI: Provider Multicast Service Interface - a pseudo interface 110 for a PE to send overlay/customer multicast traffic via underlay/ 111 provider tunnels. Includes I/S-PMSI (often referred to as x-PMSI) 112 for Inclusive/Selective-PMSI. 114 o IMET: Inclusive Multicast Ethernet Tag route. An EVPN specific 115 name for I-PMSI A-D route. 117 o PTA: PMSI Tunnel Attribute. A BGP attribute that may be attached 118 to an BGP-MVPN/EVPN A-D routes. 120 o ESI: Ethernet Segment Identifier. 122 2. Introduction 124 MVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or PIM) to 125 transport customer multicast traffic across a service provider's 126 backbone network. Often, a given P2MP tunnel carries the traffic of 127 only a single VPN. There are however procedures defined that allow a 128 single P2MP tunnel to carry traffic of multiple VPNs. In this case, 129 the P2MP tunnel is called an "aggregate tunnel". The PE router that 130 is the ingress node of an aggregate P2MP tunnel allocates an 131 "upstream-assigned MPLS label" [RFC5331] for each VPN, and each 132 packet sent on the P2MP tunnel carries the upstream-assigned MPLS 133 label that the ingress PE has bound to the packet's VPN. 135 Similarly, EVPN can use P2MP tunnels (set up by RSVP-TE, mLDP, or 136 PIM) to transport BUM traffic (Broadcast traffic, Unicast traffic 137 with an Unknown address, or Multicast traffic), across the provider 138 network. Often a P2MP tunnel carries the traffic of only a single 139 BD. However, there are procedures defined that allow a single P2MP 140 tunnel to be an "aggregate tunnel" that carries traffic of multiple 141 BDs. The procedures are analogous to the MVPN procedures -- the PE 142 router that is the ingress node of an aggregate P2MP tunnel allocates 143 an upstream-assigned MPLS label for each BD, and each packet sent on 144 the P2MP tunnel carries the upstream-assigned MPLS label that the 145 ingress PE has bound to the packet's BD. 147 MVPN and EVPN can also use BIER [RFC 8279] to transmit multicast 148 traffic or BUM traffic [I-D.ietf-bier-mvpn] [I-D.ietf-bier-evpn]. 149 Although BIER does not explicitly set up P2MP tunnels, from the 150 perspective of MVPN/EVPN, the use of BIER transport is very similar 151 to the use of aggregate P2MP tunnels. When BIER is used, the PE 152 transmitting a packet (the "BFIR" [RFC 8279]) must allocate an 153 upstream-assigned MPLS label for each VPN or BD, and the packets 154 transmitted using BIER transport always carry the label that 155 identifies their VPN or BD. (See [BIER-MVPN] and [BIER-EVPN] for the 156 details.) In the remainder of this document, we will use the term 157 "aggregate tunnels" to include both P2MP tunnels and BIER transport. 159 When an egress PE receives a packet from an aggregate tunnel, it must 160 look at the upstream-assigned label carried by the packet, and must 161 interpret that label in the context of the ingress PE. Essentially, 162 each ingress PE has its own "context label space" [RFC5331] from 163 which it allocates its upstream-assigned labels. When an egress PE 164 looks up the upstream-assigned label carried by a given packet, it 165 looks it up in the context label space owned by the packet's ingress 166 PE. How an egress PE identifies the ingress PE of a given packet 167 depends on the tunnel type. 169 2.1. Problem Description 171 Note that these procedures may require a very large number of labels. 172 Suppose an MVPN or EVPN deployment has 1001 PEs, each hosting 1000 173 VPN/BDs. Each ingress PE has to assign 1000 labels, and each egress 174 PE has to be prepared to interpret 1000 labels from each of the 175 ingress PEs. Since each ingress PE allocates labels from its own 176 context label space, and the ingress PEs do not coordinate their 177 label assignments, each egress PE must be prepared to interpret 178 1,000,000 upstream-assigned labels. This is an evident scaling 179 problem. 181 At the present time, few if any MVPN/EVPN deployments use aggregate 182 tunnels, so this problem has not surfaced. However, the use of 183 aggregate tunnels is likely to increase due to the following two 184 factors: 186 o In EVPN, a single customer ("tenant") may have a large number of 187 BDs, and the use of aggregate RSVP-TE or mLDP P2MP tunnels may 188 become important, since each tunnel creates state at the 189 intermediate nodes. 191 o The use of BIER as transport for MVPN/EVPN is becoming more and 192 more attractive and feasible. 194 Note there are pros and cons with traditional P2MP tunnel aggregation 195 (vs. BIER), which are already discussed in Section 2.1.1 of 196 [RFC6513]. This document simply specifies a way to increase label 197 scaling when tunnel aggregation is used. 199 A similar problem also exists with EVPN ESI labels used for multi- 200 homing. A PE attached to a multi-homed Ethernet Segment (ES) 201 advertises an ESI label in its Ethernet Segment route for the ES. 202 The PE imposes the label when it sends frames received from the ES to 203 other PEs via a P2MP/BIER tunnel. A receiving PE that is attached to 204 the source ES will know from the ESI label that the packet originated 205 on the source ES, and thus will not transmit the packet on its local 206 attachment circuit to that ES. From the receiving PE's point of 207 view, the ESI label is (upstream-)allocated from the source PE's 208 label space, so the receiving PE needs to maintain context label 209 tables, one for each source PE, just like the VRF/BD label case 210 above. If there are 1,001 PEs, each attached to 1,000 ESes, this can 211 require each PE to understand 1,000,000 ESI labels. Notice that the 212 issue exists even when no P2MP tunnel aggregation (i.e. one tunnel 213 used for multiple BDs) is used. 215 2.2. Proposed Solution 217 The number of labels could be greatly reduced if a central authority 218 assigned a label to each VPN, BD, or ES, and if all PEs used that 219 same label to represent a given VPN , BD, or ES. Then the number of 220 total number of labels needed would just be the sum of the number of 221 VPNs, BD, and/or ESes. 223 One method of achieving this is to reserve a portion of the label 224 space for assignment by a central authority. We refer to this 225 reserved portion as the "Domain-wide Common Block" (DCB) of labels. 226 This is analogous to the "Segment Routing Global Block" (SRGB) that 227 is described in [I-D.ietf-spring-segment-routing]. The DCB is taken 228 from the same label space that is used for downstream-assigned 229 labels, but each PE would know not to allocate local labels from that 230 space. A PE that is attached (via L3VPN VRF interfaces or EVPN 231 Access Circuits) would know by provisioning which label from the DCB 232 corresponds to which of its locally attached VPNs, BDs, or ESes. The 233 definition of "domain" is loose - it simply includes all the routers 234 that share the same DCB. In this document, it includes all PEs of an 235 MVPN/EVPN network. (Though if tunnel segmentation [RFC 6514] is 236 used, each segmentation region could have its own DCB. This will be 237 explained in more detail later.) If these PEs share other common 238 label blocks (e.g. SRGB) with other routers, the DCB MUST not 239 intersect with those common label blocks or those routers MUST be 240 considered as part of the "domain". However, the labels advertised 241 by PEs for the purposes defined in this document will only rise to 242 the top of the label stack when traffic arrives the PEs. 244 In some deployments, it may be impractical to allocate a DCB that is 245 large enough to contain labels for all the VPNs/BDs/ESes. In this 246 case, it may be necessary to allocate those labels from a context 247 label space. However, it is not necessary for each ingress PE to 248 have its own context label space. Instead, one (or some small 249 number) of context label spaces can be dedicated to such labels. 250 Each ingress PE would be provisioned to know both the context label 251 space identifier and the label for each VPN/BD/ES. 253 The MVPN/EVPN signaling defined in [RFC6514] and [RFC7432] assumes 254 that certain MPLS labels are allocated from a context label space 255 owned by a particular ingress PE. In this document, we augment the 256 signaling procedures so that it is possible to signal that a 257 particular label is from the DCB, rather than from an ingress PE's 258 context label space. We also augment the signaling so that it is 259 possible to indicate that a particular label is from an identified 260 context label space that is different than the ingress PE's own 261 context label space. 263 Notice that, the VPN/BD/ES-identifying labels from the DCB or from 264 those few context label spaces are very similar to VNIs in VXLAN. 265 Allocating a label from the DCB or from those a few context label 266 spaces and communicating them to all PEs should not be different from 267 allocating VNIs, and should be feasible in today's networks since 268 controllers are used more and more widely. 270 2.2.1. MP2MP Tunnels 272 MP2MP tunnels present the same problem that can be solved the same 273 way. 275 Per RFC 7582 ("MVPN: Using Bidirectional P-tunnels"), when MP2MP 276 tunnels are used for MVPN, the root of the MP2MP tunnel may need to 277 allocate and advertise "PE Distinguisher Labels". RFC 7582 states 278 that these labels are upstream-assigned, from the label space used by 279 the root node for its upstream-assigned labels. 281 It is REQUIRED by this document that the PE Distinguisher labels 282 allocated by a particular node come from the same source that the 283 node uses to allocate its VPN-identifying labels. 285 2.2.2. Segmented Tunnels 287 There are some additional issues to be considered when MVPN or EVPN 288 is using "tunnel segmentation" (see [RFC6514], [RFC7524], and [EVPN- 289 BUM] Sections 5 and 6). 291 2.2.2.1. Selective Tunnels 293 For "selective tunnels" (see [RFC6513] Sections 2.1.1 and 3.2.1, and 294 [EVPN-BUM] Section 4), the procedures outlined above work only if 295 tunnel segmentation is not used. 297 A selective tunnel carries one or more particular sets of flows to a 298 particular subset of the PEs that attach to a given VPN or BD. Each 299 set of flows is identified by a Selective PMSI A-D route [RFC6514]. 300 The PTA of the S-PMSI route identifies the tunnel used to carry the 301 corresponding set of flows. Multiple S-PMSI routes can identify the 302 same tunnel. 304 When tunnel segmentation is applied to a S-PMSI, certain nodes are 305 "segmentation points". A segmentation point is a node at the 306 boundary between two "segmentation regions". Let's call these 307 "region A" and "region B". A segmentation point is an egress node 308 for one or more selective tunnels in region A, and an ingress node 309 for one or more selective tunnels in region B. A given segmentation 310 point must be able to receive traffic on a selective tunnel from 311 region A, and label switch the traffic to the proper selective tunnel 312 in region B. 314 Suppose one selective tunnel (call it T1) in region A is carrying two 315 flows, Flow-1 and Flow-2, identified by S-PMSI route Route-1 and 316 Route-2 respectively. However, it is possible that, in region B, 317 Flow-1 is not carried by the same selective tunnel that carries Flow- 318 2. Let's suppose that in region B, Flow-1 is carried by tunnel T2 319 and Flow-2 by tunnel T3. Then when the segmentation point receives 320 traffic from T1, it must be able to label switch Flow-1 from T1 to 321 T2, while also label switching Flow-2 from T1 to T3. This implies 322 that Route-1 and Route-2 must signal different labels in the PTA. 324 In this case, it is not practical to have a central authority assign 325 domain-wide unique labels to individual S-PMSI routes. To address 326 this problem, all PEs can be assigned disjoint label blocks in those 327 few context label spaces, and each will allocate labels for segmented 328 S-PMSI independently from its assigned label block that is different 329 from any other PE's. For example, PE1 allocates from label block 330 [101~200], PE2 allocates from label block [201~300], and so on. 332 Allocating from disjoint label blocks can be used for VPN/BD/ES 333 labels as well, though it does not address the original scaling 334 issue, because there would be one million labels allocated from those 335 a few context label spaces in the original example, instead of just 336 one thousand common labels. 338 2.2.2.2. Per-PE/Region Tunnels 340 Similarly, for segmented per-PE (MVPN (C-*,C-*) S-PMSI or EVPN IMET) 341 or per-AS/region (MVPN Inter-AS I-PMSI or EVPN per-Region I-PMSI) 342 tunnels, labels need to be allocated per PMSI route. In case of per- 343 PE PMSI route, the labels should be allocated from the label block 344 allocated to the advertising PE. In case of per-AS/region PMSI 345 route, different ASBR/RBRs attached to the same source AS/region will 346 advertise the same PMSI route. The same label could be used when the 347 same route is advertised by different ASBRs/RBRs, though a simpler 348 way is for each ASBR/RBR to allocate its own label from the label 349 block allocated to itself. 351 In the rest of the document, we call the label allocated for a 352 particular PMSI a (per-)PMSI label, just like we have (per-)VPN/BD/ES 353 labels. Notice that using per-PMSI label in case of per-PE PMSI 354 still has the original scaling issue associated with the upstream 355 allocated label, so per-region PMSIs should be preferred. Within 356 each AS/region, per-PE PMSIs are still used though they do not go 357 across border and per-VPN/BD labels can still be used. 359 Note that, when a segmentation point re-advertise a PMSI route to the 360 next segment, it does not need to re-advertise a new label unless the 361 upstream or downstream segment uses Ingress Replication. [note - 362 future revision may extend the applicability of this document to 363 Ingress Replication as well] 365 2.2.2.3. Alternative to the per-PMSI Label Allocation 367 The per-PMSI label allocation in case of segmentation, whether for 368 S-PMSI or for per-PE/Region I-PMSI, is for the segmentation points to 369 be able to label switch traffic w/o having to do IP or MAC lookup in 370 VRFs (the segmentation points typically do not have those VRFs at 371 all). If the label scaling becomes a concern, alternatively the 372 segmentation points could use (C-S,C-G) lookup in VRFs for flows 373 identified by the S-PMSIs. This allows the S-PMSIs for the same VPN/ 374 BD to share the a VPN/BD-identifying label that leads to lookup in 375 the VRFs. That label should be different from the label used in the 376 per-PE/region I-PMSIs though, so that the segmentation points can 377 label switch other traffic (not identified by those S-PMSIs). 378 However, this moves the scaling problem from the number of labels to 379 the number of (C-S/*,C-G) routes in VRFs on the segmentation points. 381 2.2.3. Summary of Label Allocation Methods 383 In summary, labels can be allocated and advertised the following 384 ways: 386 1. A central authority allocates per-VPN/BD/ES labels from the DCB. 387 PEs advertise the labels with an indication that they are from 388 the DCB. 390 2. A central authority allocates per-VPN/BD/ES labels from a few 391 common context label spaces, and allocate labels from the DCB to 392 identify those context label spaces. PEs advertise the VPN/BD 393 labels along with the context-identifying labels. 395 3. A central authority assigns disjoint label blocks from those a 396 few context label spaces to each PE, and allocate labels from the 397 DCB to identify the context label spaces. Each PE allocates 398 labels from its assigned label block independently for its 399 segmented S-PMSI, along with the context-identifying labels. 401 Option 1 is simplest, but it requires that all the PEs set aside a 402 common label block for the DCB that is large enough for all the 403 VPNs/BDs/ESes combined. Option 3 is needed only for segmented 404 selective tunnels that are set up dynamically. Multiple options 405 could be used in any combination depending on the deployment 406 situation. 408 3. Specification 410 3.1. Context Label Space ID Extended Community 412 Context Label Space ID Extended Community is a new Transitive Opaque 413 EC with the following structure (Sub-Type value to be assigned by 414 IANA): 416 0 1 2 3 417 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 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | 0x03 or 0x43 | Sub-Type | ID-Type | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | ID-Value | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 o ID-Type: A 2-octet field that specifies the type of Label Space 425 ID. In this document, the ID-Type is 0, indicating that the ID- 426 Value field is a label. 428 o ID-Value: A 4-octet field that specifies the value of Label Space 429 ID. When it is a label (with ID-Value 0), the most significant 430 20-bit is set to the label value. 432 This document introduces a DCB-bit (to be assigned by IANA) in the 433 "Additional PMSI Tunnel Attribute Flags" BGP Extended Community 434 [RFC7902]. 436 In the remainder of the document, when we say a BGP-MVPN/EVPN A-D 437 route "carries DCB-flag" or "has DCB-flag attached" we mean the 438 following: 440 o The route carries a PMSI Tunnel Attribute (PTA) and its Flags 441 field has the Extension bit set 443 o The route carries an "Additional PMSI Tunnel Attribute Flags" EC 444 and its DCB-bit is set 446 3.2. Procedures 448 The protocol and procedures specified in this section need not be 449 applied unless when BIER, or P2MP/MP2MP tunnel aggregation is used 450 for MVPN/EVPN, or BIER/P2MP/MP2MP tunnels are used with EVPN multi- 451 homing. 453 By means outside the scope of this document, each VPN/BD/ES is 454 assigned a label from the DCB or one of those few context label 455 spaces, and every PE that is part of the VPN/BD/ES is aware of the 456 assignment. The ES label and the BD label MUST be assigned from the 457 same source. If PE Distinguisher labels are used [RFC7582], they 458 must be allocated from the same source as well. 460 In case of tunnel segmentation, each PE is also assigned a disjoint 461 label block from one of those few context label spaces and it 462 allocates labels for its segmented PMSI routes from its assigned 463 label block. 465 When a PE originates/re-advertises an x-PMSI/IMET route, the route 466 MUST carry a DCB-flag if and only if the label in its PTA is assigned 467 from the DCB. 469 If the VPN/BD/PMSI label is assigned from one of those few context 470 label spaces, a Context Label Space ID Extended Community is attached 471 to the route. The ID-Type in the EC is set to 0 and the ID-Value is 472 set to a label allocated from the DCB and identifies the context 473 label space. When an ingress PE sends traffic, it imposes the DCB 474 label that identifies the context label space after it imposes the 475 label (that is advertised in the PTA's Label field of the x-PMSI/IMET 476 route) for the VPN/BD and/or the label (that is advertised in the ESI 477 Label EC) for the ESI, and then imposes the encapsulation for the 478 transport tunnel. 480 When a PE receives an x-PMSI/IMET route with the Context Label Space 481 ID EC, it programs its default MPLS forwarding table to map the label 482 in the EC that identifies the context label space to a corresponding 483 context label table in which the next label lookup is done for 484 traffic that this PE receives. 486 The receiving PE then programs the label in the PTA or ESI Label EC 487 into either the default mpls forwarding table (if the route carries 488 the DCB-flag) or the context label table (if the Context Label Space 489 ID EC is present) according to the x-PMSI/IMET route. 491 A PE MUST NOT both carry the DCB-flag in an x-PMSI/IMET route and 492 attach the Context Label Space ID EC in the route. A PE MUST ignore 493 a received route with both the DCB-flag and the Context Label Space 494 ID EC attached. If neither the DCB-flag nor the Context Label Space 495 ID EC is attached, the label in the PTA or ESI Label EC is treated as 496 the upstream allocated from the source PE's label space, and 497 procedures in [RFC6514][RFC7432] must be followed. 499 In case of MPLS P2MP tunnels, if two x-PMSI/IMET routes specify the 500 same tunnel, one of the following conditions MUST be met, so that a 501 receiving PE can correctly interpret the label that follows the 502 tunnel label in the right context. 504 o They MUST all have the DCB-flag, or, 506 o They MUST all carry the Context Label Space ID EC, or, 508 o None of them has the DCB-flag, or, 510 o None of them carry the Context Label Space ID EC. 512 4. IANA Considerations 514 This document introduces a DCB-bit in the "Additional PMSI Tunnel 515 Attribute Flags" BGP Extended Community. An IANA request will be 516 submitted for the DCB-bit in the Additional PMSI Tunnel Attribute 517 Flags registry. 519 This document introduces a new Transitive Opaque Extended Community 520 "Context Label Space ID Extended Community". An IANA request will be 521 submitted for a sub-type value in the BGP Transitive Opaque Extended 522 Community Sub-Types registry. 524 5. Acknowledgements 526 6. Contributors 528 The following also contributed to this document. 530 Selvakumar Sivaraj 531 Juniper Networks 533 Email: ssivaraj@juniper.net 535 7. References 537 7.1. Normative References 539 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 540 Requirement Levels", BCP 14, RFC 2119, 541 DOI 10.17487/RFC2119, March 1997, 542 . 544 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 545 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 546 2012, . 548 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 549 Encodings and Procedures for Multicast in MPLS/BGP IP 550 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 551 . 553 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 554 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 555 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 556 2015, . 558 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 559 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 560 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 561 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 562 . 564 [RFC7582] Rosen, E., Wijnands, IJ., Cai, Y., and A. Boers, 565 "Multicast Virtual Private Network (MVPN): Using 566 Bidirectional P-Tunnels", RFC 7582, DOI 10.17487/RFC7582, 567 July 2015, . 569 [RFC7902] Rosen, E. and T. Morin, "Registry and Extensions for 570 P-Multicast Service Interface Tunnel Attribute Flags", 571 RFC 7902, DOI 10.17487/RFC7902, June 2016, 572 . 574 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 575 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 576 May 2017, . 578 7.2. Informative References 580 [I-D.ietf-bess-evpn-bum-procedure-updates] 581 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 582 Sajassi, "Updates on EVPN BUM Procedures", draft-ietf- 583 bess-evpn-bum-procedure-updates-08 (work in progress), 584 November 2019. 586 [I-D.ietf-bier-evpn] 587 Zhang, Z., Przygienda, T., Sajassi, A., and J. Rabadan, 588 "EVPN BUM Using BIER", draft-ietf-bier-evpn-04 (work in 589 progress), December 2020. 591 [I-D.ietf-bier-mvpn] 592 Rosen, E., Sivakumar, M., Aldrin, S., Dolganow, A., and T. 593 Przygienda, "Multicast VPN Using BIER", draft-ietf-bier- 594 mvpn-11 (work in progress), March 2018. 596 [I-D.ietf-spring-segment-routing] 597 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 598 Litkowski, S., and R. Shakir, "Segment Routing 599 Architecture", draft-ietf-spring-segment-routing-15 (work 600 in progress), January 2018. 602 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 603 Label Assignment and Context-Specific Label Space", 604 RFC 5331, DOI 10.17487/RFC5331, August 2008, 605 . 607 Authors' Addresses 609 Zhaohui Zhang 610 Juniper Networks 612 EMail: zzhang@juniper.net 613 Eric Rosen 614 Individual 616 EMail: erosen52@gmail.com 618 Wen Lin 619 Juniper Networks 621 EMail: wlin@juniper.net 623 Zhenbin Li 624 Huawei Technologies 626 EMail: lizhenbin@huawei.com 628 IJsbrand Wijnands 629 Individual 631 EMail: ice@braindump.be