idnits 2.17.1 draft-keyupate-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack 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? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (March 12, 2017) is 2601 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: 'I-D.EVPN-overlay' is mentioned on line 213, but not defined == Missing Reference: 'RFC 6514' is mentioned on line 410, but not defined == Unused Reference: 'I-D.zzhang-bess-evpn-bum-procedure-updates' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC1771' is defined on line 617, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 626, but no explicit reference was found in the text == Unused Reference: 'RFC3484' is defined on line 631, but no explicit reference was found in the text == Unused Reference: 'RFC3931' is defined on line 636, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 641, but no explicit reference was found in the text == Unused Reference: 'RFC4271' is defined on line 646, but no explicit reference was found in the text == Unused Reference: 'RFC4374' is defined on line 651, but no explicit reference was found in the text == Unused Reference: 'RFC6459' is defined on line 655, but no explicit reference was found in the text == Unused Reference: 'I-D.drao-bgp-l3vpn-virtual-network-overlays' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-bess-evpn-overlay' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'RFC4389' is defined on line 685, but no explicit reference was found in the text == Unused Reference: 'RFC7080' is defined on line 694, but no explicit reference was found in the text == Unused Reference: 'RFC7209' is defined on line 699, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-zzhang-bess-evpn-bum-procedure-updates-01 ** Obsolete normative reference: RFC 1771 (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 3484 (Obsoleted by RFC 6724) ** Downref: Normative reference to an Informational RFC: RFC 4374 ** Downref: Normative reference to an Informational RFC: RFC 6459 == Outdated reference: A later version (-12) exists of draft-ietf-bess-evpn-overlay-01 Summary: 4 errors (**), 0 flaws (~~), 21 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2VPNs K. Patel 3 Internet-Draft Arrcus 4 Intended status: Standards Track A. Sajassi 5 Expires: September 12, 2017 Cisco Systems 6 J. Drake 7 Z. Zhang 8 Juniper Networks, Inc. 9 W. Henderickx 10 Nokia 11 March 12, 2017 13 Virtual Hub-and-Spoke in BGP EVPNs 14 draft-keyupate-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 26 other host MAC and IP addresses from remote DCs are learned and 27 stored in DC GW nodes thus alleviating leaf nodes from learning host 28 MAC and IP 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 34 and IP addresses from any other leaf nodes thus reducing the number 35 of 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 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). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 8, 2017. 57 Copyright Notice 59 Copyright (c) 2017 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 76 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Routing Information Exchange for EVPN routes . . . . . . . . 5 78 5. EVPN unknown MAC Route . . . . . . . . . . . . . . . . . . . 5 79 5.1. Originating EVPN Unknown MAC Route by a V-Hub . . . . . . 5 80 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE . . . 5 81 5.3. Aliasing . . . . . . . . . . . . . . . . . . . . . . . . 6 82 5.4. Split-Horizon And Mass Withdraw . . . . . . . . . . . . . 7 83 6. Forwarding Considerations . . . . . . . . . . . . . . . . . . 7 84 6.1. IP-only Forwarding . . . . . . . . . . . . . . . . . . . 7 85 6.2. MAC-only Forwarding - Bridging . . . . . . . . . . . . . 7 86 6.3. MAC and IP Forwarding - IRB . . . . . . . . . . . . . . . 8 87 7. Handling of the Broadcast and Multicast traffic . . . . . . . 8 88 7.1. Split Horizon . . . . . . . . . . . . . . . . . . . . . . 9 89 7.2. Route Advertisement . . . . . . . . . . . . . . . . . . . 9 90 7.3. Designated Forwarder in a Cluster . . . . . . . . . . . . 10 91 7.4. Traffic Forwarding Rules . . . . . . . . . . . . . . . . 10 92 7.4.1. Traffic from Local ACs . . . . . . . . . . . . . . . 10 93 7.4.2. Traffic Received by a V-hub from Another PE . . . . . 11 94 7.4.3. Traffic received by a V-spoke from a V-hub . . . . . 11 95 7.5. Multi-homing support . . . . . . . . . . . . . . . . . . 11 96 7.6. Direct V-spoke to V-spoke traffic . . . . . . . . . . . . 12 97 8. ARP/ND Suppression . . . . . . . . . . . . . . . . . . . . . 12 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 99 10. Security Considerations . . . . . . . . . . . . . . . . . . . 13 100 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 101 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 13 102 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 104 13.2. Informative References . . . . . . . . . . . . . . . . . 15 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 107 1. Introduction 109 Ethernet Virtual Private Network (EVPN) solution is becoming 110 pervasive for Network Virtualization Overlay (NVO) services in data 111 center (DC) applications and as the next generation virtual private 112 LAN services in service provider (SP) applications. 114 With EVPN, providing any-to-any connectivity among sites of a given 115 EVPN Instance (EVI) would require each Provider Edge (PE) router 116 connected to one or more of these sites to hold all the host MAC and 117 IP addresses for that EVI. The use of host IP default route and host 118 unknown MAC route within a DC is well understood in order to 119 alleviate the learning of host MAC and IP addresses to only leaf 120 nodes (PEs) within that DC. All other host MAC and IP addresses from 121 remote DCs are learned and stored in DC GW nodes thus alleviating 122 leaf nodes from learning host MAC and IP addresses from the remote 123 DCs. 125 This draft further optimizes the MAC and IP address learning at the 126 leaf nodes such that a leaf node within a DC only needs to learn and 127 store MAC and IP addresses associated with the sites directly 128 connected to it. A leaf node does not need to learn and store MAC 129 and IP addresses from any other leaf nodes thus reducing the number 130 of learned MACs and IP addresses per EVI substantially. 132 [RFC7024] provides rules for Hub and Spoke VPNs for BGP L3VPNs. This 133 draft updates and extends [RFC7024] for BGP EVPN Address Family. 134 This draft provides rules for Originating and Processing of the EVPN 135 host unknown MAC route and host default IP route by EVPN Virtual Hub 136 (V-HUB). This draft also provides rules for the handling of the BUM 137 traffic in Hub and Spoke EVPNs and handling of ARP suppression. 139 The leaf nodes and DC GW nodes in a data center are referred to as 140 Virtual Spokes (V-spokes) and Virtual Hubs (V-hubs) respectively. A 141 set of V-spoke can be associated with one or more V-hubs. If a V- 142 spokes is associated with more than one V-hubs, then it can load 143 balanced traffic among these V-hubs. Different V-spokes can be 144 associated with different sets of V-hubs such that at one extreme 145 each V-spoke can have a different V-hub set although this may not be 146 desirable and a more typical scenario may be to associate a set of V- 147 spokes to a set of V-hubs - e.g., topology for a DC POD where a set 148 of V-spokes are associated with a set of spine nodes or DC GW nodes. 150 In order to avoid repeating many of the materials covered in 151 [RFC7024], this draft is written as a delta document with its 152 sections organized to follow those of that RFC with only delta 153 description pertinent to EVPN operation in each section. Therefore, 154 it is assumed that the readers are very familiar with [RFC7024] and 155 EVPN. 157 2. Requirements Language 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to 161 be interpreted as described in [RFC2119] only when they appear in all 162 upper case. They may also appear in lower or mixed case as English 163 words, without any normative meaning. 165 3. Terminology 167 ARP: Address Resolution Protocol 168 BEB: Backbone Edge Bridge 169 B-MAC: Backbone MAC Address 170 CE: Customer Edge 171 C-MAC: Customer/Client MAC Address 172 ES: Ethernet Segment 173 ESI: Ethernet Segment Identifier 174 IRB: Integrated Routing and Bridging 175 LSP: Label Switched Path 176 MP2MP: Multipoint to Multipoint 177 MP2P: Multipoint to Point 178 ND: Neighbor Discovery 179 NA: Neighbor Advertisement 180 P2MP: Point to Multipoint 181 P2P: Point to Point 182 PE: Provider Edge 183 EVPN: Ethernet VPN 184 EVI: EVPN Instance 185 RT: Route Target 187 Single-Active Redundancy Mode: When only a single PE, among a group 188 of PEs attached to an Ethernet segment, is allowed to forward traffic 189 to/from that Ethernet Segment, then the Ethernet segment is defined 190 to be operating in Single-Active redundancy mode. 192 All-Active Redundancy Mode: When all PEs attached to an Ethernet 193 segment are allowed to forward traffic to/from that Ethernet Segment, 194 then the Ethernet segment is defined to be operating in All-Active 195 redundancy mode. 197 4. Routing Information Exchange for EVPN routes 199 [RFC7024] defines multiple Route Types NLRI along with procedures for 200 advertisements and processing of these routes. Some of these 201 procedures are impacted as the result of hub-and-spoke architecture. 202 The routing information exchange among the hub, spoke, and vanilla 203 PEs are subject to the same rules as described in section 3 of 204 [RFC7024]. Furthermore, if there are any changes to the EVPN route 205 advisements and processing from advertisements and processing from 206 [RFC7024], they are described below. 208 5. EVPN unknown MAC Route 210 Section 3 of [RFC7024] talks about how a V-hub of a given VPN must 211 export a VPN-IP default route for that VPN and this route must be 212 exported to only the V-spokes of that VPN associated with that V-hub. 213 [I-D.EVPN-overlay] defines the notion of the unknown MAC route for an 214 EVI which is analogous to a VPN-IP default route for a VPN. This 215 unknown MAC route is exported by a V-hub to its associated V-spokes. 216 If multiple V-hubs are associated with a set of V-spokes, then each 217 V- hub advertises it with a distinct RD when originating this route. 218 If a V-spoke imports several of these unknown MAC routes and they all 219 have the same preference, then traffic from the V-spoke to other 220 sites of that EVI would be load balanced among the V-hubs. 222 5.1. Originating EVPN Unknown MAC Route by a V-Hub 224 Section 7.3 of the [RFC7024] defines procedures for originating a 225 VPN-IP default route for a VPN. The same procuedures apply when a 226 V-hub wants to originate EVPN unknown MAC route for a given EVI. The 227 V-hub MUST announce unknown MAC route using the MAC/IP advertisement 228 route along with the Default Gateway extended community as defined in 229 section 10.1 of the [RFC7432]. 231 5.2. Processing VPN-MAC EVPN unknown Route by a V-SPOKE 233 Within a given EVPN, a V-spoke MUST import all the unknown MAC routes 234 unless the route-target mismatch happens. The processing of the 235 received VPN-MAC EVPN default route follows the rules explained in 236 the section 3 of the [RFC7024]. The unknown MAC route MUST be 237 installed according to the rules of MAC/IP Advertisement route 238 installation rules in section 9.2.2 of [RFC7024]. 240 In absense of any more specific VPN-MAC EVPN routes, V-spokes 241 installing the unknown MAC route MUST use the route when performing 242 ARP proxy. This behavior would allow V-Spokes to forward the traffic 243 towards V-Hub. 245 5.3. Aliasing 247 [RFC7432] describes the concept and procedures for Aliasing where a 248 station is multi-homed to multiple PEs operating in an All-Active 249 redundancy mode, it is possible that only a single PE learns a set of 250 MAC addresses associated with traffic transmitted by the station. 251 [RFC7432] describes the concepts and procedures for Aliasing, which 252 occurs when a CE is multi-homed to multiple PE nodes, operating in 253 all-active redundancy mode, but not all of the PEs learn the CE's set 254 of MAC addresses. This leads to a situation where remote PEs receive 255 MAC advertisement routes, for these addresses, from a single NVE even 256 though multiple NVEs are connected to the multi-homed station. As a 257 result, the remote NVEs are not able to effectively load-balance 258 traffic among the NVEs connected to the multi-homed Ethernet segment. 260 To alleviate this issue, EVPN introduces the concept of Aliasing. 261 This refers to the ability of a PE to signal that it has reachability 262 to a given locally attached Ethernet segment, even when it has learnt 263 no MAC addresses from that segment. The Ethernet A-D per-EVI route 264 is used to that end. Remote PEs which receive MAC advertisement 265 routes with non-zero ESI SHOULD consider the MAC address as reachable 266 via all NVEs that advertise reachability to the relevant Segment 267 using Ethernet A-D routes with the same ESI and with the Single- 268 Active flag reset. 270 This procedure is impacted for virtual hub-and-spoke topology because 271 a given V-spoke does not receive any MAC/IP advertisements from 272 remote V-spokes; therefore, there is no point in propagating Ethernet 273 A-D per-EVI route to the remote V-spokes. In this solution, the V- 274 hubs terminate the Ethernet A-D per-EVI route (used for Aliasing) and 275 follows the procedures described in [RFC7432] for handling this 276 route. 278 There are scenarios for which it is desirable to establish direct 279 communication path between a pair of V-spokes for a given host MAC 280 address. In such scenario, the advertising V-spoke advertises both 281 the MAC/IP route and Ethernet A-D per-EVI route with the RT of V-hub 282 (RT-VH) per section 3 of [RFC7024]. The use of RT-VH, ensures that 283 these routes are received by the V-spokes associated with that V-hub 284 set and thus enables the V-spokes to perform the Aliasing procedure. 286 In summary, PE devices (V-hubs in general and V-spokes occasionally) 287 that receive EVPN MAC/IP route advertisements (associated with a 288 multi-homed site) need to also receive the associated Ethernet A-D 289 per-EVI route advertisement(s) in order for them to perform Aliasing 290 procedure. 292 5.4. Split-Horizon And Mass Withdraw 294 [RFC7432] uses Ethernet A-D per-ES route to a) signal to remote PEs 295 the multi-homing redundancy type (Single-Active versus All-Active), 296 b) advertise ESI label for split-horizon filtering when MPLS 297 encapsulation is used, and c) advertise mass-withdraw when a failure 298 of an access interface impacts many MAC addresses. This route does 299 not need to be advertise from a V-spoke to any remote V-spoke unless 300 a direct communication path between a pair of spoke is needed for a 301 given flow. 303 Even if communication between a pair of V-spoke is needed for just a 304 single flow, the Ethernet A-D per ES route needs to be advertised 305 from the originating V-spoke for that ES which may handle tens or 306 hundreds of thousands of flows. This is because in order to perform 307 Aliasing function for a given flow, the Ethernet A-D per-EVI route is 308 needed and this route itself is dependent on the Ethernet A-D per-ES 309 route. In such scenario, the advertising V-spoke advertises the 310 Ethernet A-D per-ES route with the RT of V-hub (RT-VH) per section 3 311 of [RFC7024]. 313 In summary, PE devices (V-hubs in general and V-spokes occasionally) 314 that receive EVPN MAC/IP route advertisements (associated with a 315 multi-homed site) need to also receive the associated Ethernet A-D 316 per-ES route advertisement(s). 318 6. Forwarding Considerations 320 6.1. IP-only Forwarding 322 When EVPN operates in IP-only forwarding mode using EVPN Route Type 323 5, then all forwarding considerations in section 4 of [RFC7024] are 324 directly applicable here. 326 6.2. MAC-only Forwarding - Bridging 328 When EVPN operates in MAC-only forwarding mode (i.e., bridging mode), 329 then for a given EVI, the MPLS label that a V-hub advertises with an 330 Unknown MAC address MUST be the label that identifies the MAC-VRF of 331 the V-hub in absense of a more specific MAC route. When the V-hub 332 receives a packet with such label, the V- hub pops the label and 333 determines further disposition of the packet based on the lookup in 334 the MAC-VRF. Otherwise, the MPLS label of the matching more specific 335 route is used and packet is is forwarded towards the associated 336 NEXTHOP of the more specific route. 338 6.3. MAC and IP Forwarding - IRB 340 When a EVPN speaker operates in IRB mode, it implements both the 341 a€œIP and MAC forwarding Modesa€ (aka Integrated 342 Routing and Bridging - IRB). On a packet by packet basis, the 343 V-spoke decides whether to do forwarding based on a MAC address 344 lookup (bridge) or based on a IP address lookup (route). If the host 345 destination MAC address is that of the IRB interface (i.e., if the 346 traffic is inter-subnet), then the V-spoke performs an additional IP 347 lookup in the IP-VRF. However, if the host destination MAC address 348 is that of an actual host MAC address (i.e., the traffic is intra- 349 subnet) , then the V-spoke only performs a MAC lookup in the MAC-VRF. 350 The procedure specified in Section 6.1 and Section 6.2 are applicable 351 to inter-subnet and intra-subnet forwarding respectively. For intra- 352 subnet traffic, if the MAC address is not found in the MAC-VRF, then 353 the V-spoke forwards the traffic to the V-hub with the MPLS label 354 received from the V-hub for the unknown MAC address. For the Inter- 355 subnet traffic, if the IP prefix is not found in the IP-VRF, then the 356 V-spoke forwards the traffic to the V-hub with the MPLS label 357 received from the V-hub for the default IP address. 359 7. Handling of the Broadcast and Multicast traffic 361 Just like that V-spoke to V-spoke known unicast traffic is relayed by 362 V-hubs, V-spoke to V-spoke BUM traffic can also relayed by V-hubs. 363 This is especially desired if Ingress Replication (IR) would be used 364 otherwise for V-spokes to send traffic to other V-spokes. This way, 365 a V-spoke can unicast BUM traffic to a single V-hub, who will then 366 relay the traffic. This achieves Assisted Replication, and reduces 367 multicast state in the core. Note that a V-hub may relay traffic 368 using MPLS P2MP tunnels or BIER as well as IR. While a V-spoke may 369 use P2MP tunnels or BIER to send traffic to V-hubs, this 370 specification focuses on using IR by V-spokes. 372 In this particular section, all traffic refers to BUM traffic unless 373 explicitly stated otherwise. The term PE refers to a V-hub or 374 V-spoke when there is no need to distinguish the two. 376 Consider the following topology, where V-spokes VS1/2/3 are 377 associated with V-hubs VH1/2 in one cluster, and V-spokes VS4/5/6 are 378 associated with V-hubs VH3/4 in another cluster. Note that the 379 lines/dots in the diagram indcate association, not connection. 381 VH1 ...VH2 VH3 ...VH4 382 / |.\ . . / |.\ . . 383 / .| .\ . / .| .\ . 384 /. |. \ . /. |. \ . 385 VS1 VS2 VS3 VS4 VS5 VS6 387 7.1. Split Horizon 389 When VH1 relays traffic that it receives from VS1, in case of IR it 390 MUST not send traffic back to VS1, and in case of P2MP tunnel it must 391 indicate that traffic is sourced from VS1 so that VS1 will discard 392 the traffic. In case of IR with IP unicsat tunnels, the outer source 393 IP address identifies the sending PE. In case of IR with MPLS 394 unicast tunnels, VH1 must advertise different labels to different 395 PEs, so that it can identify the sending PE based on the label in the 396 traffic from a V-spoke. 398 If MPLS P2MP/multicast tunnels (including VXLAN-GPE and MPLS-over- 399 GRE/UDP) are used by a V-hub to relay traffic, an upstream allocated 400 (by the V-hub) label MUST be imposed in the label stack to identify 401 the source of the V-spoke. The label is advertised as part of the PE 402 Distinguisher (PED) Label Attribute of the Inclusive Multicast 403 Ethernet Tag (IMET) route from the V-hub, as specified in Section 8 404 of [RFC 6514]. 406 Notice that an "upstream-assigned" label used by a V-hub to send 407 traffic with on a P2MP tunnel to identify the source V-spoke is the 408 same "downstream-assigned" label used by the V-hub to receive traffic 409 on the IR tunnel from the V-spoke. Therefore, the same PED Label 410 attribute serves two purposes. With [RFC 6514], a PED label may only 411 identify a PE but not a particular VPN. Here the PED label 412 identifies both the PE and a particular EVI/BD. A V-spoke programs 413 its context MPLS forwarding table for the V-hub to discard any 414 traffic with the PED label that the V-hub advertised for this 415 V-spoke, or pop other PED labels and direct traffic into a 416 corresponding EVI for L2 forwarding. 418 Note that a V-hub cannot use VXLAN/NVGRE multicast tunnels to relay 419 traffic because if the V-hub uses the source V-spoke's IP address in 420 the outer IP header (for the purpose of identifying the source 421 V-spoke), multicast RPF would fail and the packets will be discarded. 423 7.2. Route Advertisement 425 As with other route types, IMET routes from V-hubs are advertised 426 with RT-VH and RT-EVI so they are imported by associated V-spokes and 427 all V-hubs. They carry the PED Label attribute as described above. 429 IMET routes from V-spokes are advertised with RT-EVI so they are 430 imported by all V-hubs. They also carry PED Label attribute for 431 multi-homing split horizon purpose if and only if V-hubs uses IR to 432 relay traffic. 434 If a V-hub uses RSVP-TE P2MP tunnel, IR, or BIER to send or relay 435 traffic, all other PEs (V-hubs or V-spokes) will receive traffic 436 directly because the V-hub sees all PEs. If a V-hub uses mLDP P2MP 437 tunnel to send or relay traffic, only its associated V-spokes and all 438 V-hubs will see the V-hub's IMET route and join the tunnel announced 439 in the route. Another V-hub need to relay traffic to its associated 440 V-spokes that are not associated with this V-hub. 442 For that V-hub to announce the mLDP relay tunnel in its cluster, it 443 needs to advertise a (*,*) S-PMSI AD route, as specified in [draft- 444 zzhang-bess-evpn-bum-procedure-updates]. The route is advertised 445 with the RT-VH for that cluster, and associated V-spokes will join 446 the tunnel announced in the S-SPMI AD route. 448 7.3. Designated Forwarder in a Cluster 450 When there are multiple V-hubs in a cluster, a V-spoke in that 451 cluster decides by itself to which V-hub to send traffic. If the 452 receiving V-hub uses mLDP tunnel to relay traffic, V-hubs in other 453 clusters need to further relay traffic, but only one V-hub in each 454 cluster can do so. As a result, a DF must be elected among the 455 V-hubs for each cluster. 457 The election is similar to DF election in RFC 7432, with the 458 folllowing differences. 460 o Instead of using Ethernet Segment route to discover the PEs on a 461 multi-homing ES, the IMET route are used to determine the V-hubs 462 in the same cluster - they all carry the same pair of RT-EVI and 463 RT-VH, and advertises the unknown mac route. 465 o Instead of using VLAN to do per-VLAN DF election, the Local 466 Administration Field of the RT-EVI is used to do per-EVI DF 467 election. 469 7.4. Traffic Forwarding Rules 471 When a PE needs to forward received traffic from local Attachment 472 Circuits (ACs) or remote PEs to local ACs, it follows the rules in 473 RFC 7432, except that traffic sourced from this local PE but relayed 474 back on a p2mp tunnel is discarded. It may also need to forward to 475 other PEs, subject to rules in the following sections. 477 7.4.1. Traffic from Local ACs 479 Traffic from a V-hub's local ACs is forwarded using the tunnel 480 announced in its IMET route, as specified in RFC 7432. In case of an 481 mLDP tunnel, the traffic need to be relayed by V-hubs of other 482 clusters to their associated V-spokes. For other tunnel types, no 483 relay is needed. 485 Traffic from a V-spoke's local ACs is forwarded to an associated 486 V-hub of its choice. In case of MPLS IR, the label in the V-hub's 487 IMET route's PED attribute corresponding to this V-spoke is used. 489 7.4.2. Traffic Received by a V-hub from Another PE 491 When a V-hub receives traffic from an associated V-spoke, it needs to 492 relay to other PEs, using the tunnel announced in its IMET route. In 493 case of IR or BIER, the source V-spoke, which is determined from the 494 incoming label or source IP address, is excluded from the replication 495 list. In case of a P2MP tunnel, the popped incoming label is imposed 496 again to identify the source PE, before the tunnel label is imposed. 498 When a V-hub receives traffic from another V-hub on a P2MP tunnel, 499 and the tunnel is announced in an IMET route carrying the same RT-VH 500 as this V-hub is configured with, it does not need to relay the 501 traffic. Otherwise, the traffic is from a V-hub in a different 502 cluster, and this V-hub needs to relay to its associated V-spokes, if 503 and only if it is the DF for this cluster, using the tunnel announced 504 in its (*,*) S-PMSI route carrying its RT-VH. 506 When a V-hub recevies traffic from another V-hub via IR or BIER, it 507 does not further relay the traffic as that V-hub can reach all PEs. 509 7.4.3. Traffic received by a V-spoke from a V-hub 511 In case of P2MP tunnel, the V-spoke discards the traffic if the label 512 following the tunnel label identifies the V-spoke itself. 514 7.5. Multi-homing support 516 Consider that an ES spans across two V-spokes in the same cluster and 517 the V-hub uses MPLS IR to relay traffic. With ESI Label split 518 horizon method, a source V-spoke uses the ESI label advertised by the 519 V-hub for the ES, and the V-hub must change that to the ESI label 520 advertised by receiving v-spokes when it relays traffic. That means 521 V-hubs must advertise ESI labels for all multi-homing segments, even 522 when they're not on those segments. They must also do double label 523 swap (EVI/BD label and ESI label) or mac lookup when relaying 524 traffic. 526 To avoid that complexity, Local Bias is the preferred method for 527 split horizon. The PED label following the mpls transport tunnel 528 label or BIER header identifies the PE that originated the traffic in 529 addition to identifying the EVI/BD. 531 If a V-hub uses P2MP or BIER to relay traffic, the PED label is one 532 of the labels in the PE Distinguiser Label attribute in the V-hub's 533 IMET route, allocated by the V-hub for the source V-spoke. 535 If a V-hub uses IR to relay traffic, for each V-spoke that it relays 536 to, the PED label advertised by that receiving V-spoke for the source 537 V-spoke needs to be imposed by the V-hub. For that purpose, each 538 V-spoke must include the PED Label attribute in its IMET route, to 539 advertise different labels for different PEs. It discovers the PEs 540 that it needs to advertise labels for via the PED label Attribute in 541 the V-hub's IMET route. 543 7.6. Direct V-spoke to V-spoke traffic 545 It may be desired for allow direct V-spoke to V-spoke traffic in a 546 cluster, without the relay by a V-hub. 548 To do that, V-spokes advertise their IMET routes with both RT-VH and 549 RT-EVI. 551 Forwarding rules will be specified in future revisions. 553 8. ARP/ND Suppression 555 [RFC7432] defines the procedures for ARP/ND suppression where a PE 556 can terminate gratuitous ARP/ND request message from directly 557 connected site and advertises the associated MAC and IP addresses in 558 an EVPN MAC/IP advertisement route to all other remote PEs. The 559 remote PEs that receive this EVPN route advertisement, install the 560 MAC/IP pair in their ARP/ND cache table thus enabling them to 561 terminate ARP/ND requests and generate ARP/ND responses locally thus 562 suppressing the flooding of ARP/ND requests over the EVPN network. 564 In this hub-and-spoke approach, the ARP suppression needs to be 565 performed by both the EVPN V-hubs as well V-spokes as follow. When a 566 V-Spoke receives a gratuitous ARP/ND request, it terminates it and 567 stores the source MAC/IP pair in its ARP/ND cache table. Then, it 568 advertises the source MAC/IP pair to its associated V-Hubs using EVPN 569 MAC/IP advertisement route. The V-Hubs upon receiving this EVPN 570 route advertisement, create an entry in their ARP/ND cache table for 571 this MAC/IP pair. 573 Now when a V-Spoke receives an ARP/ND request, it first looks up its 574 ARP cache table, if an entry for that MAC/IP pair is found, then an 575 ARP/ND response is generated locally and sent to the CE. However, if 576 an entry is not found, then the ARP/ND request is unicasted to one of 577 the V-hub associated with this V-spoke. Since, the associated V-hub 578 keeps all the MAC/IP ARP entries in its cache table, it can formulate 579 and ARP/ND response and forward it to that CE via the corresponding 580 V-spoke. 582 9. IANA Considerations 584 This document does NOT make any new requests for IANA allocations. 586 10. Security Considerations 588 All the security considerations in [RFC7432] apply directly to this 589 document because this document leverages [RFC7432] control plane and 590 their associated procedures - although not the complete set but 591 rather a subset. 593 This draft does not introduce any new security considerations beyond 594 that of [RFC7432] and [RFC4761] because advertisements and processing 595 of B-MAC addresses follow that of [RFC7432] and processing of C-MAC 596 addresses follow that of [RFC4761] - i.e, B-MAC addresses are learned 597 in control plane and C-MAC addresses are learned in data plane. 599 11. Acknowledgements 601 The authors would like to thank Yakov Rekhter for initial idea 602 discussions. 604 12. Change Log 606 Initial Version: Sep 21 2014 608 13. References 610 13.1. Normative References 612 [I-D.zzhang-bess-evpn-bum-procedure-updates] 613 Zhang, J., Lin, W., Rabadan, J., and K. Patel, "Updates on 614 EVPN BUM Procedures", draft-zzhang-bess-evpn-bum- 615 procedure-updates-01 (work in progress), December 2015. 617 [RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP- 618 4)", RFC 1771, DOI 10.17487/RFC1771, March 1995, 619 . 621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 622 Requirement Levels", BCP 14, RFC 2119, 623 DOI 10.17487/RFC2119, March 1997, 624 . 626 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 627 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 628 DOI 10.17487/RFC2784, March 2000, 629 . 631 [RFC3484] Draves, R., "Default Address Selection for Internet 632 Protocol version 6 (IPv6)", RFC 3484, 633 DOI 10.17487/RFC3484, February 2003, 634 . 636 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 637 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 638 RFC 3931, DOI 10.17487/RFC3931, March 2005, 639 . 641 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 642 for IPv6 Hosts and Routers", RFC 4213, 643 DOI 10.17487/RFC4213, October 2005, 644 . 646 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 647 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 648 DOI 10.17487/RFC4271, January 2006, 649 . 651 [RFC4374] McCobb, G., "The application/xv+xml Media Type", RFC 4374, 652 DOI 10.17487/RFC4374, January 2006, 653 . 655 [RFC6459] Korhonen, J., Ed., Soininen, J., Patil, B., Savolainen, 656 T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 657 Partnership Project (3GPP) Evolved Packet System (EPS)", 658 RFC 6459, DOI 10.17487/RFC6459, January 2012, 659 . 661 [RFC7024] Jeng, H., Uttaro, J., Jalil, L., Decraene, B., Rekhter, 662 Y., and R. Aggarwal, "Virtual Hub-and-Spoke in BGP/MPLS 663 VPNs", RFC 7024, DOI 10.17487/RFC7024, October 2013, 664 . 666 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 667 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 668 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 669 2015, . 671 13.2. Informative References 673 [I-D.drao-bgp-l3vpn-virtual-network-overlays] 674 Rao, D., Mullooly, J., and R. Fernando, "Layer-3 virtual 675 network overlays based on BGP Layer-3 VPNs", draft-drao- 676 bgp-l3vpn-virtual-network-overlays-03 (work in progress), 677 July 2014. 679 [I-D.ietf-bess-evpn-overlay] 680 Sajassi, A., Drake, J., Bitar, N., Isaac, A., Uttaro, J., 681 and W. Henderickx, "A Network Virtualization Overlay 682 Solution using EVPN", draft-ietf-bess-evpn-overlay-01 683 (work in progress), February 2015. 685 [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery 686 Proxies (ND Proxy)", RFC 4389, DOI 10.17487/RFC4389, April 687 2006, . 689 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 690 LAN Service (VPLS) Using BGP for Auto-Discovery and 691 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 692 . 694 [RFC7080] Sajassi, A., Salam, S., Bitar, N., and F. Balus, "Virtual 695 Private LAN Service (VPLS) Interoperability with Provider 696 Backbone Bridges", RFC 7080, DOI 10.17487/RFC7080, 697 December 2013, . 699 [RFC7209] Sajassi, A., Aggarwal, R., Uttaro, J., Bitar, N., 700 Henderickx, W., and A. Isaac, "Requirements for Ethernet 701 VPN (EVPN)", RFC 7209, DOI 10.17487/RFC7209, May 2014, 702 . 704 Authors' Addresses 706 Keyur Patel 707 Arrcus 709 Email: keyur@arrcus.com 711 Ali Sajassi 712 Cisco Systems 713 170 W. Tasman Drive 714 San Jose, CA 95124 95134 715 USA 717 Email: sajassi@cisco.com 718 John E. Drake 719 Juniper Networks, Inc. 721 Email: jdrake@juniper.net 723 Zhaohui Zhang 724 Juniper Networks, Inc. 726 Email: zzhang@juniper.net 728 Wim Henderickx 729 Nokia 731 Email: wim.henderickx@nokia.com