idnits 2.17.1 draft-hao-l2vpn-evpn-mhn-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- -- The document has an IETF Trust Provisions (28 Dec 2009) Section 6.c(ii) Publication Limitation clause. If this document is intended for submission to the IESG for publication, this constitutes an error. 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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([EVPN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 130: '... A solution MUST support multi-homed...' RFC 2119 keyword, line 133: '... A solution MUST also support multi-...' RFC 2119 keyword, line 137: '... A solution MAY support VLAN-based l...' RFC 2119 keyword, line 140: '... A solution MAY support multi-homed ...' RFC 2119 keyword, line 235: '...A-D route per Ethernet segment MUST be...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 83 has weird spacing: '... called desig...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 14, 2013) is 3941 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) -- Looks like a reference, but probably isn't: 'EVPN' on line 494 -- Looks like a reference, but probably isn't: 'EVPN-REQ' on line 127 -- Looks like a reference, but probably isn't: 'G.8032' on line 229 -- Looks like a reference, but probably isn't: 'RFC2119' on line 160 -- Looks like a reference, but probably isn't: 'RFC6325' on line 161 == Unused Reference: '1' is defined on line 517, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 521, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-00 Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 L2VPN Weiguo Hao 2 Yizhou Li 3 Pei Xu 4 Internet Draft Huawei 5 Intended status: Standards Track June 14, 2013 6 Expires: December 2013 8 Multi-homed network in EVPN 9 draft-hao-l2vpn-evpn-mhn-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. This document may not be modified, 18 and derivative works of it may not be created, and it may not be 19 published except as an Internet-Draft. 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may not be modified, 23 and derivative works of it may not be created, except to publish it 24 as an RFC and to translate it into languages other than English. 26 This document may contain material from IETF Documents or IETF 27 Contributions published or made publicly available before November 10, 28 2008. The person(s) controlling the copyright in some of this 29 material may not have granted the IETF Trust the right to allow 30 modifications of such material outside the IETF Standards Process. 31 Without obtaining an adequate license from the person(s) controlling 32 the copyright in such materials, this document may not be modified 33 outside the IETF Standards Process, and derivative works of it may 34 not be created outside the IETF Standards Process, except to format 35 it for publication as an RFC or to translate it into languages other 36 than English. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF), its areas, and its working groups. Note that 40 other groups may also distribute working documents as Internet-Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 46 The list of current Internet-Drafts can be accessed at 47 http://www.ietf.org/ietf/1id-abstracts.txt 49 The list of Internet-Draft Shadow Directories can be accessed at 50 http://www.ietf.org/shadow.html 52 This Internet-Draft will expire on December 14, 2013. 54 Copyright Notice 56 Copyright (c) 2013 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents carefully, 63 as they describe your rights and restrictions with respect to this 64 document. Code Components extracted from this document must include 65 Simplified BSD License text as described in Section 4.e of the Trust 66 Legal Provisions and are provided without warranty as described in 67 the Simplified BSD License. 69 This document is subject to BCP 78 and the IETF Trust's Legal 70 Provisions Relating to IETF Documents 71 (http://trustee.ietf.org/license-info) in effect on the date of 72 publication of this document. Please review these documents carefully, 73 as they describe your rights and restrictions with respect to this 74 document. 76 Abstract 78 To enhance the reliability, bridged network is normally multi-homed 79 to an EVPN network, there are two categories of mechanisms to avoid 80 the layer 2 traffic loop. The first category does not require the PEs 81 participating in the control protocol of the bridged network, while 82 the second category requires that. [EVPN] described one of the first 83 category mechanisms called designated forwarder (DF) election to 84 achieve loop avoidance and vlan-based load balancing. This draft 85 mainly focuses on the second category of mechanisms which can achieve 86 intra-vlan MAC-based load balancing. MAC-based VLAN balancing is more 87 applicable than DF election mechanism if all end stations in bridged 88 network are on the same VLAN which can cause traffic congestion in DF 89 link. 91 Table of Contents 93 1. Introduction ................................................ 3 94 2. Conventions used in this document............................ 4 95 3. Recap on Designated Forwarder (DF) election mechanism.........4 96 4. Active/Active MAC-based load balancing mechanism .............6 97 4.1. Emulated MSTP root bridge solution ......................7 98 4.2. Bridge control plane protocol tunneling solution.........8 99 4.2.1. Scenario 1: Local bridged network is MSTP..........10 100 4.2.2. Scenario 2: Local bridged network is G.8032........10 101 4.2.3. Fast convergence.................................. 10 102 5. EVPN protocol extension..................................... 11 103 6. Security Considerations..................................... 11 104 7. IANA Considerations ........................................ 11 105 7.1. Normative References................................... 12 106 7.2. Informative References................................. 12 107 8. Acknowledgments ............................................ 12 109 1. Introduction 111 [EVPN] introduces a solution for multipoint L2VPN services. In EVPN 112 networks, MAC learning between PEs is not via the data 113 plane( different from what happens in traditional bridging network) 114 but via the control plane using multi-protocol (MP) BGP. 116 To enhance the reliability, the PE nodes need offer multi-homed 117 connectivity to a CE or access Network, i.e, both multi-homed device 118 (MHD) as well as multi-homed network (MHN) scenarios in [EVPN-REQ] 119 should be covered by E-VPN solution. In MHN scenario, the multi-homed 120 Ethernet network would typically run a resiliency mechanism such as 121 Multiple Spanning Tree Protocol [802.1Q] or Ethernet Ring Protection 122 Switching [G.8032]. For example, EVPN can be used for Data Center(DC) 123 interconnection to provide LAN extension for each DC site and each 124 site is an MSTP networks. Normally each site should be multi-homed to 125 multiple EVPN PEs to ensure the reliability. 127 As defined in [EVPN-REQ], the following solutions should be provided 128 for MHN scenario: 130 A solution MUST support multi-homed network connectivity with 131 active/standby redundancy. 133 A solution MUST also support multi-homed network with active/active 134 VLAN-based load balancing (i.e. disjoint VLAN sets active on 135 disparate PEs). 137 A solution MAY support VLAN-based load balancing among PEs that are 138 member of a redundancy group spanning multiple ASes. 140 A solution MAY support multi-homed network with active/active MAC- 141 based load balancing (i.e. different MAC addresses on a VLAN are 142 reachable via different PEs). 144 The former three requirements can be addressed through designated 145 forwarder (DF) election mechanism as described in [EVPN], a brief 146 review of DF election mechanism will be given in section 3. 148 This draft will mainly focus on a new mechanism to achieve 149 active/active MAC-based load balancing to fulfil the fourth 150 requirement. The details of the solution will be illustrated in 151 section 4. Protocol extensions of EVPN for this mechanism will be 152 given in section 5. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 157 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 158 this document are to be interpreted as described in RFC-2119 159 [RFC2119]. 161 This document uses the terminologies defined in [RFC6325] along with 162 the following: 164 EVPN: Ethernet virtual private network. 166 G.8032: Ethernet ring protection switching. 168 NVO3: Network virtualization over layer3. 170 STP: Spanning Tree Protocol. 172 3. Recap on Designated Forwarder (DF) election mechanism 174 ------------------ 176 / \ 178 | EVPN Network | 180 \ / 182 ------------------ 183 | | 185 | | 187 +------+ +------+ 189 DF --->| PE1 | | PE2 | 191 +------+ +------+ 193 | | 195 +---------------------------------------------+ 197 | | | | 199 | STP | | | 201 | +----+ root+----+ +----+ | 203 | | B4 |-------| B1 |-------| B2 | | 205 | +----+ +----+ +----+ | 207 | | | | 209 | | | | 211 | | |<---blocked | 213 |Bridged | +----+ | | 215 |LAN +-----| B3 |----+ | 217 | +----+ | 219 +---------------------------------------------+ 221 Figure 1 DF election mechanism 223 As described in [EVPN], designated forwarder(DF) mechanism is 224 required for loop avoidance. Only one of the links between the 225 switched bridged network and the PEs is active for a given Ethernet 226 tag, as shown by Figure 1. This mechanism does not require the PEs to 227 participate in the control protocol of the bridged network. Bridges 228 in the local bridged network runs normal Multiple Spanning Tree 229 Protocol [802.1Q] or Ethernet Ring Protection Switching [G.8032]. 231 Through this method VLAN-based load balancing among PEs can be 232 achieved. All end systems of one VLAN can access the EVPN network 233 through only one PE. 235 In this case, the Ethernet A-D route per Ethernet segment MUST be 236 advertised with the "Active-Standby" flag set to one. Only one PE is 237 elected as DF for each EVI(E-VPN Instance). Only DF is responsible 238 for sending multicast, broadcast and unknown unicast traffic, on a 239 given Ethernet tag to the bridged network. In order to perform better 240 traffic load-balancing within a given segment, multiple DFs per 241 Ethernet segment can be elected and each PE is the DF for a disjoint 242 set of EVIs. An EVI is an E-VPN routing and forwarding instance on a 243 PE and consists of one or more broadcast domains which is identified 244 by an Ethernet Tag which are assigned to the broadcast domains of a 245 given E-VPN instance by the provider of that E-VPN. The information 246 about an Ethernet Tag on a particular Ethernet segment is advertised 247 using an "Ethernet Auto-Discovery route(Ethernet A-D route)". In the 248 case of a multi-homed CE, this route MUST carry the "ESI Label 249 Extended Community" to enable split horizon. Also, the route can be 250 used for Designated Forwarder (DF) election and MAY be used to 251 optimize the withdrawal of MAC addresses upon failure. 253 For fast convergence case, upon a failure in connectivity to the 254 attached segment, the PE withdraws the corresponding Ethernet A-D 255 route. This triggers all PEs that receive the withdrawal to update 256 their next-hop adjacencies for all MAC addresses associated with the 257 Ethernet segment in question. If there is any other PE advertising 258 an Ethernet A-D route for the same segment, the PE updates the next- 259 hop adjacencies to point to this backup PE(s). 261 With DF mechanism, native frames enter and leave bridged network via 262 the same designated forwarder for a given VLAN. It may cause 263 congestion or suboptimal routing. PE and bridges should be carefully 264 configured so that end stations on a remnant bridged LAN are 265 separated into different VLANs that have different designated 266 forwarders to achieve better load balancing. 268 4. Active/Active MAC-based load balancing mechanism 270 Active/Active MAC-based load balancing mechanism requires the PEs to 271 participate in the control plane protocol of the bridged network. 272 With this mechanism, loop avoidance and per-vlan MAC-based load 273 balancing can be achieved. So it can achieve better load balancing 274 than DF election, and is more applicable if all end stations in 275 bridged network on the same VLAN may cause traffic congestion over 276 the link to DF. 278 The following two solutions can be used to achieve active/active MAC- 279 based load balancing. One is emulated MSTP root bridge solution; 280 another is bridge control plane protocol tunneling solution. We will 281 described them in the following subsections respectively. 283 4.1. Emulated MSTP root bridge solution 285 +------+ 287 | PE3 | 289 +------+ 291 | 293 | 295 | 297 ------------------ 299 / \ 301 | EVPN Network | 303 \ / 305 ------------------ 307 | | 309 | | 311 -----+-----------+---- 313 / +------+ +------+ \ <---emulated hig 315 | | PE1 | | PE2 | | priority roo 317 -------------| +------+ +------+ |--------- 319 | \-----+-----------+-----/ | 321 | | | | 323 | | | | 324 | | | | 326 | +----+ +----+ \|/ +----+ | 328 | | B4 |-------| B1 |--- ---| B2 | | 330 | +----+ p1 +----+ /|\ +----+ | 332 | | | | | 334 | | blocked \|/ | 336 | | - ----blocked | 338 |Bridged | /|\ | 340 |LAN | +----+ | | 342 | +-----| B3 |----+ | 344 | p1 +----+ p2 | 346 ----------------------------------------------- 348 Figure 2 emulated MSTP root bridge solution 350 PE1 and PE2 act as an emulated MSTP root bridge. PE1 & PE2 use the 351 same bridge ID to emit spanning tree BPDUs as the highest priority 352 root Bx. All bridges in bridged network see PE1 and PE2 as single 353 tree root. Therefore B1-B2 and B2-B3 links are blocked for loop 354 avoidance by the spanning tree protocol. 356 When B1-B3 link fails, alternate port p2 on B3 will start to send TC 357 BPDU and go to forwarding state. PE2 receives TC BPDU from B2 358 sequentially. PE2 tunnel the TC BPDU to PE1. At the same time, PE2 359 notifies remote PE3 to flush the MAC table through corresponding 360 Ethernet A-D route. 362 With this solution, PE1 and PE2 needs to tunnel TC BPDU to each other 363 when topology change occurs in the local bridged network. 365 4.2. Bridge control plane protocol tunneling solution 367 +------+ 369 | PE3 | 370 +------+ 372 | 374 | 376 ------------------ 378 / \ 380 | EVPN Network | 382 \ / 384 ------------------ 386 | | 388 | | 390 +------+ +------+ <---BPDU message is 391 tunneled 393 | PE1 | | PE2 | between PE1 and 394 PE2 396 ------------- +------+ +------+ --------- 398 | | | 400 | | | | 402 | | | | 404 | | | | 406 | +----+ +----+ \|/ +----+ | 408 | | B4 |-------| B1 |--- ---| B2 | | 410 | +----+ p1 +----+ /|\ +----+ | 412 | | | | | 414 | | blocked \|/ | 416 | | - ----blocked | 417 |Bridged | /|\ | 419 |LAN | +----+ | | 421 | +-----| B3 |----+ | 423 | p1 +----+ p2 | 425 ----------------------------------------------- 427 Figure 3 PE1 and PE2 act as normal MSTP bridge nodes 429 The solution described in the previous section is applicable for 430 STP/MSTP domain. Now we are going to present another solution which 431 can be used for both MSTP and G.8032 domain. The basic idea is to 432 tunnel the control plane messages of local domain among the multi- 433 homed PEs over EVPN network. 435 4.2.1. Scenario 1: Local bridged network is MSTP 437 PE1 and PE2 act as normal MSTP bridge nodes. MSTP root bridge can be 438 PE or any switch in the bridged network. BPDU message can be sent 439 through tunnel over EVPN network between PE1 and PE2. The tunnel can 440 be MPLS P2P LSP, MPLS P2MP LSP, or NVO3 tunnel, etc. PE1 and PE2 441 regard the BPDU tunnel as normal physical link. To avoid BPDU tunnel 442 blocked by MSTP, link cost of the tunnel should be set to 0 or 443 minimum value in MSTP network. With such configuration, it is 444 expected that the blocked port by MSTP protocol can never be the EVPN 445 network facing port on PEs. 447 4.2.2. Scenario 2: Local bridged network is G.8032 449 Similarly, PE1 and PE2 act as normal G.8032 ring nodes. They support 450 standard FDB MAC learning, forwarding, flush behavior and port 451 blocking/unblocking mechanisms. G.8032 message can be sent through 452 tunnel over EVPN network between PE1 and PE2. ring protection 453 link(RPL) owner node can be PE or any switch in bridged network. If 454 PE is RPL owner node, RPL can only be configured on access link and 455 can never be configured on the EVPN network facing port on PEs. 457 4.2.3. Fast convergence 459 For fast convergence, when a PE notice a topology change event, it 460 should flush local MAC entries and notify the remote PE of the same 461 EVPN instance to withdraw the corresponding Ethernet A-D route. The 462 remote PE that received the withdrawal simply invalidates the MAC 463 entries for that segment. 465 5. EVPN protocol extension 467 ESI Label Extended Community MUST be included in EVPN Ethernet A-D 468 route. All-Active multi-homing or active-standby multi-homing mode is 469 decided by the "Active-Standby" bit in the flags of the ESI Label 470 Extended Community through DF mechanism. 472 ESI Label Extended Community should be extended to support the 473 mechanisms illustrated in this document. "M" bit is introduced to 474 indicate multi-homing mode of MAC-based all active without DF 475 Election. DF selection procedures should be skipped if "M" bit is set 476 to be 1. When remote PE receives Ethernet A-D route withdraw message, 477 it simply invalidates the MAC entries for the segment that 478 corresponding to the Ethernet A-D route. 480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Type=0x06 | Sub-Type=0x01 |DF|R|M| Reserved=0 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | Reserved = 0| ESI Label | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 DF: As defined in [EVPN]. It should be ignored if M bit is 1. 494 R: The bit is already defined as the "Root-Leaf" in [EVPN]. 496 M: The bit is defined as "MAC-based all active without DF Election" 497 and may be set to 1. The above "DF" bit is significant only when "M" 498 bit is set to 0. A value of 1 for M bit means that multi-homed site 499 uses MAC-based active-active access. 501 6. Security Considerations 503 TBD 505 7. IANA Considerations 507 TBD 509 7.1. Normative References 511 [1] [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 513 Requirement Levels", BCP 14, RFC 2119, March 1997. 515 7.2. Informative References 517 [1] [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 519 Ethernet VPN", draft-ietf-l2vpn-evpn-req-01.txt. 521 [2] [EVPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft- 522 ietf-l2vpn-evpn-00.txt, work in progress, February, 2012. 524 8. Acknowledgments 526 The authors wish to acknowledge the important contributions of 527 Shunwan Zhuang. 529 Authors' Addresses 531 Weiguo Hao 532 Huawei Technologies 533 101 Software Avenue, 534 Nanjing 210012 535 China 536 Phone: +86-25-56623144 537 Email: haoweiguo@huawei.com 539 Yizhou Li 540 Huawei Technologies 541 101 Software Avenue, 542 Nanjing 210012 543 China 544 Phone: +86-25-56625375 545 Email: liyizhou@huawei.com 546 Pei Xu 547 Huawei Technologies 548 101 Software Avenue, 549 Nanjing 210012 550 China 551 Phone: +86-25-56623590 552 Email: xupei@huawei.com