idnits 2.17.1 draft-ietf-bess-evpn-virtual-hub-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 233: '... V-hub MUST announce unknown MAC rou...' RFC 2119 keyword, line 239: '... EVPN, a V-spoke MUST import all the u...' RFC 2119 keyword, line 242: '... the section 3 of the [RFC7024]. The unknown MAC route MUST be...' RFC 2119 keyword, line 247: '...nknown MAC route MUST use the route wh...' RFC 2119 keyword, line 271: '...ith non-zero ESI SHOULD consider the M...' (4 more instances...) 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: When VH1 relays traffic that it receives from VS1, in case of IR it MUST not send traffic back to VS1, and in case of P2MP tunnel it must indicate that traffic is sourced from VS1 so that VS1 will discard the traffic. In case of IR with IP unicsat tunnels, the outer source IP address identifies the sending PE. In case of IR with MPLS unicast tunnels, VH1 must advertise different labels to different PEs, so that it can identify the sending PE based on the label in the traffic from a V-spoke. -- The document date (September 28, 2019) is 1662 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: 'RFC2119' is mentioned on line 170, but not defined == Missing Reference: 'DCI-EVPN' is mentioned on line 219, but not defined == Missing Reference: 'RFC 6514' is mentioned on line 415, but not defined == Missing Reference: 'BUM-PROCEDURE' is mentioned on line 447, but not defined == Unused Reference: 'RFC7080' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'OVERLAY' is defined on line 651, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-01 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 BESS Working Group K. Patel 2 Arrcus 3 Internet Draft A. Sajassi 4 Category: Standards Track Cisco 5 J. Drake 6 Z. Zhang 7 Juniper Networks 8 W. Henderickx 9 Nokia 11 Expires: March 28, 2020 September 28, 2019 13 Virtual Hub-and-Spoke in BGP EVPNs 14 draft-ietf-bess-evpn-virtual-hub-00 16 Abstract 18 Ethernet Virtual Private Network (EVPN) solution is becoming 19 pervasive for Network Virtualization Overlay (NVO) services in data 20 center (DC) applications and as the next generation virtual private 21 LAN services in service provider (SP) applications. 23 The use of host IP default route and host unknown MAC route within a 24 DC is well understood in order to ensure that leaf nodes within a DC 25 only learn and store host MAC and IP addresses for that DC. All other 26 host MAC and IP addresses from remote DCs are learned and stored in 27 DC GW nodes thus alleviating leaf nodes from learning host MAC and IP 28 addresses from the remote DCs. 30 This draft further optimizes the MAC and IP address learning at the 31 leaf nodes such that a leaf node within a DC only needs to learn and 32 store MAC and IP addresses associated with the sites directly 33 connected to it. A leaf node does not need to learn and store MAC and 34 IP addresses from any other leaf nodes thus reducing the number of 35 learned MACs and IP addresses per EVI substantially. 37 The modifications provided by this draft updates and extends RFC7024 38 for BGP EVPN Address Family. 40 Status of this Memo 42 This Internet-Draft is submitted to IETF in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF), its areas, and its working groups. Note that 47 other groups may also distribute working documents as 48 Internet-Drafts. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/1id-abstracts.html 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html 61 Copyright and License Notice 63 Copyright (c) 2015 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 (http://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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 80 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 4. Routing Information Exchange for EVPN routes . . . . . . . . . 5 82 5. EVPN unknown MAC route . . . . . . . . . . . . . . . . . . . . 6 83 5.1. Originating EVPN Unknown MAC Route by a V-Hub . . . . . . 6 84 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE . . . . 6 85 5.3. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . 7 86 5.4. Split-Horizon & Mass Withdraw . . . . . . . . . . . . . . 8 87 6. Forwarding Considerations . . . . . . . . . . . . . . . . . . 8 88 6.1. IP-only Forwarding . . . . . . . . . . . . . . . . . . . . 8 89 6.2. MAC-only Forwarding - Bridging . . . . . . . . . . . . . . 8 90 6.3. MAC and IP Forwarding - IRB . . . . . . . . . . . . . . . 8 91 7. Handling of Broadcast and Multicast traffic . . . . . . . . . 9 92 7.1. Split Horizon . . . . . . . . . . . . . . . . . . . . . . 10 93 7.2. Route Advertisement . . . . . . . . . . . . . . . . . . . 10 94 7.3. Designated Forwarder in a Cluster . . . . . . . . . . . . 11 95 7.4. Traffic Forwarding Rules . . . . . . . . . . . . . . . . . 11 96 7.4.1. Traffic from Local ACs . . . . . . . . . . . . . . . . 12 97 7.4.2. Traffic Received by a V-hub from Another PE . . . . . 12 98 7.4.3. Traffic received by a V-spoke from a V-hub . . . . . . 12 99 7.5. Multi-homing support . . . . . . . . . . . . . . . . . . . 12 100 7.5.1 Domain-wide Common Block (DCB) Label . . . . . . . . . . 13 101 7.5.2 Local Bias . . . . . . . . . . . . . . . . . . . . . . . 13 102 7.6. Direct V-spoke to V-spoke traffic . . . . . . . . . . . . 13 103 8. ARP/ND Suppression . . . . . . . . . . . . . . . . . . . . . . 13 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 105 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 106 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 107 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 15 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 109 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 110 13.2. Informative References . . . . . . . . . . . . . . . . . 15 111 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15 113 1. Introduction 115 Ethernet Virtual Private Network (EVPN) solution is becoming 116 pervasive for Network Virtualization Overlay (NVO) services in data 117 center (DC) applications and as the next generation virtual private 118 LAN services in service provider (SP) applications. 120 With EVPN, providing any-to-any connectivity among sites of a given 121 EVPN Instance (EVI) would require each Provider Edge (PE) router 122 connected to one or more of these sites to hold all the host MAC and 123 IP addresses for that EVI. The use of host IP default route and host 124 unknown MAC route within a DC is well understood in order to 125 alleviate the learning of host MAC and IP addresses to only leaf 126 nodes (PEs) within that DC. All other host MAC and IP addresses from 127 remote DCs are learned and stored in DC GW nodes thus alleviating 128 leaf nodes from learning host MAC and IP addresses from the remote 129 DCs. 131 This draft further optimizes the MAC and IP address learning at the 132 leaf nodes such that a leaf node within a DC only needs to learn and 133 store MAC and IP addresses associated with the sites directly 134 connected to it. A leaf node does not need to learn and store MAC 135 and IP addresses from any other leaf nodes thus reducing the number 136 of learned MACs and IP addresses per EVI substantially. 138 [RFC7024] provides rules for Hub and Spoke VPNs for BGP L3VPNs. This 139 draft updates and extends [RFC7024] for BGP EVPN Address Family. This 140 draft provides rules for Originating and Processing of the EVPN host 141 unknown MAC route and host default IP route by EVPN Virtual Hub (V- 142 HUB). This draft also provides rules for the handling of the BUM 143 traffic in Hub and Spoke EVPNs and handling of ARP suppression. 145 The leaf nodes and DC GW nodes in a data center are referred to as 146 Virtual Spokes (V-spokes) and Virtual Hubs (V-hubs) respectively. A 147 set of V-spoke can be associated with one or more V-hubs. If a V- 148 spokes is associated with more than one V-hubs, then it can load 149 balanced traffic among these V-hubs. Different V-spokes can be 150 associated with different sets of V-hubs such that at one extreme 151 each V-spoke can have a different V-hub set although this may not be 152 desirable and a more typical scenario may be to associate a set of V- 153 spokes to a set of V-hubs - e.g., topology for a DC POD where a set 154 of V-spokes are associated with a set of spine nodes or DC GW nodes. 156 In order to avoid repeating many of the materials covered in 157 [RFC7024], this draft is written as a delta document with its 158 sections organized to follow those of that RFC with only delta 159 description pertinent to EVPN operation in each section. Therefore, 160 it is assumed that the readers are very familiar with [RFC7024] and 161 EVPN. 163 2. Requirements Language 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 167 be interpreted as described in [RFC2119] only when they appear in all 168 upper case. They may also appear in lower or mixed case as English 169 words, without any normative meaning. 171 3. Terminology 173 ARP: Address Resolution Protocol 174 BEB: Backbone Edge Bridge 175 B-MAC: Backbone MAC Address 176 CE: Customer Edge 177 C-MAC: Customer/Client MAC Address 178 ES: Ethernet Segment 179 ESI: Ethernet Segment Identifier 180 IRB: Integrated Routing and Bridging 181 LSP: Label Switched Path 182 MP2MP: Multipoint to Multipoint 183 MP2P: Multipoint to Point 184 ND: Neighbor Discovery 185 NA: Neighbor Advertisement 186 P2MP: Point to Multipoint 187 P2P: Point to Point 188 PE: Provider Edge 189 EVPN: Ethernet VPN 190 EVI: EVPN Instance 191 RT: Route Target 193 Single-Active Redundancy Mode: When only a single PE, among a group 194 of PEs attached to an Ethernet segment, is allowed to forward traffic 195 to/from that Ethernet Segment, then the Ethernet segment is defined 196 to be operating in Single-Active redundancy mode. 198 All-Active Redundancy Mode: When all PEs attached to an Ethernet 199 segment are allowed to forward traffic to/from that Ethernet Segment, 200 then the Ethernet segment is defined to be operating in All-Active 201 redundancy mode. 203 4. Routing Information Exchange for EVPN routes 205 [RFC7432] defines multiple Route Types NLRI along with procedures for 206 advertisements and processing of these routes. Some of these 207 procedures are impacted as the result of hub-and-spoke architecture. 208 The routing information exchange among the hub, spoke, and vanilla 209 PEs are subject to the same rules as described in section 3 of 210 [RFC7024]. Furthermore, if there are any changes to the EVPN route 211 advisements and processing from that of [RFC7432], they are described 212 below. 214 5. EVPN unknown MAC route 216 Section 3 of [RFC7024] talks about how a V-hub of a given VPN must 217 export a VPN-IP default route for that VPN and this route must be 218 exported to only the V-spokes of that VPN associated with that V-hub. 219 [DCI-EVPN] defines the notion of the unknown MAC route for an EVI 220 which is analogous to a VPN-IP default route for a VPN. This unknown 221 MAC route is exported by a V-hub to its associated V-spokes. If 222 multiple V-hubs are associated with a set of V-spokes, then each V- 223 hub advertises it with a distinct RD when originating this route. If 224 a V-spoke imports several of these unknown MAC routes and they all 225 have the same preference, then traffic from the V-spoke to other 226 sites of that EVI would be load balanced among the V-hubs. 228 5.1. Originating EVPN Unknown MAC Route by a V-Hub 230 Section 7.3 of the [RFC7024] defines procedures for originating a 231 VPN-IP default route for a VPN. The same procuedures apply when a V- 232 hub wants to originate EVPN unknown MAC route for a given EVI. The 233 V-hub MUST announce unknown MAC route using the MAC/IP advertisement 234 route along with the Default Gateway extended community as defined in 235 section 10.1 of the [RFC7432]. 237 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE 239 Within a given EVPN, a V-spoke MUST import all the unknown MAC routes 240 unless the route-target mismatch happens. The processing of the 241 received VPN-MAC EVPN default route follows the rules explained in 242 the section 3 of the [RFC7024]. The unknown MAC route MUST be 243 installed according to the rules of MAC/IP Advertisement route 244 installation rules in section 9.2.2 of [RFC7024]. 246 In absense of any more specific VPN-MAC EVPN routes, V-spokes 247 installing the unknown MAC route MUST use the route when performing 248 ARP proxy. This behavior would allow V-Spokes to forward the traffic 249 towards V-Hub. 251 5.3. Aliasing 253 [RFC7432] describes the concept and procedures for Aliasing where a 254 station is multi-homed to multiple PEs operating in an All-Active 255 redundancy mode, it is possible that only a single PE learns a set of 256 MAC addresses associated with traffic transmitted by the station. 257 [RFC7432] describes the concepts and procedures for Aliasing, which 258 occurs when a CE is multi-homed to multiple PE nodes, operating in 259 all-active redundancy mode, but not all of the PEs learn the CE's set 260 of MAC addresses. This leads to a situation where remote PEs receive 261 MAC advertisement routes, for these addresses, from a single NVE even 262 though multiple NVEs are connected to the multi-homed station. As a 263 result, the remote NVEs are not able to effectively load-balance 264 traffic among the NVEs connected to the multi-homed Ethernet segment. 266 To alleviate this issue, EVPN introduces the concept of Aliasing. 267 This refers to the ability of a PE to signal that it has reachability 268 to a given locally attached Ethernet segment, even when it has learnt 269 no MAC addresses from that segment. The Ethernet A-D per-EVI route is 270 used to that end. Remote PEs which receive MAC advertisement routes 271 with non-zero ESI SHOULD consider the MAC address as reachable via 272 all NVEs that advertise reachability to the relevant Segment using 273 Ethernet A-D routes with the same ESI and with the Single-Active flag 274 reset. 276 This procedure is impacted for virtual hub-and-spoke topology because 277 a given V-spoke does not receive any MAC/IP advertisements from 278 remote V-spokes; therefore, there is no point in propagating Ethernet 279 A-D per-EVI route to the remote V-spokes. In this solution, the V- 280 hubs terminate the Ethernet A-D per-EVI route (used for Aliasing) and 281 follows the procedures described in [RFC7432] for handling this 282 route. 284 There are scenarios for which it is desirable to establish direct 285 communication path between a pair of V-spokes for a given host MAC 286 address. In such scenario, the advertising V-spoke advertises both 287 the MAC/IP route and Ethernet A-D per-EVI route with the RT of V-hub 288 (RT-VH) per section 3 of [RFC7024]. The use of RT-VH, ensures that 289 these routes are received by the V-spokes associated with that V-hub 290 set and thus enables the V-spokes to perform the Aliasing procedure. 292 In summary, PE devices (V-hubs in general and V-spokes occasionally) 293 that receive EVPN MAC/IP route advertisements (associated with a 294 multi-homed site) need to also receive the associated Ethernet A-D 295 per-EVI route advertisement(s) in order for them to perform Aliasing 296 procedure. 298 5.4. Split-Horizon & Mass Withdraw 300 [RFC7432] uses Ethernet A-D per-ES route to a) signal to remote PEs 301 the multi-homing redundancy type (Single-Active versus All-Active), 302 b) advertise ESI label for split-horizon filtering when MPLS 303 encapsulation is used, and c) advertise mass-withdraw when a failure 304 of an access interface impacts many MAC addresses. This route does 305 not need to be advertise from a V-spoke to any remote V-spoke unless 306 a direct communication path between a pair of spoke is needed for a 307 given flow. 309 Even if communication between a pair of V-spoke is needed for just a 310 single flow, the Ethernet A-D per ES route needs to be advertised 311 from the originating V-spoke for that ES which may handle tens or 312 hundreds of thousands of flows. This is because in order to perform 313 Aliasing function for a given flow, the Ethernet A-D per-EVI route is 314 needed and this route itself is dependent on the Ethernet A-D per-ES 315 route. In such scenario, the advertising V-spoke advertises the 316 Ethernet A-D per-ES route with the RT of V-hub (RT-VH) per section 3 317 of [RFC7024]. 319 In summary, PE devices (V-hubs in general and V-spokes occasionally) 320 that receive EVPN MAC/IP route advertisements (associated with a 321 multi-homed site) need to also receive the associated Ethernet A-D 322 per-ES route advertisement(s). 324 6. Forwarding Considerations 326 6.1. IP-only Forwarding 328 When EVPN operates in IP-only forwarding mode using EVPN Route Type 329 5, then all forwarding considerations in section 4 of [RFC7024] are 330 directly applicable here. 332 6.2. MAC-only Forwarding - Bridging 334 When EVPN operates in MAC-only forwarding mode (i.e., bridging mode), 335 then for a given EVI, the MPLS label that a V-hub advertises with 336 anUnknown MAC address MUST be the label that identifies the MAC-VRF 337 of the V-hub in absense of a more specific MAC route. When the V-hub 338 receives a packet with such label, the V- hub pops the label and 339 determines further disposition of the packet based on the lookup in 340 the MAC-VRF. Otherwise, the MPLS label of the matching more specific 341 route is used and packet is is forwarded towards the associated 342 NEXTHOP of the more specific route. 344 6.3. MAC and IP Forwarding - IRB 345 When a EVPN speaker operates in IRB mode, it implements both the IP 346 and MAC forwarding Modes (aka Integrated Routing and Bridging - IRB). 347 On a packet by packet basis, the V-spoke decides whether to do 348 forwarding based on a MAC address lookup (bridge) or based on a IP 349 address lookup (route). If the host destination MAC address is that 350 of the IRB interface (i.e., if the traffic is inter-subnet), then the 351 V-spoke performs an additional IP lookup in the IP-VRF. However, if 352 the host destination MAC address is that of an actual host MAC 353 address (i.e., the traffic is intra- subnet) , then the V-spoke only 354 performs a MAC lookup in the MAC-VRF. The procedure specified in 355 Section 6.1 and Section 6.2 are applicable to inter-subnet and intra- 356 subnet forwarding respectively. For intra- subnet traffic, if the 357 MAC address is not found in the MAC-VRF, then the V-spoke forwards 358 the traffic to the V-hub with the MPLS label received from the V-hub 359 for the unknown MAC address. For the Inter- subnet traffic, if the 360 IP prefix is not found in the IP-VRF, then the V-spoke forwards the 361 traffic to the V-hub with the MPLS label received from the V-hub for 362 the default IP address. 364 7. Handling of Broadcast and Multicast traffic 366 Just like that V-spoke to V-spoke known unicast traffic is relayed by 367 V-hubs, V-spoke to V-spoke BUM traffic can also relayed by V-hubs. 368 This is especially desired if Ingress Replication (IR) would be used 369 otherwise for V-spokes to send traffic to other V-spokes. This way, 370 a V-spoke can unicast BUM traffic to a single V-hub, who will then 371 relay the traffic. This achieves Assisted Replication, and reduces 372 multicast state in the core. Note that a V-hub may relay traffic 373 using MPLS P2MP tunnels or BIER as well as IR. While a V-spoke may 374 use P2MP tunnels or BIER to send traffic to V-hubs, this 375 specification focuses on using IR by V-spokes. 377 In this particular section, all traffic refers to BUM traffic unless 378 explicitly stated otherwise. The term PE refers to a V-hub or V- 379 spoke when there is no need to distinguish the two. 381 Consider the following topology, where V-spokes VS1/2/3 are 382 associated with V-hubs VH1/2 in one cluster, and V-spokes VS4/5/6 are 383 associated with V-hubs VH3/4 in another cluster. Note that the 384 lines/dots in the diagram indcate association, not connection. 386 VH1 ...VH2 VH3 ...VH4 387 / |. . . / |. . . 388 / .| . . / .| . . 389 /. |. . /. |. . 390 VS1 VS2 VS3 VS4 VS5 VS6 392 7.1. Split Horizon 394 When VH1 relays traffic that it receives from VS1, in case of IR it 395 MUST not send traffic back to VS1, and in case of P2MP tunnel it must 396 indicate that traffic is sourced from VS1 so that VS1 will discard 397 the traffic. In case of IR with IP unicsat tunnels, the outer source 398 IP address identifies the sending PE. In case of IR with MPLS 399 unicast tunnels, VH1 must advertise different labels to different 400 PEs, so that it can identify the sending PE based on the label in the 401 traffic from a V-spoke. 403 If MPLS P2MP/multicast tunnels (including VXLAN-GPE and MPLS-over- 404 GRE/UDP) are used by a V-hub to relay traffic, an upstream allocated 405 (by the V-hub) label MUST be imposed in the label stack to identify 406 the source of the V-spoke. The label is advertised as part of the PE 407 Distinguisher (PED) Label Attribute of the Inclusive Multicast 408 Ethernet Tag (IMET) route from the V-hub, as specified in Section 8 409 of [RFC 6514]. 411 Notice that an "upstream-assigned" label used by a V-hub to send 412 traffic with on a P2MP tunnel to identify the source V-spoke is the 413 same "downstream-assigned" label used by the V-hub to receive traffic 414 on the IR tunnel from the V-spoke. Therefore, the same PED Label 415 attribute serves two purposes. With [RFC 6514], a PED label may only 416 identify a PE but not a particular VPN. Here the PED label 417 identifies both the PE and a particular EVI/BD. A V-spoke programs 418 its context MPLS forwarding table for the V-hub to discard any 419 traffic with the PED label that the V-hub advertised for this V- 420 spoke, or pop other PED labels and direct traffic into a 421 corresponding EVI for L2 forwarding. 423 Note that a V-hub cannot use VXLAN/NVGRE multicast tunnels to relay 424 traffic because if the V-hub uses the source V-spoke's IP address in 425 the outer IP header (for the purpose of identifying the source V- 426 spoke), multicast RPF would fail and the packets will be discarded. 428 7.2. Route Advertisement 429 As with other route types, IMET routes from V-hubs are advertised 430 with RT-VH and RT-EVI so they are imported by associated V-spokes and 431 all V-hubs. They carry the PED Label attribute as described above. 433 IMET routes from V-spokes are advertised with RT-EVI so they are 434 imported by all V-hubs. They also carry PED Label attribute for 435 multi-homing split horizon purpose if and only if V-hubs uses IR to 436 relay traffic. 438 If a V-hub uses RSVP-TE P2MP tunnel, IR, or BIER to send or relay 439 traffic, all other PEs (V-hubs or V-spokes) will receive traffic 440 directly because the V-hub sees all PEs. If a V-hub uses mLDP P2MP 441 tunnel to send or relay traffic, only its associated V-spokes and all 442 V-hubs will see the V-hub's IMET route and join the tunnel announced 443 in the route. Another V-hub need to relay traffic to its associated 444 V-spokes that are not associated with this V-hub. 446 For that V-hub to announce the mLDP relay tunnel in its cluster, it 447 needs to advertise a (*,*) S-PMSI AD route, as specified in [BUM- 448 PROCEDURE]. The route is advertised with the RT-VH for that cluster, 449 and associated V-spokes will join the tunnel announced in the S-SPMI 450 AD route. 452 7.3. Designated Forwarder in a Cluster 454 When there are multiple V-hubs in a cluster, a V-spoke in that 455 cluster decides by itself to which V-hub to send traffic. If the 456 receiving V-hub uses mLDP tunnel to relay traffic, V-hubs in other 457 clusters need to further relay traffic, but only one V-hub in each 458 cluster can do so. As a result, a DF must be elected among the V- 459 hubs for each cluster. 461 The election is similar to DF election in RFC 7432, with the 462 folllowing differences. 464 o Instead of using Ethernet Segment route to discover the PEs on a 465 multi-homing ES, the IMET route are used to determine the V-hubs in 466 the same cluster - they all carry the same pair of RT-EVI and RT-VH, 467 and advertises the unknown mac route. 469 o Instead of using VLAN to do per-VLAN DF election, the Local 470 Administration Field of the RT-EVI is used to do per-EVI DF election. 472 7.4. Traffic Forwarding Rules 474 When a PE needs to forward received traffic from local Attachment 475 Circuits (ACs) or remote PEs to local ACs, it follows the rules in 476 RFC 7432, except that traffic sourced from this local PE but relayed 477 back on a p2mp tunnel is discarded. It may also need to forward to 478 other PEs, subject to rules in the following sections. 480 7.4.1. Traffic from Local ACs 482 Traffic from a V-hub's local ACs is forwarded using the tunnel 483 announced in its IMET route, as specified in RFC 7432. In case of an 484 mLDP tunnel, the traffic need to be relayed by V-hubs of other 485 clusters to their associated V-spokes. For other tunnel types, no 486 relay is needed. 488 Traffic from a V-spoke's local ACs is forwarded to an associated V- 489 hub of its choice. In case of MPLS IR, the label in the V-hub's IMET 490 route's PED attribute corresponding to this V-spoke is used. 492 7.4.2. Traffic Received by a V-hub from Another PE 494 When a V-hub receives traffic from an associated V-spoke, it needs to 495 relay to other PEs, using the tunnel announced in its IMET route. In 496 case of IR or BIER, the source V-spoke, which is determined from the 497 incoming label or source IP address, is excluded from the replication 498 list. In case of a P2MP tunnel, the popped incoming label is imposed 499 again to identify the source PE, before the tunnel label is imposed. 501 When a V-hub receives traffic from another V-hub on a P2MP tunnel, 502 and the tunnel is announced in an IMET route carrying the same RT-VH 503 as this V-hub is configured with, it does not need to relay the 504 traffic. Otherwise, the traffic is from a V-hub in a different 505 cluster, and this V-hub needs to relay to its associated V-spokes, if 506 and only if it is the DF for this cluster, using the tunnel announced 507 in its (*,*) S-PMSI route carrying its RT-VH. 509 When a V-hub recevies traffic from another V-hub via IR or BIER, it 510 does not further relay the traffic as that V-hub can reach all PEs. 512 7.4.3. Traffic received by a V-spoke from a V-hub 514 In case of P2MP tunnel, the V-spoke discards the traffic if the label 515 following the tunnel label identifies the V-spoke itself. 517 7.5. Multi-homing support 519 Consider that an ES spans across two V-spokes in the same cluster and 520 the V-hub uses MPLS IR to relay traffic. With ESI Label split 521 horizon method, a source V-spoke uses the ESI label advertised by the 522 V-hub for the ES, and the V-hub must change that to the ESI label 523 advertised by receiving v-spokes when it relays traffic. That means 524 V-hubs must advertise ESI labels for all multi-homing segments, even 525 when they're not on those segments. They must also do double label 526 swap (EVI/BD label and ESI label) or mac lookup when relaying 527 traffic. 529 There are two methods detailed below to avoid that complexity. Either 530 one MAY be used. 532 7.5.1 Domain-wide Common Block (DCB) Label 534 [draft-zzhang-bess-mvpn-evpn-aggregation-label] proposes for all PEs 535 on an MHES to use the same ESI label allocated from a Domain-wide 536 Common Block. Not only does that have the advantages described in 537 that document, but also It avoids the MHES complexity with Virtual 538 Hub and Spoke as mentioned above, because the V-Hubs do not need to 539 care about the ESI label at all any more. 541 7.5.2 Local Bias 543 If DCB labels cannot be used, then Local Bias can be used even For 544 EVPN MPLS. The PED label following the mpls transport tunnel label or 545 BIER header identifies the PE that originated the traffic in addition 546 to identifying the EVI/BD. 548 If a V-hub uses P2MP or BIER to relay traffic, the PED label is one 549 of the labels in the PE Distinguiser Label attribute in the V-hub's 550 IMET route, allocated by the V-hub for the source V-spoke. 552 If a V-hub uses IR to relay traffic, for each V-spoke that it relays 553 to, the PED label advertised by that receiving V-spoke for the source 554 V-spoke needs to be imposed by the V-hub. For that purpose, each V- 555 spoke must include the PED Label attribute in its IMET route, to 556 advertise different labels for different PEs. It discovers the PEs 557 that it needs to advertise labels for via the PED label Attribute in 558 the V-hub's IMET route. 560 7.6. Direct V-spoke to V-spoke traffic 562 It may be desired for allow direct V-spoke to V-spoke traffic in a 563 cluster, without the relay by a V-hub. To do that, V-spokes advertise 564 their IMET routes with both RT-VH and RT-EVI. Forwarding rules will 565 be specified in future revisions. 567 8. ARP/ND Suppression 569 [RFC7432] defines the procedures for ARP/ND suppression where a PE 570 can terminate gratuitous ARP/ND request message from directly 571 connected site and advertises the associated MAC and IP addresses in 572 an EVPN MAC/IP advertisement route to all other remote PEs. The 573 remote PEs that receive this EVPN route advertisement, install the 574 MAC/IP pair in their ARP/ND cache table thus enabling them to 575 terminate ARP/ND requests and generate ARP/ND responses locally thus 576 suppressing the flooding of ARP/ND requests over the EVPN network. 578 In this hub-and-spoke approach, the ARP suppression needs to be 579 performed by both the EVPN V-hubs as well V-spokes as follow. When a 580 V-Spoke receives a gratuitous ARP/ND request, it terminates it and 581 stores the source MAC/IP pair in its ARP/ND cache table. Then, it 582 advertises the source MAC/IP pair to its associated V-Hubs using EVPN 583 MAC/IP advertisement route. The V-Hubs upon receiving this EVPN 584 route advertisement, create an entry in their ARP/ND cache table for 585 this MAC/IP pair. 587 Now when a V-Spoke receives an ARP/ND request, it first looks up its 588 ARP cache table, if an entry for that MAC/IP pair is found, then an 589 ARP/ND response is generated locally and sent to the CE. However, if 590 an entry is not found, then the ARP/ND request is unicasted to one of 591 the V-hub associated with this V-spoke. Since, the associated V-hub 592 keeps all the MAC/IP ARP entries in its cache table, it can formulate 593 and ARP/ND response and forward it to that CE via the corresponding 594 V-spoke. 596 9. IANA Considerations 598 There is no additional IANA considerations for PBB-EVPN beyond what 599 is already described in [RFC7432]. 601 10. Security Considerations 603 All the security considerations in [RFC7432] apply directly to this 604 document because this document leverages [RFC7432] control plane and 605 their associated procedures - although not the complete set but 606 rather a subset. 608 This draft does not introduce any new security considerations beyond 609 that of [RFC7432] and [RFC4761] because advertisements and processing 610 of B-MAC addresses follow that of [RFC7432], and processing of C-MAC 611 addresses follow that of [RFC4761] - i.e, B-MAC addresses are learned 612 in control plane and C-MAC addresses are learned in data plane. 614 11. Acknowledgements 616 The authors would like to thank Yakov Rekhter for initial idea 617 discussions. 619 12. Change Log 621 Initial Version: Sep 21 2014 Original Name: draft-keyupate-evpn- 622 virtual-hub-00.txt 624 13. References 626 13.1. Normative References 628 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 629 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 630 VPNs", RFC 7024, October 2013. 632 [RFC7432] A. Sajassi, et al., "BGP MPLS Based Ethernet VPN", RFC 633 7432 , February 2015. 635 13.2. Informative References 637 [RFC7080] A. Sajassi, et al., "Virtual Private LAN Service (VPLS) 638 Interoperability with Provider Backbone Bridges", RFC 639 7080, December 2013. 641 [RFC7209] D. Thaler, et al., "Requirements for Ethernet VPN (EVPN)", 642 RFC 7209, May 2014. 644 [RFC4389] A. Sajassi, et al., "Neighbor Discovery Proxies (ND 645 Proxy)", RFC 4389, April 2006. 647 [RFC4761] K. Kompella, et al., "Virtual Private LAN Service (VPLS) 648 Using BGP for Auto-Discovery and Signaling", RFC 4761, 649 Jauary 2007. 651 [OVERLAY] A. Sajassi, et al., "A Network Virtualization Overlay 652 Solution using EVPN", draft-ietf-bess-evpn-overlay-01, 653 work in progress, February 2015. 655 14. Authors' Addresses 657 Keyur Patel 658 Arrcus, Inc. 659 2077 Gateway Pl, Suite 400 660 San Jose, CA 95110, US 661 Email: keyur@arrcus.com 663 Ali Sajassi 664 Cisco 665 170 West Tasman Drive 666 San Jose, CA 95134, US 667 Email: sajassi@cisco.com 669 Yakov Rekhter 670 Juniper Networks, Inc. 671 Email: yakov@juniper.net 673 John E. Drake 674 Juniper Networks, Inc. 675 Email: jdrake@juniper.net 677 Zhaohui Zhang 678 Juniper Networks, Inc. 679 Email: zzhang@juniper.net 681 Wim Henderickx 682 Nokia 683 Email: wim.henderickx@nokia.com