idnits 2.17.1 draft-zzhang-bess-evpn-bum-procedure-updates-03.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 IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 16 instances of too long lines in the document, the longest one being 3 characters in excess of 72. -- The draft header indicates that this document updates RFC7432, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2016) is 2921 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: 'RFC 7524' is mentioned on line 172, but not defined == Unused Reference: 'I-D.ietf-bess-ir' is defined on line 640, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 645, but no explicit reference was found in the text == Unused Reference: 'RFC7117' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC7432' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'RFC7524' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-dci-evpn-overlay' is defined on line 668, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-overlay' is defined on line 674, but no explicit reference was found in the text == Unused Reference: 'I-D.rabadan-bess-evpn-optimized-ir' is defined on line 680, but no explicit reference was found in the text == Unused Reference: 'I-D.wijnands-bier-architecture' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC6513' is defined on line 692, but no explicit reference was found in the text == Unused Reference: 'RFC6514' is defined on line 696, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-bess-ir-00 == Outdated reference: A later version (-10) exists of draft-ietf-bess-dci-evpn-overlay-00 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-01 == Outdated reference: A later version (-02) exists of draft-rabadan-bess-evpn-optimized-ir-00 Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BESS Z. Zhang 3 Internet-Draft W. Lin 4 Updates: 7432 (if approved) Juniper Networks 5 Intended status: Standards Track J. Rabadan 6 Expires: October 23, 2016 Nokia 7 K. Patel 8 Cisco Systems 9 April 21, 2016 11 Updates on EVPN BUM Procedures 12 draft-zzhang-bess-evpn-bum-procedure-updates-03 14 Abstract 16 This document specifies procedure updates for broadcast, unknown 17 unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), 18 including selective multicast, and provider tunnel segmentation. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC2119. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on October 23, 2016. 43 Copyright Notice 45 Copyright (c) 2016 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2.1. Reasons for Tunnel Segmentation . . . . . . . . . . . . . 4 63 3. Additional Route Types of EVPN NLRI . . . . . . . . . . . . . 5 64 3.1. Per-Region I-PMSI A-D route . . . . . . . . . . . . . . . 5 65 3.2. S-PMSI A-D route . . . . . . . . . . . . . . . . . . . . 6 66 3.3. Leaf-AD route . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Selective Multicast . . . . . . . . . . . . . . . . . . . . . 7 68 5. Inter-AS Segmentation . . . . . . . . . . . . . . . . . . . . 7 69 5.1. Changes to Section 7.2.2 of RFC 7117 . . . . . . . . . . 7 70 5.2. I-PMSI Leaf Tracking . . . . . . . . . . . . . . . . . . 8 71 5.3. Backward Compatibility . . . . . . . . . . . . . . . . . 9 72 6. Inter-Region Segmentation . . . . . . . . . . . . . . . . . . 10 73 6.1. Area vs. Region . . . . . . . . . . . . . . . . . . . . . 10 74 6.2. Per-region Aggregation . . . . . . . . . . . . . . . . . 12 75 6.3. Use of S-NH-EC . . . . . . . . . . . . . . . . . . . . . 13 76 6.4. Ingress PE's I-PMSI Leaf Tracking . . . . . . . . . . . . 13 77 7. Multi-homing Support . . . . . . . . . . . . . . . . . . . . 13 78 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 80 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 81 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. Normative References . . . . . . . . . . . . . . . . . . 14 83 11.2. Informative References . . . . . . . . . . . . . . . . . 15 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 86 1. Terminology 88 To be added 90 2. Introduction 92 RFC 7432 specifies procedures to handle broadcast, unknown unicast, 93 and multicast (BUM) traffic in Section 11, 12 and 16, using Inclusive 94 Multicast Ethernet Tag Route. A lot of details are referred to RFC 95 7117 (VPLS Multicast). In particular, selective multicast is briefly 96 mentioned for Ingress Replication but referred to RFC 7117. 98 RFC 7117 specifies procedures for using both inclusive tunnels and 99 selective tunnels, similar to MVPN procedures specified in RFC 6513 100 and RFC 6514. A new SAFI "MCAST-VPLS" is introduced, with two types 101 of NLRIs that match MVPN's S-PMSI A-D routes and Leaf A-D routes. 102 The same procedures can be applied to EVPN selective multicast for 103 both Ingress Replication and other tunnel types, but new route types 104 need to be defined under the same EVPN SAFI. 106 MVPN uses terms I-PMSI and S-PMSI A-D Routes. For consistency and 107 convenience, this document will use the same I/S-PMSI terms for VPLS 108 and EVPN. In particular, EVPN's Inclusive Multicast Ethernet Tag 109 Route and VPLS's VPLS A-D route carrying PTA (PMSI Tunnel Attribute) 110 for BUM traffic purpose will all be referred to as I-PMSI A-D routes. 111 Depending on the context, they may be used interchangeably. 113 MVPN provider tunnels and EVPN/VPLS BUM provider tunnels, which are 114 referred to as MVPN/EVPN/VPLS provider tunnels in this document for 115 simplicity, can be segmented for technical or administrative reasons, 116 which are summarized in Section 2.1 of this document. RFC 6513/6514 117 cover MVPN inter-as segmentation, RFC 7117 covers VPLS multicast 118 inter-as segmentation, and RFC 7524 (Seamless MPLS Multicast) covers 119 inter-area segmentation for both MVPN and VPLS. 121 There is a difference between MVPN and VPLS multicast inter-as 122 segmentation. For simplicity, EVPN uses the same procedures as in 123 MVPN. All ASBRs can re-advertise their choice of the best route. 124 Each can become the root of its intra-AS segment and inject traffic 125 it receives from its upstream, while each downstream PE/ASBR will 126 only pick one of the upstream ASBRs as its upstream. This is also 127 the behavior even for VPLS in case of inter-area segmentation. 129 For inter-area segmentation, RFC 7524 requires the use of Inter-area 130 P2MP Segmented Next-Hop Extended Community (S-NH-EC), and the setting 131 of "Leaf Information Required" (LIR) flag in PTA in certain 132 situations. Either of these could be optional in case of EVPN. 133 Removing these requirements would make the segmentation procedures 134 transparent to ingress and egress PEs. 136 RFC 7524 assumes that segmentation happens at area borders. However, 137 it could be at "regional" borders, where a region could be a sub- 138 area, or even an entire AS plus its external links (Section 6). That 139 would allow for more flexible deployment scenarios (e.g. for single- 140 area provider networks). 142 This document specifies/clarifies/redefines certain/additional EVPN 143 BUM procedures, with a salient goal that they're better aligned among 144 MVPN, EVPN and VPLS. For brevity, only changes/additions to relevant 145 RFC 7117 and RFC 7524 procedures are specified, instead of repeating 146 the entire procedures. Note that these are to be applied to EVPN 147 only, even though sometimes they may sound to be updates to RFC 148 7117/7524. 150 2.1. Reasons for Tunnel Segmentation 152 Tunnel segmentation may be required and/or desired because of 153 administrative and/or technical reasons. 155 For example, an MVPN/VPLS/EVPN network may span multiple providers 156 and Inter-AS Option-B has to be used, in which the end-to-end 157 provider tunnels have to be segmented at and stitched by the ASBRs. 158 Different providers may use different tunnel technologies (e.g., 159 provider A uses Ingress Replication, provider B uses RSVP-TE P2MP 160 while provider C uses mLDP). Even if they use the same tunnel 161 technology like RSVP-TE P2MP, it may be impractical to set up the 162 tunnels across provider boundaries. 164 The same situations may apply between the ASes and/or areas of a 165 single provider. For example, the backbone area may use RSVP-TE P2MP 166 tunnels while non-backbone areas may use mLDP tunnels. 168 Segmentation can also be used to divide an AS/area to smaller 169 regions, so that control plane state and/or forwarding plane state/ 170 burden can be limited to that of individual regions. For example, 171 instead of Ingress Replicating to 100 PEs in the entire AS, with 172 inter-area segmentation [RFC 7524] a PE only needs to replicate to 173 local PEs and ABRs. The ABRs will further replicate to their 174 downstream PEs and ABRs. This not only reduces the forwarding plane 175 burden, but also reduces the leaf tracking burden in the control 176 plane. 178 Smaller regions also have the benefit that, in case of tunnel 179 aggregation, it is easier to find congruence among the segments of 180 different constituent (service) tunnels and the resulting aggregation 181 (base) tunnel in a region. This leads to better bandwidth 182 efficiency, because the more congruent they are, the fewer leaves of 183 the base tunnel need to discard traffic when a service tunnel's 184 segment does not need to receive the traffic (yet it is receiving the 185 traffic due to aggregation). 187 Another advantage of the smaller region is smaller BIER sub-domains. 188 In this new multicast architecture BIER, packets carry a BitString, 189 in which the bits correspond to edge routers that needs to receive 190 traffic. Smaller sub-domains means smaller BitStrings can be used 191 without having to send multiple copies of the same packet. 193 3. Additional Route Types of EVPN NLRI 195 RFC 7432 defines the format of EVPN NLRI as the following: 197 +-----------------------------------+ 198 | Route Type (1 octet) | 199 +-----------------------------------+ 200 | Length (1 octet) | 201 +-----------------------------------+ 202 | Route Type specific (variable) | 203 +-----------------------------------+ 205 So far five types have been defined: 207 + 1 - Ethernet Auto-Discovery (A-D) route 208 + 2 - MAC/IP Advertisement route 209 + 3 - Inclusive Multicast Ethernet Tag route 210 + 4 - Ethernet Segment route 211 + 5 - IP Prefix Route 213 This document defines three additional route types: 215 + 6 - Per-Region I-PMSI A-D route 216 + 7 - S-PMSI A-D route 217 + 8 - Leaf A-D route 219 The "Route Type specific" field of the type 6 and type 7 EVPN NLRIs 220 starts with a type 1 RD, whose Administrative sub-field MUST match 221 that of the RD in all the EVPN routes from the same advertising 222 router for a given EVI, except the Leaf A-D route (Section 3.3). 224 3.1. Per-Region I-PMSI A-D route 226 The Per-region I-PMSI A-D route has the following format. Its usage 227 is discussed in Section 6.2. 229 +-----------------------------------+ 230 | RD (8 octets) | 231 +-----------------------------------+ 232 | Ethernet Tag ID (4 octets) | 233 +-----------------------------------+ 234 | Extended Community (8 octets) | 235 +-----------------------------------+ 237 After Ethernet Tag ID, an Extended Community (EC) is used to identify 238 the region. Various types and sub-types of ECs provide maximum 239 flexibility. Note that this is not an EC Attribute, but an 8-octet 240 field embedded in the NLRI itself, following EC encoding scheme. 242 3.2. S-PMSI A-D route 244 The S-PMSI A-D route has the following format: 246 +-----------------------------------+ 247 | RD (8 octets) | 248 +-----------------------------------+ 249 | Ethernet Tag ID (4 octets) | 250 +-----------------------------------+ 251 | Multicast Source Length (1 octet) | 252 +-----------------------------------+ 253 | Multicast Source (Variable) | 254 +-----------------------------------+ 255 | Multicast Group Length (1 octet) | 256 +-----------------------------------+ 257 | Multicast Group (Variable) | 258 +-----------------------------------+ 259 | Originating Router's IP Addr | 260 +-----------------------------------+ 262 Other than the addition of Ethernet Tag ID, it is identical to the 263 S-PMSI A-D route as defined in RFC 7117. The procedures in RFC 7117 264 also apply (including wildcard functionality), except that the 265 granularity level is per Ethernet Tag. 267 3.3. Leaf-AD route 269 The Route Type specific field of a Leaf A-D route consists of the 270 following: 272 +-----------------------------------+ 273 | Route Key (variable) | 274 +-----------------------------------+ 275 | Originating Router's IP Addr | 276 +-----------------------------------+ 278 A Leaf A-D route is originated in response to a PMSI route, which 279 could be an Inclusive Multicast Tag route, a per-region I-PMSI A-D 280 route, an S-PMSI A-D route, or some other types of routes that may be 281 defined in the future that triggers Leaf A-D routes. The Route Key 282 is the "Route Type Specific" field of the route for which this Leaf 283 A-D route is generated. 285 The general procedures of Leaf A-D route are first specified in RFC 286 6514 for MVPN. The principles apply to VPLS and EVPN as well. RFC 287 7117 has details for VPLS Multicast, and this document points out 288 some specifics for EVPN, e.g. in Section 5. 290 4. Selective Multicast 292 RFC 7117 specifies Selective Multicast for VPLS. Other than that 293 different route types and formats are specified with EVPN SAFI for 294 S-PMSI A-D and Leaf A-D routes (Section 3), all procedures in RFC 295 7117 with respect to Selective Multicast apply to EVPN as well, 296 including wildcard procedures. 298 5. Inter-AS Segmentation 300 5.1. Changes to Section 7.2.2 of RFC 7117 302 The first paragraph of Section 7.2.2.2 of RFC 7117 says: 304 "... The best route procedures ensure that if multiple 305 ASBRs, in an AS, receive the same Inter-AS A-D route from their EBGP 306 neighbors, only one of these ASBRs propagates this route in Internal 307 BGP (IBGP). This ASBR becomes the root of the intra-AS segment of 308 the inter-AS tree and ensures that this is the only ASBR that accepts 309 traffic into this AS from the inter-AS tree." 311 The above VPLS behavior requires complicated VPLS specific procedures 312 for the ASBRs to reach agreement. For EVPN, a different approach is 313 used and the above quoted text is not applicable to EVPN. 315 The Leaf A-D based procedure is used for each ASBR who re-advertises 316 into the AS to discover the leaves on the segment rooted at itself. 317 This is the same as the procedures for S-PMSI in RFC 7117 itself. 319 The following text at the end of the second bullet: 321 "................................................... If, in order 322 to instantiate the segment, the ASBR needs to know the leaves of 323 the tree, then the ASBR obtains this information from the A-D 324 routes received from other PEs/ASBRs in the ASBR's own AS." 326 is changed to the following: 328 "................................................... If, in order 329 to instantiate the segment, the ASBR needs to know the leaves of 330 the tree, then the ASBR MUST set the LIR flag to 1 in the PTA to 331 trigger Leaf A-D routes from egress PEs and downstream ASBRs. 332 It MUST be (auto-)configured with an import RT, which controls 333 acceptance of leaf A-D routes by the ASBR." 335 Accordingly, the following paragraph in Section 7.2.2.4: 337 "If the received Inter-AS A-D route carries the PMSI Tunnel attribute 338 with the Tunnel Identifier set to RSVP-TE P2MP LSP, then the ASBR 339 that originated the route MUST establish an RSVP-TE P2MP LSP with the 340 local PE/ASBR as a leaf. This LSP MAY have been established before 341 the local PE/ASBR receives the route, or it MAY be established after 342 the local PE receives the route." 344 is changed to the following: 346 "If the received Inter-AS A-D route has the LIR flag set in its PTA, 347 then a receiving PE must originate a corresponding Leaf A-D route, 348 and a receiving ASBR must originate a corresponding Leaf A-D route 349 if and only if it received and imported one or more corresponding Leaf 350 A-D routes from its downstream IBGP or EBGP peers, or it has non-null 351 downstream forwarding state for the PIM/mLDP tunnel that instantiates 352 its downstream intra-AS segment. The ASBR that (re-)advertised the 353 Inter-AS A-D route then establishes a tunnel to the leaves discovered 354 by the Leaf A-D routes." 356 5.2. I-PMSI Leaf Tracking 358 An ingress PE does not set the LIR flag in its I-PMSI's PTA, even 359 with Ingress Replication or RSVP-TE P2MP tunnels. It does not rely 360 on the Leaf A-D routes to discover leaves in its AS, and Section 11.2 361 of RFC 7432 explicitly states that the LIR flag must be set to zero. 363 An implementation of RFC 7432 might have used the Originating 364 Router's IP Address field of the Inclusive Multicast Ethernet Tag 365 routes to determine the leaves, or might have used the Next Hop field 366 instead. Within the same AS, both will lead to the same result. 368 With segmentation, an ingress PE MUST determine the leaves in its AS 369 from the BGP next hops in all its received I-PMSI A-D routes, so it 370 does not have to set the LIR bit set to request Leaf A-D routes. PEs 371 within the same AS will all have different next hops in their I-PMSI 372 A-D routes (hence will all be considered as leaves), and PEs from 373 other ASes will have the next hop in their I-PMSI A-D routes set to 374 addresses of ASBRs in this local AS, hence only those ASBRs will be 375 considered as leaves (as proxies for those PEs in other ASes). Note 376 that in case of Ingress Replication, when an ASBR re-advertises IBGP 377 I-PMSI A-D routes, it MUST advertise the same label for all those for 378 the same Ethernet Tag ID and the same EVI. When an ingress PE builds 379 its flooding list, multiple routes may have the same (nexthop, label) 380 tuple and they will only be added as a single branch in the flooding 381 list. 383 5.3. Backward Compatibility 385 The above procedures assume that all PEs are upgraded to support the 386 segmentation procedures: 388 o An ingress PE uses the Next Hop instead of Originating Router's IP 389 Address to determine leaves for the I-PMSI tunnel. 391 o An egress PE sends Leaf A-D routes in response to I-PMSI routes, 392 if the PTA has the LIR flag set (by the re-advertising ASBRs). 394 o In case of Ingress Replication, when an ingress PE builds its 395 flooding list, multiple I-PMSI routes may have the same (nexthop, 396 label) tuple and only a single branch for those will be added in 397 the flooding list. 399 If a deployment has legacy PEs that does not support the above, then 400 a legacy ingress PE would include all PEs (including those in remote 401 ASes) as leaves of the inclusive tunnel and try to send traffic to 402 them directly (no segmentation), which is either undesired or not 403 possible; a legacy egress PE would not send Leaf A-D routes so the 404 ASBRs would not know to send external traffic to them. 406 To address this backward compatibility problem, the following 407 procedure can be used (see Section 6.2 for per-PE/AS/region I-PMSI 408 A-D routes): 410 o An upgraded PE indicates in its per-PE I-PMSI A-D route that it 411 supports the new procedures. Details will be provided in a future 412 revision. 414 o All per-PE I-PMSI A-D routes are restricted to the local AS and 415 not propagated to external peers. 417 o The ASBRs in an AS originate per-region I-PMSI A-D routes and 418 advertise to their external peers to advertise tunnels used to 419 carry traffic from the local AS to other ASes. Depending on the 420 types of tunnels being used, the LIR flag in the PTA may be set, 421 in which case the downstream ASBRs and upgraded PEs will send Leaf 422 A-D routes to pull traffic from their upstream ASBRs. In a 423 particular downstream AS, one of the ASBRs is elected, based on 424 the per-region I-PMSI A-D routes for a particular source AS, to 425 send traffic from that source AS to legacy PEs in the downstream 426 AS. The traffic arrives at the elected ASBR on the tunnel 427 announced in the best per-region I-PMSI A-D route for the source 428 AS, that the ASBR has selected of all those that it received over 429 EBGP or IBGP sessions. Details of the election procedure will be 430 provided in a future revision. 432 o In an ingress AS, if and only if an ASBR has active downstream 433 receivers (PEs and ASBRs), which are learned either explicitly via 434 Leaf AD routes or implicitly via PIM join or mLDP label mapping, 435 the ASBR originates a per-PE I-PMSI A-D route (i.e., regular 436 Inclusive Multicast Ethernet Tag route) into the local AS, and 437 stitches incoming per-PE I-PMSI tunnels into its per-region I-PMSI 438 tunnel. With this, it gets traffic from local PEs and send to 439 other ASes via the tunnel announced in its per-region I-PMSI A-D 440 route. 442 Note that, even if there is no backward compatibility issue, the 443 above procedures have the benefit of keeping all per-PE I-PMSI A-D 444 routes in their local ASes, greatly reducing the flooding of the 445 routes and their corresponding Leaf A-D routes (when needed), and the 446 number of inter-as tunnels. 448 6. Inter-Region Segmentation 450 6.1. Area vs. Region 452 RFC 7524 is for MVPN/VPLS inter-area segmentation and does not 453 explicitly cover EVPN. However, if "area" is replaced by "region" 454 and "ABR" is replaced by "RBR" (Regional Border Router) then 455 everything still works, and can be applied to EVPN as well. 457 A region can be a sub-area, or can be an entire AS including its 458 external links. Instead of automatic region definition based on IGP 459 areas, a region would be defined as a BGP peer group. In fact, even 460 with IGP area based region definition, a BGP peer group listing the 461 PEs and ABRs in an area is still needed. 463 Consider the following example diagram: 465 --------- ------ --------- 466 / \ / \ / \ 467 / \ / \ / \ 468 | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | 469 \ / \ / \ / 470 \ / \ / \ / 471 --------- ------ --------- 472 AS 100 AS 200 AS 300 473 |-----------|--------|---------|--------|------------| 474 segment1 segment2 segment3 segment4 segment5 476 The inter-as segmentation procedures specified so far (RFC 6513/6514, 477 7117, and Section 5 of this document) requires all ASBRs to be 478 involved, and Ingress Replication is used between two ASBRs in 479 different ASes. 481 In the above diagram, it's possible that ASBR1/4 does not support 482 segmentation, and the provider tunnels in AS 100/300 can actually 483 extend across the external link. In the case, the inter-region 484 segmentation procedures can be used instead - a region is the entire 485 (AS100 + ASBR1-ASBR2 link) or (AS300 + ASBR3-ASBR4 link). ASBR2/3 486 would be the RBRs, and ASBR1/4 will just be a transit core router 487 with respect to provider tunnels. 489 As illustrated in the diagram below, ASBR2/3 will establish a 490 multihop EBGP session with either a RR or directly with PEs in the 491 neighboring AS. I/S-PMSI A-D routes from ingress PEs will not be 492 processed by ASBR1/4. When ASBR2 re-advertises the routes into AS 493 200, it changes the next hop to its own address and changes PTA to 494 specify the tunnel type/identification in its own AS. When ASBR3 re- 495 advertises I/S-PMSI A-D routes into the neighboring AS 300, it 496 changes the next hop to its own address and changes PTA to specify 497 the tunnel type/identification in the neighboring region 3. Now the 498 segment is rooted at ASBR3 and extends across the external link to 499 PEs. 501 --------- ------ --------- 502 / RR....\.mh-ebpg / \ mh-ebgp/....RR \ 503 / : \ `. / \ .' / : \ 504 | PE1 o ASBR1 -- ASBR2 ASBR3 -- ASBR4 o PE2 | 505 \ / \ / \ / 506 \ / \ / \ / 507 --------- ------ --------- 508 AS 100 AS 200 AS 300 509 |-------------------|----------|---------------------| 510 segment 1 segment 2 segment 3 512 6.2. Per-region Aggregation 514 Notice that every I/S-PMSI route from each PE will be propagated 515 throughout all the ASes or regions. They may also trigger 516 corresponding Leaf A-D routes depending on the types of tunnels used 517 in each region. This may become too many - routes and corresponding 518 tunnels. To address this concern, the I-PMSI routes from all PEs in 519 a AS/region can be aggregated into a single I-PMSI route originated 520 from the RBRs, and traffic from all those individual I-PMSI tunnels 521 will be switched into the single I-PMSI tunnel. This is like the 522 MVPN Inter-AS I-PMSI route originated by ASBRs. 524 The MVPN Inter-AS I-PMSI A-D route can be better called as per-AS 525 I-PMSI A-D route, to be compared against the (per-PE) Intra-AS I-PMSI 526 A-D routes originated by each PE. In this document we will call it 527 as per-region I-PMSI A-D route, in case we want to apply the 528 aggregation at regional level. The per-PE I-PMSI routes will not be 529 propagated to other regions. If multiple RBRs are connected to a 530 region, then each will advertise such a route, with the same route 531 key (Section 3.1). Similar to the per-PE I-PMSI A-D routes, RBRs/PEs 532 in a downstream region will each select a best one from all those re- 533 advertised by the upstream RBRs, hence will only receive traffic 534 injected by one of them. 536 MVPN does not aggregate S-PMSI routes from all PEs in an AS like it 537 does for I-PMSIs routes, because the number of PEs that will 538 advertise S-PMSI routes for the same (s,g) or (*,g) is small. This 539 is also the case for EVPN, i.e., there is no per-region S-PMSI 540 routes. 542 Notice that per-region I-PMSI routes can also be used to address 543 backwards compatibility issue, as discussed in Section 5.3. 545 The per-region I-PMSI route uses an embedded EC in NLRI to identify a 546 region. As long as it uniquely identifies the region and the RBRs 547 for the same region uses the same EC it is permitted. In the case 548 where an AS number or area ID is needed, the following can be used: 550 o For a two-octet AS number, a Transitive Two-Octet AS-Specific EC 551 of sub-type 0x09 (Source AS), with the Global Administrator sub- 552 field set to the AS number and the Local Administrator sub-field 553 set to 0. 555 o For a four-octet AS number, a Transitive Four-Octet AS-Specific EC 556 of sub-type 0x09 (Source AS), with the Global Administrator sub- 557 field set to the AS number and the Local Administrator sub-field 558 set to 0. 560 o For an area ID, a Transitive IPv4-Address-Specific EC of any sub- 561 type. 563 Uses of other particular ECs may be specified in other documents. 565 6.3. Use of S-NH-EC 567 RFC 7524 specifies the use of S-NH-EC because it does not allow ABRs 568 to change the BGP next hop when they re-advertise I/S-PMSI AD routes 569 to downstream areas. That is only to be consistent with the MVPN 570 Inter-AS I-PMSI A-D routes, whose next hop must not be changed when 571 they're re-advertised by the segmenting ABRs for reasons specific to 572 MVPN. For EVPN, it is perfectly fine to change the next hop when 573 RBRs re-advertise the I/S-PMSI A-D routes, instead of relying on S- 574 NH-EC. As a result, this document specifies that RBRs change the BGP 575 next hop when they re-advertise I/S-PMSI A-D routes and do not use S- 576 NH-EC. if a downstream PE/RBR needs to originate Leaf A-D routes, it 577 simply uses the BGP next hop in the corresponding I/S-PMSI A-D routes 578 to construct Route Targets. 580 The advantage of this is that neither ingress nor egress PEs need to 581 understand/use S-NH-EC, and consistent procedure (based on BGP next 582 hop) is used for both inter-as and inter-region segmentation. 584 6.4. Ingress PE's I-PMSI Leaf Tracking 586 RFC 7524 specifies that when an ingress PE/ASBR (re-)advertises an 587 VPLS I-PMSI A-D route, it sets the LIR flag to 1 in the route's PTA. 588 Similar to the inter-as case, this is actually not really needed for 589 EVPN. To be consistent with the inter-as case, the ingress PE does 590 not set the LIR flag in its originated I-PMSI A-D routes, and 591 determines the leaves based on the BGP next hops in its received 592 I-PMSI A-D routes, as specified in Section 5.2. 594 The same backward compatibility issue exists, and the same solution 595 as in the inter-as case applies, as specified in Section 5.3. 597 7. Multi-homing Support 599 If multi-homing does not span across different ASes or regions, 600 existing procedures work with segmentation. If an ES is multi-homed 601 to PEs in different ASes or regions, additional procedures are needed 602 to work with segmentation. The procedures are well understood but 603 omitted here until the requirement becomes clear. 605 8. Security Considerations 607 This document does not seem to introduce new security risks, though 608 this may be revised after further review and scrutiny. 610 9. Acknowledgements 612 The authors thank Eric Rosen, John Drake, and Ron Bonica for their 613 comments and suggestions. 615 10. Contributors 617 The following also contributed to this document through their earlier 618 work in EVPN selective multicast. 620 Junlin Zhang 621 Huawei Technologies 622 Huawei Bld., No.156 Beiqing Rd. 623 Beijing 100095 624 China 626 Email: jackey.zhang@huawei.com 628 Zhenbin Li 629 Huawei Technologies 630 Huawei Bld., No.156 Beiqing Rd. 631 Beijing 100095 632 China 634 Email: lizhenbin@huawei.com 636 11. References 638 11.1. Normative References 640 [I-D.ietf-bess-ir] 641 Rosen, E., Subramanian, K., and J. Zhang, "Ingress 642 Replication Tunnels in Multicast VPN", draft-ietf-bess- 643 ir-00 (work in progress), January 2015. 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, 647 DOI 10.17487/RFC2119, March 1997, 648 . 650 [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and 651 C. Kodeboniya, "Multicast in Virtual Private LAN Service 652 (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, 653 . 655 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 656 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 657 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 658 2015, . 660 [RFC7524] Rekhter, Y., Rosen, E., Aggarwal, R., Morin, T., 661 Grosclaude, I., Leymann, N., and S. Saad, "Inter-Area 662 Point-to-Multipoint (P2MP) Segmented Label Switched Paths 663 (LSPs)", RFC 7524, DOI 10.17487/RFC7524, May 2015, 664 . 666 11.2. Informative References 668 [I-D.ietf-bess-dci-evpn-overlay] 669 Rabadan, J., Sathappan, S., Henderickx, W., Palislamovic, 670 S., Balus, F., Sajassi, A., and D. Cai, "Interconnect 671 Solution for EVPN Overlay networks", draft-ietf-bess-dci- 672 evpn-overlay-00 (work in progress), January 2015. 674 [I-D.ietf-bess-evpn-overlay] 675 Sajassi, A., Drake, J., Bitar, N., Isaac, A., Uttaro, J., 676 and W. Henderickx, "A Network Virtualization Overlay 677 Solution using EVPN", draft-ietf-bess-evpn-overlay-01 678 (work in progress), February 2015. 680 [I-D.rabadan-bess-evpn-optimized-ir] 681 Rabadan, J., Sathappan, S., Henderickx, W., Sajassi, A., 682 and A. Isaac, "Optimized Ingress Replication solution for 683 EVPN", draft-rabadan-bess-evpn-optimized-ir-00 (work in 684 progress), October 2014. 686 [I-D.wijnands-bier-architecture] 687 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 688 S. Aldrin, "Multicast using Bit Index Explicit 689 Replication", draft-wijnands-bier-architecture-05 (work in 690 progress), March 2015. 692 [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/ 693 BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 694 2012, . 696 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP 697 Encodings and Procedures for Multicast in MPLS/BGP IP 698 VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, 699 . 701 Authors' Addresses 703 Zhaohui Zhang 704 Juniper Networks 706 EMail: zzhang@juniper.net 708 Wen Lin 709 Juniper Networks 711 EMail: wlin@juniper.net 713 Jorge Rabadan 714 Nokia 716 EMail: jorge.rabadan@nokia.com 718 Keyur Patel 719 Cisco Systems 721 EMail: keyupate@cisco.com