1 / 10

draft-ietf-l2vpn-evpn- 04. txt

This document proposes enhancements to the Ethernet VPN (EVPN) protocol, including the addition of sticky MAC addresses, support for MAC mobility, and improved frame ordering. It also clarifies terminology and addresses interoperability with single-homing PEs.

hazelip
Download Presentation

draft-ietf-l2vpn-evpn- 04. txt

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. draft-ietf-l2vpn-evpn-04.txt A. Sajassi (Cisco), R. Aggarwal (Arktan), W. Henderickx (ALU), N. Bitar (Verizon), A. Issac (Bloomberg), J. Uttaro (ATT), F. Balus (ALU), R. Shekhar (Juniper), J. Drake (Juniper), S. Boutros (Cisco), K. Patel (Cisco), S. Salam (Cisco) IETF 87, July 2013 Berlin

  2. Changes from Rev03 • Three categories • Added some sections • Removed some sections • Modified some sections for better clarifications

  3. draft-ietf-l2vpn-evpn-04.txtAdditions (1) • ES route • Added originating router’s IP address for scenarios where ES is multi-homed across different ASes • Sticky MAC address & MAC mobility – 16.2 • Added a flag to ESI Ext. Community to indicate that sticky/static MAC • Described the corresponding procedure in 16.2

  4. draft-ietf-l2vpn-evpn-04.txtAdditions (2) • Interoperability with Single-homing PEs – 9.6 • Single-homing PEs need to support the following Multi-homing procedures: • Procedures related to Ether AD route for fast convergence, aliasing, and backup path

  5. draft-ietf-l2vpn-evpn-04.txtAdditions (3) • Frame Ordering – new sec. 19 • If the most significant nible of most significant byte of destination MAC address happens to be 0x4 or 0x6, then the Ethernet frame can be misinterpreted as an IPv4 or IPv6 packet • P nodes can load-balance different packets of the same flow onto different ECMP paths • In order to avoid such issues, a control world is mandated before Ethernet Header

  6. draft-ietf-l2vpn-evpn-04.txtRemoval • Multicast using MP2MP LSPs – sec. 17.3 • Multicast for Selective Trees – sec. 17.3.2. • Multicast with Explicit Tracking – sec. 17.4 • LACP State Synchronization – old sec. 19 • Local repair – sec. 18.2.1

  7. draft-ietf-l2vpn-evpn-04.txtChanges (1) • E-VPN -> EVPN • EVI: sometimes was used as EVPN instance and some other times as MAC VRF. Clarified definition of EVI and introduced a new term MAC-VRF • EVI: An EVPN instance spanning across the PEs participating in that VPN • MAC VRF: A Virtual Routing and Forwarding table for MAC addresses on a PE for an EVI • Update the document for the proper use of the terms EVI and MAC-VRF • Clarified relationship between EVI, VLANs, and VIDs

  8. draft-ietf-l2vpn-evpn-04.txtChanges (2) • Clarified relationship between MAC-VRF, Bridge Domains (BDs), and different service types (VLAN-based, VLAN Bundle, and VLAN-Aware Bundle) • Clarified prefix versus address (for both MAC and IP) in EVPN MAC route – sec. 10.2.1 • MPLS label field is a single label in EVPN MAC route – sec. 10.2.1. • Expended the description of default GW for inter-subnet forwarding in sec. 11.1

  9. draft-ietf-l2vpn-evpn-04.txtChanges (3) • Added a paragraph in MAC mobility (sec. 16) to explain why in case of MAC mobility among single-home CEs, PEs don’t need to compare ESIs.

  10. Next Step • As can be seen lots of cleanups have been done to get ready for WG last call • It is ready !

More Related