idnits 2.17.1 draft-xia-nvo3-l2gw-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([IEEE802.1Q], [NVO3FRWK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3462 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: 'IEEE802.1Q' is mentioned on line 17, but not defined == Missing Reference: 'IEEE802.1AD' is mentioned on line 674, but not defined == Unused Reference: 'NVGRE' is defined on line 720, but no explicit reference was found in the text == Unused Reference: 'VXLAN' is defined on line 724, but no explicit reference was found in the text == Unused Reference: 'EVPN-REQ' is defined on line 731, but no explicit reference was found in the text == Unused Reference: 'EVPN-MHN' is defined on line 734, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-nvo3-framework-07 == Outdated reference: A later version (-08) exists of draft-sridharan-virtualization-nvgre-03 == Outdated reference: A later version (-09) exists of draft-mahalingam-dutt-dcops-vxlan-05 == Outdated reference: A later version (-11) exists of draft-ietf-l2vpn-evpn-07 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network working group L. Xia 2 Internet Draft L. Yong 3 Category: Standard Track Weiguo Hao 4 Huawei 5 Anoop Ghanwani 6 Dell 7 Ram Krishnan 8 Brocade 9 Expires: April 2015 October 27, 2014 11 Layer 2 Gateway (L2GW) 12 draft-xia-nvo3-l2gw-02 14 Abstract 16 A Layer 2 Gateway (L2GW) is used for interconnecting a Layer 2 17 overlay network [NVO3FRWK] and a Layer 2 bridged network [IEEE802.1Q] 18 to form a single Layer 2 virtual network. This draft describes data 19 plane interconnection and control plane interworking at the L2GW. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on April 27, 2015. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. 56 Table of Contents 58 1. Introduction ................................................ 3 59 1.1. Conventions used in this document ...................... 3 60 1.2. Terminology ............................................ 3 61 2. L2GW Reference Model......................................... 4 62 3. General L2GW Operation Procedures ........................... 5 63 3.1. MAC Learning ........................................... 5 64 3.2. ARP Handling ........................................... 6 65 3.3. Dual L2GWs ............................................. 6 66 4. L2CP Review and Applicability to L2 Overlay Network ......... 8 67 4.1. STP/RSTP/MSTP ......................................... 10 68 4.2. PAUSE ................................................. 11 69 4.3. LACP/LAMP ............................................. 11 70 4.4. Link OAM .............................................. 12 71 4.5. Port Authentication ................................... 12 72 4.6. E-LMI ................................................. 13 73 4.7. LLDP .................................................. 13 74 4.8. PTP Peer Delay ........................................ 13 75 4.9. ESMC .................................................. 13 76 4.10. GARP/MRP Block........................................ 14 77 5. L2CP Processing in L2GWs ................................... 14 78 5.1. L2CP Frames Filtered (Peered or Discarded) in L2GW .... 14 79 5.2. L2CP Frames Passed through L2GW ....................... 15 80 6. Other Interworking Cases ................................... 15 81 7. Security Considerations .................................... 16 82 8. IANA Considerations ........................................ 16 83 9. References ................................................. 16 84 9.1. Normative References .................................. 16 85 9.2. Informative References ................................ 16 87 1. Introduction 89 Cloud computing and network virtualization are evolving in the 90 direction of using network virtualization overlays over Layer 3 91 (NVO3). Some of the goals of NVO3 are -- fast and easy creation of 92 tenant networks, support tenant system mobility, and improved 93 manageability of all virtualized resources in the data center (DC). 95 Layer 2 (L2) overlay network in NVO3 means tenant systems are 96 interconnected at L2, while the NVEs are interconnected using Layer 97 3 (L3). As a result, it forms a full mesh topology of overlay 98 network, i.e. only one L2 hop between any pair of NVEs. On the other 99 hand, L2 bridged network is used to refer to the L2 network as 100 specified in IEEE 802.1Q [IEEE 802.1Q] in this draft. 102 In the first use case, involving DC network migration from physical 103 tenant systems to virtual tenant systems, it is expected that the L2 104 overlay network may be used along with an existing L2 bridged 105 network in a DC, and communication between them would be required. 106 In the last use case, a L2 bridged network would be used to connect 107 physical (non-virtualized) systems. These devices need to 108 communicate to virtualized networks for information exchange. Some 109 CPU-intensive applications such as big data analytics typically use 110 physical servers rather than making of use of server virtualization. 112 To interconnect two networks that are implemented with different 113 technologies (NVO3 and a bridged network), gateway functions are 114 needed on the device(s)/system(s) that interconnect them. This 115 device is referred to as a Layer 2 Gateway (L2GW) in this draft. The 116 device can be thought of as implementing an NVE that connects the 117 tenant systems in the L2 bridged network to tenant systems in the 118 NVO3 network. 120 1.1. Conventions used in this document 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC-2119 [RFC2119]. 126 1.2. Terminology 128 This document uses the terms defined in NVO3 framework [NVO3FRWK] 129 and architecture [NVO3ARCH] documents. 131 2. L2GW Reference Model 133 The following figure shows a reference model where an L2GW provides 134 an interconnection between an L2 overlay network and an L2 bridged 135 network. It shows the case where two different technologies are 136 used to implement a single L2 network. 138 ......... ......... 139 +---+ ... .... . +------+ 140 TSs-+NVE| +---------+ +-+Server| 141 +---+ L2 Overlay | | L2 Bridge . +------+ 142 . Network | L2GW | Network . 143 . | | . +------+ 144 ..+---+ +---------+ +-+Server| 145 TSs-+NVE| ... .... ... +------+ 146 +---+......... ........ 148 Figure 1: L2GW Reference Model 150 The L2GW can reside at the edge of the network providing direct 151 connection to tenant systems, or reside at aggregation or core where 152 the tenant systems attach to L2 switches. To connect with an L2 153 overlay network, an L2GW device physically connects to the underlay 154 network on which the L2 overlay network is implemented and it 155 functions as an NVE, providing termination for the L2 overlay 156 network . 158 To provide node failure resilience, the reference model can further 159 be shown as in Figure 2, where two L2GWs interconnect the two 160 networks. 162 ......... ......... 163 +---+ ... .... . +------+ 164 TSs-+NVE| +---------+ +-+Server| 165 +---+ L2 Overlay | L2GW | L2 Bridge . +------+ 166 . Network +---------+ Network . 167 . . +------+ 168 ..+---+ +---------+ +-+Server| 169 TSs-+NVE| ...| L2GW |.... ... +------+ 170 +---+......... +---------+ ........ 172 Figure 2: Redundant L2GW Model 174 Note that this draft assumes that L2GW device embeds an L2 NVE as 175 well as IEEE802.1Q bridge functions. 177 3. General L2GW Operation Procedures 179 3.1. MAC Learning 181 The MAC addresses for an L2 virtual network created by 182 interconnecting the two networks (the L2 overlay network and the L2 183 bridged network) needs to be distributed and/or learned at all NVEs 184 that participate in that L2 virtual network. If NVE-NVA architecture 185 is used, when an L2GW learns the MAC addresses from the bridged 186 network, the L2GW should notify NVA of the MAC addresses. The NVA 187 maintains the mapping of these MAC addresses from the L2GW, and 188 informs the other NVEs of the mappings. 190 Similarly, if the NVA maintains the mappings between a tenant 191 system's MAC address and NVE for an L2 virtual network, the NVA 192 would be expected to inform those mappings of MAC addresses to NVEs 193 to the L2GWs because the L2GWs also implement the functions of an 194 NVE. The L2GW maintains the mapping of VNID from the L2 overlay 195 network and VLAN ID in the bridged network. These mappings may be 196 manually configured at the L2GW or may be configured via the NVA. 198 The L2GW maintains a forwarding table per virtual network which has 199 all the MAC addresses learned from the bridged network as well as 200 all of the MAC addresses it received from the NVA for that virtual 201 network. 203 Upon receiving a packet from the overlay network, the L2GW 204 decapsulates the packet, performs the table lookup, and may insert a 205 VLAN ID (if the decapsulated frame doesn't already have one) or 206 modify the VLAN ID (if one is already present) prior to forwarding 207 it to the bridged network. If the destination MAC address of the 208 decapsulated packet is unknown (i.e. not present in the forwarding 209 table), the L2GW may choose to discard the packet or flood it on the 210 VLAN depending on the configured policy. 212 Upon receiving a frame from the L2 bridge network, the L2GW 213 encapsulates the frame prior to forwarding it to the remote NVE. If 214 the frame's MAC DA is unknown to L2GW, it will be discarded or 215 flooded to all the remote NVEs depending on the configured policy. 216 Note that the outer VLAN ID on the packet may be removed before the 217 encapsulation. 219 The two networks which are interconnected to form a single L2 220 virtual network MUST NOT have any overlapping MAC addresses; i.e. 221 the same MAC address cannot appear in the both the L2 overlay 222 network as well as the L2 bridged network. 224 3.2. ARP Handling 226 To avoid ARP flooding in the L2 overlay network, the L2GW may 227 maintain an ARP cache locally and/or rely on NVA to maintain the ARP 228 table. For the purpose of maintaining the ARP cache locally, the 229 L2GW can snoop ARP requests from the bridged network and send ARP 230 replies back. 232 If the L2 overlay network supports ARP flooding, the L2GW can simply 233 flood ARP requests from one network to another. 235 3.3. Dual L2GWs 237 Two L2GWs may be used for network interconnection to support a 238 network that is resilient to node failures. These two L2GWs may 239 further operate in Active/Standby or Active/Active mode. In 240 Active/Standby mode, only one of the L2GWs is actively passing 241 traffic from one network to the other for a given L2 virtual network. 242 In Active/Active mode, both L2GWs pass traffic from one network to 243 the other for a given virtual network. 245 (TBD: Does this need to be restricted to only two L2GWs?) 247 In Active/Standby mode, to protect node failure, some protocol is 248 necessary between the L2GWs to facilitate status exchange and 249 determine which of them will operate in Active mode. The 250 Active/Standby role may be configured or automatically selected 251 based on an algorithm or policy. An L2GW should inform NVA about its 252 role, i.e., Active or Standby, and the NVA should ensure that the 253 active L2GW IP address is used in the mapping of (inner) MAC 254 addresses to (outer) IP address. 256 In Active/Active mode, NVA/NVEs have two paths to the bridge network 257 and vise versa. The NVEs in an overlay can choose one based on the 258 policy. 260 The following presents the problems that need to be addressed and 261 related solutions for Active/Active connection scenarios: 263 1. MAC flip-flop on remote NVEs 265 MAC learning on an L2GW can be performed either in data plane or 266 control plane. When a local host h1 attaches to multiple L2GWs, 267 address learning at the remote NVEs for a given host h1 may 268 experience what we refer to as the MAC flip-flop problem where h1 269 appears behind the NVE of one L2GW and then subsequently appears 270 behind the NVE of the other L2GW, going back and forth in this 271 manner. 273 In the data plane learning scenario, an anycast L2GW IP address that 274 is shared among L2GWs may be used to avoid MAC flip-flop on remote 275 devices (NVEs, L2GWs, etc). When a bridged network attaches to 276 multiple L2GWs, any L2GW should use the shared anycast IP address, 277 rather than its own IP address, as the ingress NVE IP address when 278 it forwards NVO3 data frames into overlay network. Use of an 279 anycast L2GW IP address makes the MAC addresses learnt by the remote 280 devices appear to be behind a single source IP address rather than 281 multiple different source IP addresses. 283 In the control plane learning scenario (i.e. when NVA-NVE is used to 284 learn address mappings), if an L2 bridged network is multi-homed to 285 multiple L2GWs in Active/Active mode, each edge L2GW should announce 286 the MAC addresses of its attached end systems to all other devices 287 through NVE-NVA control plane protocol. For MAC addresses that 288 originate from multiple L2GWs, remote devices will learn the MAC 289 addresses as being associated with multiple ingress IP addresses and 290 will generate multiple MAC forwarding entries in ECMP mode. All edge 291 L2GWs should disable the data plane MAC learning function in their 292 NVEs; they must still continue to learn MAC addresses from traffic 293 received from the L2 bridged network. MAC address to NVE IP address 294 association should be learned only through the control plane. The 295 control plane must be aware of edge ports that are multi-homed to 296 multiple L2GWs. 298 2. Duplicated traffic from remote device 300 Frame duplication may occur when BUM (broadcast, unknown unicast, 301 multicast) traffics are forwarded bidirectionally between an L2 302 bridged network and a NVO3 network which have an Active/Active 303 connection through multiple edge L2GWs. The Designated Forwarder (DF) 304 election mechanism defined in [EVPN] can be used to resolve this 305 issue. According to [EVPN], multi-homing functions cover two 306 scenarios. For the MHN (Multi-Homed Network) scenario, DF election 307 mechanism allows only one L2GW of an edge group to forward BUM 308 traffics between NVO3 network and the L2 bridged network by two 309 directions for each VN. The basic idea of DF is to elect one L2GW 310 per VN from an edge group to be responsible for forwarding the BUM 311 traffics. For the MHD (Multi-Homed Device) scenario, the only 312 difference with MHN scenario is at the L2 bridged network side, MC- 313 LAG mechanism guarantees BUM traffics coming from L2 bridged network 314 only goes to one L2GW. DF mechanism is not needed in this direction. 316 3. Loops 318 Consider the case where a bridged network originates a frame that is 319 sent as a BUM frame to the NVO3 network via an L2GW, say L2GW1, that 320 is one of multiple gateways interconnecting the bridged network and 321 the NVO3 network. This frame will be encapsulated and then forwarded 322 through NVO3 network and reach the other L2GW, say L2GW2, that is 323 also connected to the bridged network. In this case, if L2GW2 324 decapsulates the NVO3 frame and forwards it into the bridged network 325 where the frame originated, the frame loops endlessly. This is why 326 it is important to have only single designated forwarder for 327 multicast traffic. 329 4. Unsynchronized information among member L2GWs 331 A local L2GW, say L2GW1 in an edge group, may have learned a VLAN 332 and MAC to IP correspondence for a remote end system ES1 when ES1 333 sends a packet to local bridge. The returning traffic from local 334 bridge may go to any other member L2GW of MC-LAG, for example L2GW2. 335 To avoid flooding unicast traffic on L2GW2, MAC address should be 336 synchronized among the edge L2GWs in an edge group. 338 Additionally, to ensure DF election consistency, dynamic joined VLAN 339 through VLAN registration protocol (VRP, [IEEE 802.1ak] amendment to 340 the [IEEE 802.1Q]) and dynamic joined multicast group through IGMP 341 or MLD protocol should be synchronized among all L2GWs in an edge 342 group. 344 4. L2CP Review and Applicability to L2 Overlay Network 346 This Section mainly discusses which L2CP (Layer 2 Control Protocol, 347 specified in [IEEE 802.1Q]) should be supported by L2 overlay 348 network and which should not, Section 5 specifies how L2GW should 349 deal with L2CP frames. 351 L2CP protocols defined in [IEEE 802.1Q] are listed in Table 1: 353 +------------------+----------+----------+---------------------+ 354 |MAC DA |Assignment| Protocol | L2CP Action | 355 | | | Type +----------+----------+ 356 | | | |VLAN-based|PORT-based| 357 | | | | L2 | L2 | 358 | | | | services | services | 359 +------------------+----------+----------+----------+----------+ 360 |01-80-C2-00-00-00 |Nearest |STP/RSTP/M|Filter |Pass | 361 | |Customer |STP, | | | 362 | |Bridge |LACP/LAMP | | | 363 +------------------+----------+----------+----------+----------+ 364 |01-80-C2-00-00-01 |IEEE MAC |PAUSE |Filter |Filter | 365 | |Specific | | | | 366 | |Control | | | | 367 | |Protocols | | | | 368 +------------------+----------+----------+----------+----------+ 369 |01-80-C2-00-00-02 |IEEE 802 |LACP/LAMP,|Filter |Filter | 370 | |Slow |Link OAM, | | | 371 | |Protocols |ESMC | | | 372 +------------------+----------+----------+----------+----------+ 373 |01-80-C2-00-00-03 |Nearest |Port |Filter |Filter | 374 | |non-TPRM |Authentica| | | 375 | |Bridge |tion, | | | 376 | | |LACP/LAMP | | | 377 +------------------+----------+----------+----------+----------+ 378 |01-80-C2-00-00-04 |IEEE MAC | |Filter |Filter | 379 | |Specific | | | | 380 | |Control | | | | 381 | |Protocols | | | | 382 +------------------+----------+----------+----------+----------+ 383 |01-80-C2-00-00-05 |Reserved | |Filter |Filter | 384 | |for Future| | | | 385 |01-80-C2-00-00-06 |Standardiz| | | | 386 | |ation | | | | 387 |01-80-C2-00-00-09 | | | | | 388 | | | | | | 389 |01-80-C2-00-00-0A | | | | | 390 +------------------+----------+----------+----------+----------+ 391 |01-80-C2-00-00-07 |MEF ELMI |E-LMI |Filter |Filter | 392 +------------------+----------+----------+----------+----------+ 393 |01-80-C2-00-00-08 |Provide | |Filter |Filter | 394 | |Bridge | | | | 395 | |Group | | | | 396 +------------------+----------+----------+----------+----------+ 397 |01-80-C2-00-00-0B |Reserved | |Filter |Pass | 398 | |for Future| | | | 399 |01-80-C2-00-00-0C |Standardiz| | | | 400 | |ation | | | | 401 +------------------+----------+----------+----------+----------+ 402 |01-80-C2-00-00-0D |Provider | |Filter |Pass | 403 | |Bridge | | | | 404 | |MVRP | | | | 405 +------------------+----------+----------+----------+----------+ 406 |01-80-C2-00-00-0E |Nearest |LLDP, PTP |Filter |Filter | 407 | |Bridge, |Peer Delay| | | 408 | |Individual| | | | 409 | |LAN Scope | | | | 410 +------------------+----------+----------+----------+----------+ 411 |01-80-C2-00-00-20 | |GARP/MRP |Pass |Pass | 412 | | |Block | | | 413 | through | | | | | 414 | | | | | | 415 |01-80-C2-00-00-2F | | | | | 416 +------------------+----------+----------+----------+----------+ 418 Table 1 L2CP protocols specification 420 Note: 422 Different L2CP protocols can use the same MAC DA in above block of 423 32 addresses, but be differentiated by protocol identifier. MAC DA 424 determines the intended recipient device for the frame; 426 Filter represent the L2CP action of peer or discard; 428 Based on whether L2 interface is VLAN-aware, L2 services can 429 divided into two categories: VLAN-based L2 services, PORT-based L2 430 services. L2CP action (peer, discard, pass) for these two L2 431 services is also different; 433 Whether the L2CP frames are peered or discarded is further 434 determined by the configuration of L2 interface. 436 Further analysis about whether a L2CP protocol is necessary and how 437 it is processed in NVO3 supported L2 VN, is provided in the 438 following sub sections. 440 4.1. STP/RSTP/MSTP 442 The Spanning Tree Protocol (STP) is a L2 protocol that ensures a 443 loop-free topology for any bridged Ethernet local area network. The 444 basic function of STP is to prevent bridge loops and the broadcast 445 storm that results from them. Rapid spanning Tree Protocol (RSTP) 446 and Multiple Spanning Tree Protocol (MSTP) are all the enhanced xSTP 447 protocols. 449 L2 overlay network does not need xSTP protocols to prevent bridge 450 loops because it has its own mechanism for it, i.e., NVA, control 451 plane mechanisms, full mesh + split horizon, etc. So, the process of 452 xSTP frames in L2 VN is: 454 Be in line with L2CP protocols' specification of Table 1 from IEEE 455 in the L2 sub-networks attached to L2 NVEs; 457 xSTP frames are filtered in L2 NVEs and should not go into L2 458 overlay network. 460 4.2. PAUSE 462 [IEEE 802.3-2005] has specified a L2 flow control mechanism through 463 using the PAUSE frame. This frame uses L2CP MAC DA of 01-80-C2-00- 464 00-01 to be sent to the node at the other end of the link for 465 informing it to halt the frame transmission for a specified period 466 of time. 468 When L2 NVE is co-located in Hypervisor, PAUSE frame is not 469 necessary in one device. When they are separated, PAUSE frame is 470 only used in layer 2 network between L2 NVE and Hypervisor, there is 471 no need to overlay PAUSE frame between L2 NVEs. For the underlay 472 network of NVO3 network, L2 PAUSE mechanism is still used between 473 two adjacent switches for flow control. 475 4.3. LACP/LAMP 477 Link Aggregation [IEEE 802.1AXbk-2012] is a mechanism for making 478 multiple point-to-point links between a pair of devices appear to be 479 a single logical link between those devices. Link Aggregation 480 Control Protocol (LACP) and Link Marker Control Protocol (LAMP) 481 operate between exactly two peer devices for the purpose of creating, 482 verifying, and monitoring the logical link created by aggregating 483 individual links. Specific L2CP frames, known as Link Aggregation 484 Control Protocol Data Units (LACPDUs), are exchanged between the 485 peer devices on each individual link in the aggregation. The 486 protocol identifier used by LACP is an Ethertype with a value of 487 0x8809 (the ''Slow Protocols'' Ethertype) and subtype values 01 (for 488 LACP) and 02 (for LAMP). Note that LACP is used to represent LACP 489 and LAMP in the following text. 491 LACP uses 3 different L2CP MAC DAs to determine the scope of 492 propagation of LACPDUs within a bridged LAN, as Table 2 follows: 494 +----------------+------------------+-----------------------------+ 495 |Assignment | L2CP MAC DA |Peered or discarded by | 496 +----------------+------------------+-----------------------------+ 497 |Nearest Customer| 01-80-C2-00-00-00|End Station, Customer Bridge,| 498 |Bridge | |Provider Edge Bridge | 499 +----------------+------------------+-----------------------------+ 500 |IEEE 802 Slow | 01-80-C2-00-00-02|End Station, Customer Bridge,| 501 |Protocols | |Provider Edge Bridge, | 502 | | |Provider Bridge | 503 +----------------+------------------+-----------------------------+ 504 |Nearest non-TPRM| 01-80-C2-00-00-03|Bridges except for Two Port | 505 |Bridge | |MAC Relay | 506 +----------------+------------------+-----------------------------+ 507 Table 2 LACP specification of L2CP MAC DAs 509 Base on the summary of Table 2, LACPDUs with the L2CP MAC DA of 01- 510 80-C2-00-00-02 are peered or discarded by every node, so this kind 511 of LACPDUs will not be overlaid across the L2 overlay network. For 512 01-80-C2-00-00-00, it is possible that LACPDUs need to be overlaid 513 across Provider Bridge and L2 NVEs of L2 overlay network to reach 514 the other end Custom Bridge, L2 overlay network maybe need to 515 support to overlay this kind of LACP frame between L2 NVEs. How the 516 L2 overlay network support LACP frame of 01-80-C2-00-00-03 is TBD. 518 4.4. Link OAM 520 Lin OAM defined is defined in [IEEE 802.3ah], as mechanisms for 521 monitoring and troubleshooting Ethernet access links. Specifically 522 it defines tools for discovery, remote failure indication, remote 523 and local loopbacks and status and performance monitoring. 525 The Link OAM frames using L2CP MAC DA of 01-80-C2-00-00-02 are 526 peered or discarded by every node, so this kind of frame will not be 527 overlaid across the L2 overlay network. 529 4.5. Port Authentication 531 [IEEE 802.1X] is an IEEE Standard for Port-based Network Access 532 Control (PNAC). It is part of the IEEE 802.1 group of networking 533 protocols. It provides an authentication mechanism to devices 534 wishing to attach to a LAN or WLAN. 536 Whether or not the L2 overlay network needs to overlay this L2CP 537 frames is TBD. 539 4.6. E-LMI 541 Ethernet Local Management Interface (E-LMI) [MEF-16] is a protocol 542 between the customer edge (CE) device and the provider edge (PE) 543 device. It runs only on the PE-CE UNI link and notifies the CE of 544 connectivity status and configuration parameters of Ethernet 545 services available on the CE port. E-LMI interoperates with an OAM 546 protocol, such as Connectivity Fault Management (CFM), that runs 547 within the provider network to collect OAM status. CFM runs at the 548 provider maintenance level (UPE to UPE with inward-facing MEPs at 549 the UNI). E-LMI relies on the OAM Ethernet Infrastructure (EI) to 550 interwork with CFM for end-to-end status of Ethernet virtual 551 connections (EVCs) across CFM domains. 553 The LLDP frames using L2CP MAC DA of 01-80-C2-00-00-07 are peered or 554 discarded by every node except for the Two Port MAC Relay (TPMR) 555 bridge, so this kind of frame will not be overlaid across the L2 556 overlay network. 558 4.7. LLDP 560 The Link Layer Discovery Protocol (LLDP) is a vendor-neutral link 561 layer protocol in the Internet Protocol Suite used by network 562 devices for advertising their identity, capabilities, and neighbors 563 on an IEEE 802 local area network, principally wired Ethernet. The 564 protocol is formally referred to by the IEEE as Station and Media 565 Access Control Connectivity Discovery specified in standards 566 document [IEEE 802.1AB]. 568 The LLDP frames using L2CP MAC DA of 01-80-C2-00-00-0E are peered or 569 discarded by every node, so this kind of frame will not be overlaid 570 across the L2 overlay network. 572 4.8. PTP Peer Delay 574 PTP Peer Delay frame is specified in [IEEE 1588-2008] to carry PTP 575 peer time information. It uses L2CP MAC DA of 01-80-C2-00-00-0E and 576 peered or discarded by every node, so this kind of frame will not be 577 overlaid across the L2 overlay network. 579 4.9. ESMC 581 Ethernet Synchronization Messaging Channel (ESMC) is specified in 582 [ITU-T Rec. G.8264] for conveying clock information between 583 Synchronous Ethernet (SyncE) bridges. 585 The ESMC frames using L2CP MAC DA of 01-80-C2-00-00-02 are peered or 586 discarded by every node, so this kind of frame will not be overlaid 587 across the L2 overlay network. 589 4.10. GARP/MRP Block 591 Multiple Registration Protocol (MRP), which replaced Generic 592 Attribute Registration Protocol (GARP), is a generic registration 593 framework defined by the [IEEE 802.1ak] amendment to the [IEEE 594 802.1Q] standard. MRP allows bridges, switches or other similar 595 devices to be able to register and de-register attribute values, 596 such as VLAN identifiers and multicast group membership across a 597 large LAN. MRP operates at the Data Link Layer. 599 The block of L2CP MAC DA from 01-80-C2-00-00-20 to 01-80-C2-00-00-2F 600 is used for MRP protocol. Now, only 01-80-C2-00-00-20 is for 601 Multiple MAC Registration Protocol (MMRP) and 01-80-C2-00-00-21 is 602 for Multiple VLAN Registration Protocol (MVRP), other L2CP MAC DA of 603 the block are all reserved for future use. Protocol using one 604 address of this block is passed by all the intervening bridges that 605 does not participate in the protocol using this address, and peered 606 or discarded by the bridge that participate in the protocol at last. 607 In order to send the MRP frames to all related nodes (i.e., NVEs, 608 bridges, etc) in one L2 overlay network, the MRP frames may require 609 to be overlaid across the L2 overlay network. 611 5. L2CP Processing in L2GWs 613 For all L2CP protocols, several differences exist between L2 overlay 614 network and L2 bridge network on how to process them. As the 615 demarcation point between L2 overlay network and L2 bridge network, 616 L2GW keeps the same action to all L2CP frames as before at the L2 617 bridge network side on the one hand, but maybe processes some L2CP 618 frames differently at the L2 overlay network side on the other hand. 619 The following sub sections will describe the L2CP process in L2GW. 621 5.1. L2CP Frames Filtered (Peered or Discarded) in L2GW 623 Although xSTP protocols using Nearest Customer Bridge address of 01- 624 80-C2-00-00-00 indicate that it can be overlaid across L2 overlay 625 network, they still are not necessary for L2 overlay network because 626 L2 overlay network has its own mechanism to prevent bridge loops. So 627 xSTP frames will be filtered by the L2GW and not go into the L2 628 overlay network. 630 Based on the analysis of section 3.3, LACP/LAMP frames using IEEE 631 802 Slow Protocols of 01-80-C2-00-00-02 are not necessary for L2 632 overlay network. So, LACP/LAMP frames will be filtered by the L2GW 633 and not go into the L2 overlay network. ESMC frames using the same 634 MAC DA will also be filtered by L2GW. 636 For Link OAM frames, if OAM functions are necessary for the whole L2 637 network which interconnects L2 bridge network and L2 overlay network, 638 L2GW needs to support the interworking of OAM as well. This means 639 that L2GW should peer the Link OAM frames of L2 bridge network and 640 perform some actions between NVEs in L2 overlay network. The 641 detailed operation is TBD. 643 Other L2CP protocols that are filtered by L2GW and do not go into L2 644 overlay network include PAUSE, E-LMI, LLDP, PTP Peer Delay. The 645 basic reason is that they all require to be processed hop by hop in 646 L2 network strictly, but overlay network breaks this rule. 648 The action of ''filter'' can be ''peer'', or ''discard''. It depends on 649 the specific service requirement, i.e., does L2GW need to 650 participate in the L2CP protocol, etc. How to determine the specific 651 action is TBD. 653 5.2. L2CP Frames Passed through L2GW 655 Excepting for the aforementioned L2CP protocols filtered by L2GW, 656 the left L2CP protocols need to be passed through L2GW. They include: 658 LACP/LAMP frames using IEEE 802 Slow Protocols of 01-80-C2-00-00- 659 00; 661 GARP/MRP series protocols (i.e., MMRP, MVRP) using the MAC DA 662 block of 01-80-C2-00-00-20 through 01-80-C2-00-00-2F. 664 All these kinds of L2CP frames are passed through L2GW and traverse 665 across the L2 overlay network and L2 bridge network to arrive the 666 bridges that participate in the L2CP protocols. For MRP protocols, 667 another necessary operation of L2GW is to use the pre-provisioned 668 VLAN to virtual network instance (VNI) mappings in NVE locally or by 669 getting from NVA to map these MRP frames into corresponding VNIs. 671 6. Other Interworking Cases 673 There are other L2 bridge network technologies that use L2 Control 674 Plane protocols such as Provider Bridge [IEEE802.1AD] or Provider 675 Backbone Bridge [PBB] [IEEE802.1AH]. The use case of L2 Overlay 676 Network interworking with these types of bridge networks is for the 677 further study. 679 Note that VPLS [RFC4761] [RFC4762], EVPN [EVPN], Shortest Path 680 Bridging [IEEE SPB] and TRILL [RFC6325] are also technologies for L2 681 private network implementation. These technologies rely on the 682 control plane protocol and aim for service provider network. SDN 683 controller interworking with such control plane protocol will be 684 addressed in separate draft. 686 7. Security Considerations 688 TBD. 690 8. IANA Considerations 692 The document does not require any IANA action. 694 9. References 696 9.1. Normative References 698 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 699 Requirement Levels", BCP 14, RFC2119, March 1997. 701 [RFC4761] Kompella, K. and Rekhter, Y. (Editors), "Virtual Private 702 LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 703 4761, January 2007 705 [RFC4762] Lasserre, M. and Kompella, V. (Editors), "Virtual Private 706 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 707 Signaling", RFC 4762, January 2007. 709 [RFC6325] Perlman, R., "RBridges: Base Protocol Specification", 710 July 2011. 712 9.2. Informative References 714 [NVO3ARCH] Black, D, Narten, T., et al, "An Architecture for Overlay 715 Networks (NVO3)", draft-narten-nvo3-arch-01, work in progress 717 [NVO3FRWK] LASSERRE, M., Motin, T., et al, "Framework for DC Network 718 Virtualization", draft-ietf-nvo3-framework-07, work in progress. 720 [NVGRE] Sridharan, M., et al, "NVGRE: Network Virtualization using 721 Generic Routing Encapsulation", draft-sridharan-virtualization- 722 nvgre-03, work in progress 724 [VXLAN] Mahalingam, M., Dutt, D., etc, "VXLAN: A Framework for 725 Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", 726 draft-mahalingam-dutt-dcops-vxlan-05.txt, work in progress 728 [EVPN] Sajassi, A. and R. Aggarwal, "BGP MPLS Based Ethernet VPN", 729 draft-ietf-l2vpn-evpn-07, May 2014 731 [EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for 732 Ethernet VPN", RFC7209 734 [EVPN-MHN] Weiguo, Hao, Yizhou, Li, et al, "Multi-homed network in 735 EVPN", draft-hao-l2vpn-evpn-mhn-00, work in progress 737 [802.1Q] IEEE, "Media Access Control (MAC) Bridges and Virtual 738 Bridged Local Area Networks", IEEE Std 802.1Q-2011, August, 2011. 740 [IEEE 802.3-2005] "Part 3: Carrier sense multiple access with 741 collision detection (CSMA/CD) access method and physical layer 742 specifications" 744 [IEEE 802.1AXbk-2012] "IEEE Standard for Local and metropolitan area 745 networks--Link Aggregation Amendment 1: Protocol Addressing" 747 [IEEE 802.3ah] "IEEE Standard for Information technology--Local and 748 metropolitan area networks--Part 3: CSMA/CD Access Method and 749 Physical Layer Specifications Amendment: Media Access Control 750 Parameters, Physical Layers, and Management Parameters for 751 Subscriber Access Networks" 753 [IEEE 802.1X] "IEEE Standard for Local and metropolitan Area 754 Networks. Port-based Network Access Control" 756 [IEEE 802.1AB] "IEEE Standard for Station and Media Access Control, 757 Connectivity Discovery" 759 [MEF-16] Metro Ethernet Forum, MEF 16, Ethernet Local Management 760 Interface (E-LMI), January 2006. 762 [IEEE 1588-2008] "IEEE Standard for a Precision Clock 763 Synchronization Protocol for Networked Measurement and Control 764 Systems" 766 [IEEE 802.1ak] "IEEE Standard for Local and metropolitan Area 767 Networks - Virtual Bridged Local Area Networks, Amendment 7: 768 Multiple Registration Protocol" 770 [IEEE 802.1AD], "Virtual Bridged Local Area Networks - Amendment 4: 771 Provider Bridges", 2005 773 [PBB] Clauses 25 and 26 of "IEEE Standard for Local and metropolitan 774 area networks - Media Access Control (MAC) Bridges and Virtual 775 Bridged Local Area Networks", IEEE Std 802.1Q, 2013. 777 [IEEE802.1AH] IEEE Draft P802.1ah/D4.2 "Virtual Bridged Local Area 778 Networks, Amendment 6: Provider Backbone Bridges", 2008 780 [IEEE SPB] "IEEE standard for local and metropolitan area networks: 781 Media access control (MAC) bridges and virtual bridged local area 782 networks -- Amendment 20: Shortest path bridging", IEEE 802.1aq, 783 June 2012. 785 [ITU-T Rec. G.8264] "Distribution of Timing Through Packet Networks" 787 Authors' Addresses 789 Liang Xia (Frank) 790 Huawei Technologies 792 Email: frank.xialiang@huawei.com 794 Lucy Yong 795 Huawei Technologies, USA 797 Email: lucy.yong@huawei.com 799 Weiguo Hao 800 Huawei Technologies 801 101 Software Avenue, 802 Nanjing 210012 803 China 805 Phone: +86-25-56623144 806 EMail: haoweiguo@huawei.com 808 Anoop Ghanwani 809 Dell 810 Email: anoop@alumni.duke.edu 812 Ram (Ramki) Krishnan 813 Brocade 815 Email: ramk@brocade.com