idnits 2.17.1 draft-wang-bess-evpn-context-label-02.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 an Introduction section. ** The abstract seems to contain references ([RFC4761], [RFC4762]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 437: '...th have a IR-PTA, PE2 SHOULD use R2 to...' RFC 2119 keyword, line 544: '... Leaf A-D route SHOULD be generated f...' RFC 2119 keyword, line 574: '...erent TPEs, SPE1 MUST use different CL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (10 June 2020) is 1416 days in the past. Is this intentional? 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: 'RFC4762' is mentioned on line 13, but not defined == Outdated reference: A later version (-14) exists of draft-ietf-bess-evpn-bum-procedure-updates-08 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-optimized-ir-06 == Outdated reference: A later version (-14) exists of draft-ietf-bess-mvpn-evpn-aggregation-label-03 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS WG Y. Wang 3 Internet-Draft B. Song 4 Intended status: Standards Track ZTE Corporation 5 Expires: 12 December 2020 10 June 2020 7 Context Label for MPLS EVPN 8 draft-wang-bess-evpn-context-label-02 10 Abstract 12 EVPN is designed to provide a better VPLS service than [RFC4761] and 13 [RFC4762], and EVPN indeed introduced many new features which 14 couldn't be achieved in those old VPLS implementions. But EVPN 15 didn't inherit all features of old VPLS, and a few issues arises for 16 EVPN only. 18 Some of these issues can be imputed to the MP2P nature of EVPN 19 labels. The PW label in old VPLS is a label for P2P VC, so it 20 contains more context than a identifier in dataplane for it's VSI 21 instance.But the EVPN label just identifies it's VSI instnace and it 22 can't stand for the ingress PE in dataplane. So the following issues 23 arises with MPLS EVPN service: 25 * MPLS EVPN statistics can't be done per ingress PE. 27 * MPLS EVPN can't support hub/spoke use case which the spoke PE can 28 only connect to each other by the hub PE. 30 * MPLS EVPN can't support AR REPLICATOR. 32 * MPLS EVPN can't support anycast SR-MPLS tunnel on the SPE nodes. 34 This document introduces a compound label stack to take advantage of 35 both P2P VC and MP2P evpn labels. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on 12 December 2020. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Terminology and Acronyms . . . . . . . . . . . . . . . . . . 3 71 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 72 3. Using VC Label to Add Context Data to EVPN Flows . . . . . . 5 73 3.1. The Shared Context VCs . . . . . . . . . . . . . . . . . 5 74 3.2. The per-EVI Context VCs . . . . . . . . . . . . . . . . . 6 75 4. Signalling for Shared Context VCs . . . . . . . . . . . . . . 6 76 4.1. Kompella Signalling for Context VC . . . . . . . . . . . 6 77 4.2. SR-MPLS signalling for CSL-based Context VC . . . . . . . 6 78 5. Signalling for per-EVI Context VCs . . . . . . . . . . . . . 7 79 5.1. Construct Leaf A-D Route for IR . . . . . . . . . . . . . 8 80 5.1.1. Advertising Per-platform VC Label . . . . . . . . . . 8 81 5.1.2. Advertising Context-Specific VC label . . . . . . . . 8 82 5.2. Establish Ingress Replication List by Leaf A-D Route . . 10 83 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 10 84 6. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6.1. Solution for Source-Squelching in Hub-Spoke Scenarios . . 10 86 6.2. Solution for per ingress statistics . . . . . . . . . . . 11 87 6.3. Solution for AR REPLICATOR in MPLS EVPN . . . . . . . . . 11 88 6.4. Solution for anycast tunnel usage on SPE . . . . . . . . 12 89 6.4.1. Control-plane . . . . . . . . . . . . . . . . . . . . 13 90 6.4.2. Data-plane . . . . . . . . . . . . . . . . . . . . . 13 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 93 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 94 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 95 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 96 10.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Terminology and Acronyms 101 This document uses the following acronyms and terms: 103 BUM - Broadcast, Unknown unicast, and Multicast. 105 CE - Customer Edge equipment. 107 PE - Provider Edge equipment. 109 OPE - Originating PE - the original Router of an EVPN route. 111 ORIP - Originating Router's IP address. 113 Root ORIP - The ORIP in the Route Key field of a Leaf A-D route is 114 called as that Leaf A-D route's Root ORIP. The Route Key field is 115 the "Route Type specific" field of an PMSI route for which that 116 Leaf A-D route is generated. When that PMSI route is an IMET 117 route, that Leaf A-D route's root ORIP is that IMET route's 118 "Originating Router's IP Address". 120 Leaf ORIP - The "Originator's Addr" field of the "Route Type 121 specific" field of a Leaf A-D route is called as that Leaf A-D 122 route's Leaf ORIP. 124 Self ORIP - The Leaf ORIP of a Leaf A-D route is also called as 125 that Leaf A-D route's "self ORIP". 127 PTA - PMSI Tunnel Attribute. 129 PTA label - The MPLS label field of PMSI Tunnel Attribute. 131 PTA flags - The flags field of PMSI Tunnel Attribute. 133 IR - Ingress Replication. 135 AR - Assisted Replication. 137 IR PTA - PMSI Tunnel Attribute with tunnel-type = IR. 139 AR PTA - PMSI Tunnel Attribute with tunnel-type = AR. 141 IRL - Ingress Replication List, the list for Ingress-Replication 142 BUM packets forwarding. 144 LS - Label Space. 146 CL - Context Label, A "context label" is one label that identifies 147 a label table in which the label immediately below the context 148 label should be looked up. It is defined in [RFC5331] section 3. 150 CLS - Context Label Space, a Label Space that is identified by a 151 Context Label. In [RFC5331], it is called as "Context-specific 152 Label Space". 154 CLS ID - Context Label Space ID, which is defined in 155 [I-D.ietf-bess-mvpn-evpn-aggregation-label]. 157 CSL - Context-Specific Label, a MPLS label that is allocated in a 158 Context Label Space (CLS) which is identified by a CL. Note that 159 a CSL is totally different from a CL. A CL itself is typically 160 allocated in the per-platform label space. 162 CSL-Entry - Context-Specific Label Entry, a specific MPLS label 163 allocated in a specific Context Label Space (CLS). 165 EVI - EVPN Instance. 167 EVPN label - The MPLS label in an EVPN route. 169 EVI label - A MPLS label identifies an EVPN Instance (EVI) 171 Admin EVI - A EVPN Instance (EVI) that is responsible for specific 172 signalling work for other EVIs. 174 EC - Extended Community 176 SR-TL - Segment Routing (SR) Tunnel Label (TL). 178 2. Problem Statement 180 EVPN is designed to provide a better VPLS service than RFC4761/ 181 RFC4762, and EVPN indeed introduced many new features which couldn't 182 be achieved in those old VPLS implemention.But EVPN didn't inherit 183 all features of old VPLS, and a few issues arises for EVPN only. 185 Some of these issues can be imputed to the MP2P nature of EVPN 186 labels. The PW label in old VPLS is a label for P2P VC, so it 187 contains more context than a identifier in dataplane for it's VSI 188 instance. But the EVPN label just identifies it's VSI instnace and 189 it can't stand for the ingress PE in dataplane. So the following 190 issues arises with MPLS EVPN service: 192 * MPLS EVPN statistics can't be done per ingress PE. All flows from 193 remote PEs share the same statistics on egress PE, because they 194 share the same EVPN label and the egress PE can't pick them out in 195 the dataplane. 197 * MPLS EVPN can't support hub/spoke usecase, where the spoke PEs can 198 only connect to each other through the hub PE. Especially when at 199 least two of the spoke PEs are connected to a common route 200 reflector. 202 * MPLS EVPN can't work as an AR-REPLICATOR. Because the AR- 203 REPLICATOR will apply replication for the ingress AR-LEAF too. 204 But a packet shoud not be sent back to the AR-LEAF where it is 205 received from. 207 * MPLS EVPN SPE cannot make use of SR-MPLS anycast tunnel because 208 the two SPEs of the anycast tunnel will assign different EVPN 209 labels for the same EVPN route. 211 So this document introduces an compound label stack to take advantage 212 of both P2P VC and MP2P EVPN labels. 214 3. Using VC Label to Add Context Data to EVPN Flows 216 In order to add as much context as old VPLS to EVPN data packet, We 217 can construct a infrastructure by a full-mesh of context-VCs among 218 the EVPN PEs. 220 Take the context-VCs between PE-i and PE-j as an example, VC-ij is 221 the context-VC from PE-i to PE-j, and VC-ji is the context-VC from 222 PE-j to PE-i. The VC-ij identifies the PE-i node on PE-j. The VC-ji 223 identifies PE-j node on PE-i. The VC-label for VC-ij is called as 224 L-ij, and the VC-label for VC-ji is called as L-ji. 226 So the PE-i can push the L-ij onto the EVPN data packet for PE-j to 227 distinguish the packet of PE-i from other data packets. Because the 228 L-ij identifies the ingress PE of the data packet. 230 There are two styles of context-VC in this draft. One style is named 231 as shared context-VC, the other style is named as per-EVI context VC. 233 3.1. The Shared Context VCs 235 The shared context-VCs are dedicated to identify the context for a 236 data packet while the EVPN label still identifies the EVPN instance. 238 Note that typically a shared context VC can be shared by all the EVPN 239 instances between it's ingress PE and egress PE. In other words, we 240 don't have to establish a dedicated mesh of context VCs for each 241 specified EVPN service. So we called the shared context VCs as a 242 common infrastructure for those EVPN services. 244 3.2. The per-EVI Context VCs 246 The per-EVI context VCs are used to identify both the context 247 (typically the ingress-PE) and the EVPN instance for a data packet at 248 the same time. In other words, we have to establish a dedicated set 249 of per-EVI context VCs for each specified EVPN service. 251 4. Signalling for Shared Context VCs 253 The VCs of a context VC infrastructure are set up by a context VC 254 container, the container implements a VC signalling to set up the 255 VCs. There are two existing signalling protocol can be reused to set 256 up context VCs for a context VC container. 258 4.1. Kompella Signalling for Context VC 260 The signalling used by a Kompella VPLS instance per [RFC4761] can 261 also be used by a context VC container. 263 Different from the ordinary Kompella VPLS instances, a context VC 264 container only use the signalling to set up the context VCs. They 265 are the same in signalling but different in dataplane. Take the PW 266 between PE-i and PE-j as an example, it is constructed by VC-ij and 267 VC-ji, and none of the two context VCs will identify a MAC-VRF. In 268 other words the PW is a context PW. 270 Note that the context VC containers don't have a MAC-VRF or a MAC- 271 table, they are just containers for context VC. 273 4.2. SR-MPLS signalling for CSL-based Context VC 275 SR-MPLS signalling is very similar to the singleton pattern of 276 Kompella VPLS in the signalling behaviors, in spite of their 277 different data plane and service procedure. The SID is similar to 278 the VE-ID, the SRGB is similar to the label block. 280 So the established LSPs of the SR-MPLS signalling can be 281 reinterpreted as context VCs in another label space named S. These 282 context VCs use the same label values as those SR-LSPs but they are 283 established at the same time in different label spaces. Take the VC- 284 ij as an example, its label value L-ij is the same as the SID label 285 for PE-i (The label for the SR-LSP destined to PEi) in PE-j's SRGB. 287 But the VC-ij are established in the context label space S which is 288 identified by a static label, the static label is the CL of label 289 space S. VC-ij may not be established in the same label space as 290 that SID label for PE-i. 292 The context VC signalling may be [RFC8665], [RFC8666], [RFC8667]. 293 The context VC may be established along with SR-LSPs. 295 Note that the context VC label is a Context-specific Label (CSL), 296 that's why the context-VC is called CSL-based context-VC. The CL of 297 the SR-Signalling-Based Context-VCs may be the same value in the same 298 domain. In such case, the PEs in that domain don't have to signal 299 the CL to each other. 301 +---------------------------------+ 302 | underlay ethernet header | 303 +---------------------------------+ 304 | PSN tunnel label | 305 +---------------------------------+ 306 | EVPN label | 307 +---------------------------------+ 308 | Static CL for Label Space S | 309 +---------------------------------+ 310 | Context VC Label = L-ij | 311 +---------------------------------+ 312 | overlay ethernet or IP header | 313 +---------------------------------+ 315 Figure 1: Encapsulation of CSL-based Context VC 317 Note that the static CL is the context label for L-ij, while the L-ij 318 is the context label for the payload. 320 5. Signalling for per-EVI Context VCs 322 The IMET route per [RFC7432] have a corresponding route-type in MVPN. 323 It is, in effect, the Intra-AS I-PMSI route per [RFC6514]. The 324 difference between them is that an IMET route won't handle a 325 responding Leaf A-D route, but an Intra-AS I-PMSI route will. 327 The Leaf A-D route per [I-D.ietf-bess-evpn-bum-procedure-updates] is 328 required for per-EVI context VCs. In this draft, we use the Leaf A-D 329 route with IR-PTA to establish per-EVI context-VCs. The Leaf A-D 330 route is generated for an IMET route. 332 It is an update for [RFC7432]. The backward compatibility will be 333 described in Section 5.3. 335 5.1. Construct Leaf A-D Route for IR 337 PE1 will construct a Leaf A-D route with IR-PTA for EVI1 in response 338 to an IMET route R1 with IR-PTA. The IMET route R1 is received from 339 PE2 previously. The key fields of the IMET route is included in the 340 "Route Key" field of the Leaf A-D route (say R2) along with the ORIP 341 of PE1 itself. We call the ORIP of PE1 itself as the Leaf A-D 342 route's "self-ORIP" in order to distinguish it from the Leaf A-D 343 route's Root-ORIP. So the "Route Type sepcific" field of the Leaf 344 A-D route is per basis. 346 5.1.1. Advertising Per-platform VC Label 348 The MPLS label field in the IR-PTA of the Leaf A-D route is allocated 349 per basis in per-platform label space on PE1. So the 350 per-EVI context VC can identify the EVI1 too. 352 Note that PE1 may already advertise an IMET route R3 to PE2 before 353 the advertisement of above Leaf A-D route. 355 5.1.2. Advertising Context-Specific VC label 357 Note that the per basis label allocation (see 358 Section 5.1.1) may consume too many labels in per-platform label 359 space. Sometimes we want to use the same EVPN label in all Leaf A-D 360 routes and IMET routes of the same EVI. So we allocate a context- 361 specific label (CSL) for a context VC in this section. 363 The EVPN label is still allocated from per-platform label space, and 364 it identifies the EVPN instance as per [RFC7432]. But it also 365 identifies a context label space CLS1. The VC label of the context 366 VC is allocated in CLS1. So we say that the VC label is a context- 367 specific VC label. 369 We introduce a new BGP Extended Community called Context-specific 370 Label (CSL) Entry Extended Community, the CSL-Entry EC has the same 371 format as the Context Label Space ID Extended Community (Section 3.1 372 of [I-D.ietf-bess-mvpn-evpn-aggregation-label]) except for a few 373 notable differences. 375 The "sub-type" field of the CSL-Entry EC has a different codepoint 376 from the CLS-ID EC. The ID-Value of the CSL-Entry EC is a MPLS label 377 in a context-specific label space identified by the PTA label. And 378 the MPLS label in the CSL-Entry EC will be pushed onto the label 379 stack before the PTA label by the ingress PE. Typically, the MPLS 380 label of the CSL-Entry EC is a downstream assigned label, which means 381 that it will be used as an outgoing label by the PE receiving the 382 CSL-Entry EC, not as incomming label. 384 When constructing the Leaf A-D route, the IR-PTA label is the EVPN 385 Label, as per [RFC7432]. But the ID-value in the CSL-Entry EC is a 386 label (say L1) that is allocated per TPE basis in CLS1. In fact, L1 387 is the context-specific VC label of the context VC of that ingress 388 TPE. That's why the context VC is called as CSL-based context VC. 389 So the CLS1-specific VC label need to be pushed onto the label stack 390 before EVPN Label (which identifies CLS1) on ingress PEs. 392 Note that the CSL-Entry ECs (for different EVIs) received from the 393 same TPE may be the same label, because that all EVI labels on the 394 same PE may identify the same Context-specific Label Space (CLS). So 395 we can select a single EVI to use the Leaf A-D route with CSL-Entry 396 EC in such case. This EVI is called as administrating EVI (admin- 397 EVI). The context VC label carried in the Leaf A-D routes of the 398 admin-EVI will be used to take the place of the PTA label of the IMET 399 route with the same ORIP in all other ordinary EVIs in such case. 400 Note that all other ordinary EVIs don't use the Leaf A-D routes with 401 IR-PTA in their signalling procedures, they use ordinary IMET routes 402 instead. The admin-EVI need to be configured on all EVPN-PEs in such 403 case. 405 Such encapsulation is illustrated as the following figure: 407 +---------------------------------+ 408 | underlay ethernet header | 409 +---------------------------------+ 410 | PSN tunnel label | 411 +---------------------------------+ 412 | EVPN label | 413 +---------------------------------+ 414 | Context VC Label | 415 +---------------------------------+ 416 | overlay ethernet or IP header | 417 +---------------------------------+ 419 Figure 2: Encapsulation of EVI-Specific VC Label for EVPN Payload 421 Note that the Context-VC Label here is not the CLS-ID of the EVPN 422 Label. But the EVPN label is the CLS-ID of the Context-VC Label. 423 That's why the CLS-ID EC of 424 [I-D.ietf-bess-mvpn-evpn-aggregation-label] is not appropriate for 425 such encapsulation. 427 Note that when the PTA label is changed to a new value (caused by the 428 BGP nexthop rewriting) by the SPE nodes, the CSL-Entry in the same 429 EVPN route won't be rewrite. This is similar to the behavior of ESI 430 Label EC of EAD per ES route. 432 5.2. Establish Ingress Replication List by Leaf A-D Route 434 PE2 receives the responding Leaf A-D route (say R2) of the IMET route 435 R1 which is previously advertised by itself, and PE2 preiously 436 received an IMET route R3 with the same ORIP as the self-ORIP of R2 . 437 Given that R1,R2 and R3 both have a IR-PTA, PE2 SHOULD use R2 to 438 install the Ingress Replication List (IRL) item for PE1 instead, and 439 R3 will not used to install the IRL-item for PE1 from then on. 441 Note that when R2 included a CSL-Entry EC, the ID-value of the CSL- 442 Entry EC will be used as the outgoing label of the IRL-item. The 443 MPLS label of the IR-PTA will be used as the context label (CL) of 444 the CSL-Entry in NHLFE. No ILM entry will be installed for the CSL 445 of R2 on PE2. 447 5.3. Backward Compatibility 449 In [RFC7432], the LIR flag of IMET route is required to be zero when 450 it is advertised and to be ignored on receipt. 452 It means that the LIR flag is reserved by IMET routes, but it 453 technically can be used in the future. What should the LIR flag be 454 restrained in the future use is no more severer than any other 455 reserved PTA flags in the IMET routes. 457 So when PE2 set the LIR flag to one in the IMET route and send it to 458 PE1, PE2 won't expect that the IMET route must be responded by a Leaf 459 A-D. When the corresponding Leaf A-D route can't be received from 460 PE1, the IMET route from PE1 still be used as per [RFC7432]. But 461 when PE1 is a new PE following this draft, PE1 will indeed respond a 462 Leaf A-D route for the IMET route. 464 6. Solutions 466 6.1. Solution for Source-Squelching in Hub-Spoke Scenarios 468 PEs1--------RR1--------PEh---------RR2--------PEs3 469 / 470 PEs2-------/ 472 Figure 3: Hub PE and Spoke PEs 474 Now take above use case for example, there are three spoke PEs and 475 one hub PE. The spoke PEs are PEs1, PEs2 and PEs3. The hub PE is 476 PEh. Two of the spoke PEs (PEs1 and PEs2) are connected to the same 477 RR group and the third one connects to another RR group. 479 Although we can advertise different EVPN labels for different RR 480 groups, we can't advertise different EVPN labels for PEs1 and PEs2. 482 But PEh can request PEs1 or PEs2 to push the label of the context VC 483 from them to PEh. Benefit from the context VC label, PEh can 484 distinguish where the packet from, in other words, PEh can decide 485 where the packet can't be sent to. 487 The signaling for the hub PE to request the spoke PE to push the 488 context VC label will be added in future versions. 490 Note that although PEs1 and PEs2 can receive EVPN routes from each 491 other they won't import these routes because of the hub/spoke 492 behaviors. 494 6.2. Solution for per ingress statistics 496 We use CSL-based per-EVI context-VCs(see Section 5.1.2) to do per- 497 ingress statistics. 499 Note that The per-platform label space can be used as CLS1 at the 500 same time. In such case, the inner context-VC label is similar to 501 the downstream-assigned ESI-label in ILM-lookup behavior. Such 502 context-VC is very similar to the shared context VC too. 504 Note that when PE1 sends a Leaf A-D route with a CSL-Entry EC to PE2, 505 but PE2 don't recognize the CSL-Entry EC, then PE2 will encapsulate 506 the EVPN label without the inner context-VC label. If CLS1 is 507 actually identical to the per-platform label space, this will work as 508 well as [RFC7432], although the per-ingress statistics can't be 509 executed. 511 Note that legacy PEs will not send a Leaf A-D route in response to an 512 IMET route even if the LIR flag in the IMET route is set to one. So 513 when legacy PEs and new PEs following this section coexist in the 514 same EVI, they can interwork well, but only the new PEs can do per- 515 ingress statistics. 517 6.3. Solution for AR REPLICATOR in MPLS EVPN 518 LEAF1--------REPLICATOR1--------RNVE1 519 / 520 LEAF2-----------/ 522 Figure 4: AR REPLICATOR in MPLS EVPN 524 When REPLICATOR1 node recieves an IMET Route with AR-role = AR-LEAF 525 from LEAF1 node, REPLICATOR1 SHOLD respond to it with an Leaf A-D 526 route with AR-PTA. The MPLS label field of the AR-PTA (say AR-PTA 527 Label) will be allocated following the same rules as the IR-PTA Label 528 in Section 5.1. When ALEAF1 receives above Leaf A-D route, the Leaf 529 A-D route is treated as a Replicator-AR route for the same ORIP, and 530 then the control-plane procedures works following 531 [I-D.ietf-bess-evpn-optimized-ir]. When REPLICATOR1 receives data 532 packets from the AR-PTA Label, REPLICATOR1 will do source-squelching 533 for LEAF1 which means that these data packets will not be forwarded 534 back to LEAF1. 536 Note that the old Replicator-AR route which is in terms of IMET route 537 will not be used by MPLS EVPN AR-REPLICATOR. Because that the Leaf 538 A-D routes will take it's place per AR-LEAF basis. But the old 539 Regular-IR route can still be used by MPLS EVPN AR-REPLICATORs. 541 Note that the AR-REPLICATOR don't have to set the LIR flag of its 542 IMET routes to one. We suggest that when receiving an IMET route 543 with AR-role = AR-LEAF and tunnel-encapsulation = MPLS, the above 544 Leaf A-D route SHOULD be generated for that IMET route, even if the 545 LIR flag is set to zero. 547 6.4. Solution for anycast tunnel usage on SPE 549 /--------SPE1-------\ 550 TPE1 TPE2 551 \--------SPE2-------/ 553 Figure 5: SPE with Anycast Tunnel 555 Now take above use case for example, the two SPEs are the egress 556 nodes of an anycast SR-MPLS tunnel. The anycast SR-MPLS tunnel is 557 used to transport flows from TPE1 to either SPE1 or SPE2 according to 558 load balancing procedures. So SPE1 and SPE2 have to advertise the 559 same EVPN label independently for a given EVPN route. 561 6.4.1. Control-plane 563 In fact, SPE1 and SPE2 can simply inherit the EVPN label (say EVL4) 564 from TPE2, and they advertise it to TPE1 along with a context-VC 565 label (say VCL4). The context-VC label is for the shared context-VC 566 from TPE2 to SPE1 or SPE2. We can make the VC labels from TPE2 to 567 SPE1 and SPE2 have the same value through configuring. 569 Note that the context-VCs can be established according to 570 Section 4.2. Note that VCL4 has the same value as the SR-LSP to TPE2 571 according to Section 4.2. Note that VCL4 identify a Label Space (say 572 TPE2-specific CLS) that is dedicated to turning the EVPN label 573 received from TPE2 into an incoming label on the SPEs. When SPE1 574 receives EVPN labels from different TPEs, SPE1 MUST use different CLS 575 to install the corresponding ILM entry for Label swapping. 577 6.4.2. Data-plane 579 The label stack on the anycast SR-MPLS tunnel is constructed by TPE1 580 as the following: 582 +---------------------------------+ 583 | underlay ethernet header | 584 +---------------------------------+ 585 | Anycast SR-TL = SR_LSP_to_SPEx | 586 +---------------------------------+ 587 | Static CL = CL4 | 588 +---------------------------------+ 589 | Context-VC Label = VCL4 | 590 +---------------------------------+ 591 | EVPN label = EVL4 | 592 +---------------------------------+ 593 | overlay ethernet or IP header | 594 +---------------------------------+ 596 Figure 6: Anycast SPE dataplane 598 Note that the SR Tunnel Label (TL) in the label stack is the SR-LSP 599 label from TPE1 to the SPE1 or SPE2. 601 Note that the context-VC is also constructed in a context label space 602 (say CLS4), the label space CLS4 is identified by a static label (say 603 CL4). And the CLS4 is identified by the same CL4 on all PEs of the 604 service domain. so the label stacks on the anycast tunnel are the 605 same for SPE1 and SPE2. 607 Then SPE1/SPE2 will perform ILM lookup for the EVPN label in the 608 "TPE2-specific label space" which is identified by the context-VC 609 label VCL4. The label operation will be swap, and the new outgoing 610 EVPN label will be the same value. 612 7. Security Considerations 614 This section will be added in future versions. 616 8. IANA Considerations 618 The IANA considerations for CSL-Entry EC in Section 5.1.2 will be 619 added in future versions. 621 9. Acknowledgements 623 The authors would like to thank the following for their comments and 624 review of this document: 626 Benchong Xu. 628 10. References 630 10.1. Normative References 632 [I-D.ietf-bess-evpn-bum-procedure-updates] 633 Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. 634 Sajassi, "Updates on EVPN BUM Procedures", Work in 635 Progress, Internet-Draft, draft-ietf-bess-evpn-bum- 636 procedure-updates-08, 18 November 2019, 637 . 640 [I-D.ietf-bess-evpn-optimized-ir] 641 Rabadan, J., Sathappan, S., Lin, W., Katiyar, M., and A. 642 Sajassi, "Optimized Ingress Replication solution for 643 EVPN", Work in Progress, Internet-Draft, draft-ietf-bess- 644 evpn-optimized-ir-06, 19 October 2018, 645 . 648 [I-D.ietf-bess-mvpn-evpn-aggregation-label] 649 Zhang, Z., Rosen, E., Lin, W., Li, Z., and I. Wijnands, 650 "MVPN/EVPN Tunnel Aggregation with Common Labels", Work in 651 Progress, Internet-Draft, draft-ietf-bess-mvpn-evpn- 652 aggregation-label-03, 24 October 2019, 653 . 656 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 657 Encodings and Procedures for Multicast in MPLS/BGP IP 658 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 659 . 661 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 662 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 663 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 664 2015, . 666 10.2. Informative References 668 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 669 LAN Service (VPLS) Using BGP for Auto-Discovery and 670 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 671 . 673 [RFC5331] Aggarwal, R., Rekhter, Y., and E. Rosen, "MPLS Upstream 674 Label Assignment and Context-Specific Label Space", 675 RFC 5331, DOI 10.17487/RFC5331, August 2008, 676 . 678 [RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler, 679 H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 680 Extensions for Segment Routing", RFC 8665, 681 DOI 10.17487/RFC8665, December 2019, 682 . 684 [RFC8666] Psenak, P., Ed. and S. Previdi, Ed., "OSPFv3 Extensions 685 for Segment Routing", RFC 8666, DOI 10.17487/RFC8666, 686 December 2019, . 688 [RFC8667] Previdi, S., Ed., Ginsberg, L., Ed., Filsfils, C., 689 Bashandy, A., Gredler, H., and B. Decraene, "IS-IS 690 Extensions for Segment Routing", RFC 8667, 691 DOI 10.17487/RFC8667, December 2019, 692 . 694 Authors' Addresses 696 Yubao Wang 697 ZTE Corporation 698 No. 50 Software Ave, Yuhuatai Distinct 699 Nanjing 700 China 702 Email: yubao.wang2008@hotmail.com 703 Bing Song 704 ZTE Corporation 705 No. 50 Software Ave, Yuhuatai Distinct 706 Nanjing 707 China 709 Email: song.bing@zte.com.cn