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