draft-ietf-l2vpn-evpn-08.txt   draft-ietf-l2vpn-evpn-09.txt 
skipping to change at page 1, line 18 skipping to change at page 1, line 18
Juniper Networks Juniper Networks
N. Bitar N. Bitar
W. Henderickx Verizon W. Henderickx Verizon
Alcatel-Lucent Alcatel-Lucent
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
J. Uttaro J. Uttaro
AT&T AT&T
Expires: March 12, 2015 September 12, 2014 Expires: April 2, 2015 October 2, 2014
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-08 draft-ietf-l2vpn-evpn-09
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 3, line 15 skipping to change at page 3, line 15
8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 20 8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 20
8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 21 8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 21
8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 21 8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 21
8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 22 8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 22
8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 23 8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 23
8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) 8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI)
Route . . . . . . . . . . . . . . . . . . . . . . . . . 24 Route . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 25 8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 25
8.6. Interoperability with Single-homing PEs . . . . . . . . . . 27 8.6. Interoperability with Single-homing PEs . . . . . . . . . . 27
9. Determining Reachability to Unicast MAC Addresses . . . . . . . 27 9. Determining Reachability to Unicast MAC Addresses . . . . . . . 27
9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 28
9.2. Remote learning . . . . . . . . . . . . . . . . . . . . . . 28 9.2. Remote learning . . . . . . . . . . . . . . . . . . . . . . 28
9.2.1. Constructing the BGP EVPN MAC/IP Address 9.2.1. Constructing the BGP EVPN MAC/IP Address
Advertisement . . . . . . . . . . . . . . . . . . . . . 28 Advertisement . . . . . . . . . . . . . . . . . . . . . 28
9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 30 9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 30
10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 32 10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 32
11. Handling of Multi-Destination Traffic . . . . . . . . . . . . 33 11. Handling of Multi-Destination Traffic . . . . . . . . . . . . 33
11.1. Construction of the Inclusive Multicast Ethernet Tag 11.1. Construction of the Inclusive Multicast Ethernet Tag
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 34
11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 34 11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 34
12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 35 12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 35
12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 36 12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 36
12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 36 12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 36
13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 36 13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 37
13.1. Forwarding packets received from a CE . . . . . . . . . . 37 13.1. Forwarding packets received from a CE . . . . . . . . . . 37
13.2. Forwarding packets received from a remote PE . . . . . . . 38 13.2. Forwarding packets received from a remote PE . . . . . . . 38
13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 38 13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 38
13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 38 13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 38
14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 38 14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 38
14.1. Load balancing of traffic from a PE to remote CEs . . . . 38 14.1. Load balancing of traffic from a PE to remote CEs . . . . 39
14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 39 14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 39
14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 39 14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 39
14.2. Load balancing of traffic between a PE and a local CE . . 41 14.2. Load balancing of traffic between a PE and a local CE . . 41
14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 41 14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 41
14.2.2. Control plane learning . . . . . . . . . . . . . . . . 41 14.2.2. Control plane learning . . . . . . . . . . . . . . . . 41
15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 41 15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 42
15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43 15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43
15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 44 15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 44
16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 44 16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 44
16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 44 16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 44
16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 44 16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 44
16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 45 16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 45
17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 45 17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.1. Transit Link and Node Failures between PEs . . . . . . . . 45 17.1. Transit Link and Node Failures between PEs . . . . . . . . 45
17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 45 17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 46
17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 46 17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 46
18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 46 18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 46
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
20. Security Considerations . . . . . . . . . . . . . . . . . . . 47 20. Security Considerations . . . . . . . . . . . . . . . . . . . 47
21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 49
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
23.1 Normative References . . . . . . . . . . . . . . . . . . . 49 23.1 Normative References . . . . . . . . . . . . . . . . . . . 49
23.2 Informative References . . . . . . . . . . . . . . . . . . 50 23.2 Informative References . . . . . . . . . . . . . . . . . . 50
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50 24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50
1. Introduction 1. Introduction
This document describes procedures for BGP MPLS based Ethernet VPNs This document describes procedures for BGP MPLS based Ethernet VPNs
(EVPN). The procedures described here are intended to meet the (EVPN). The procedures described here are intended to meet the
skipping to change at page 19, line 12 skipping to change at page 19, line 12
over the MPLS network. As such, in the absence of any fast protection over the MPLS network. As such, in the absence of any fast protection
mechanism, the network convergence time is a function of the number mechanism, the network convergence time is a function of the number
of MAC Advertisement routes that must be withdrawn by the PE of MAC Advertisement routes that must be withdrawn by the PE
encountering a failure. For highly scaled environments, this scheme encountering a failure. For highly scaled environments, this scheme
yields slow convergence. yields slow convergence.
To alleviate this, EVPN defines a mechanism to efficiently and To alleviate this, EVPN defines a mechanism to efficiently and
quickly signal, to remote PE nodes, the need to update their quickly signal, to remote PE nodes, the need to update their
forwarding tables upon the occurrence of a failure in connectivity to forwarding tables upon the occurrence of a failure in connectivity to
an Ethernet segment. This is done by having each PE advertise a set an Ethernet segment. This is done by having each PE advertise a set
of Ethernet A-D per Ethernet segment (per ES) routes for each locally of one or more Ethernet A-D per Ethernet segment (per ES) routes for
attached Ethernet segment (refer to section 8.2.1 below for details each locally attached Ethernet segment (refer to section 8.2.1 below
on how this route is constructed). Upon a failure in connectivity to for details on how these routes are constructed). The reason that a
the attached segment, the PE withdraws the corresponding Ethernet A-D PE may need to advertise more than one Ethernet A-D per ES route for
route. This triggers all PEs that receive the withdrawal to update a given ES is that the ES may be in a multiplicity of EVIs and the
their next-hop adjacencies for all MAC addresses associated with the RTs for all of these EVIs may not fit into a single route.
Ethernet segment in question. If no other PE had advertised an Advertising a set of Ethernet A-D per ES routes for the ES allows
Ethernet A-D route for the same segment, then the PE that received each route to contain a subset of the complete set of RTs.
the withdrawal simply invalidates the MAC entries for that segment.
Otherwise, the PE updates the next-hop adjacencies to point to the Upon a failure in connectivity to the attached segment, the PE
backup PE(s). withdraws the corresponding set of Ethernet A-D Per ES routes. This
triggers all PEs that receive the withdrawal to update their next-hop
adjacencies for all MAC addresses associated with the Ethernet
segment in question. If no other PE had advertised an Ethernet A-D
route for the same segment, then the PE that received the withdrawal
simply invalidates the MAC entries for that segment. Otherwise, the
PE updates the next-hop adjacencies to point to the backup PE(s).
8.2.1 Constructing the Ethernet A-D per Ethernet Segment (ES) Route 8.2.1 Constructing the Ethernet A-D per Ethernet Segment (ES) Route
This section describes the procedures used to construct the Ethernet This section describes the procedures used to construct the Ethernet
A-D per ES route, which is used for fast convergence (as discussed A-D per ES route, which is used for fast convergence (as discussed
above) and for advertising the ESI label used for split-horizon above) and for advertising the ESI label used for split-horizon
filtering (as discussed in section 8.3). Support of this route is filtering (as discussed in section 8.3). Support of this route is
REQUIRED. REQUIRED.
The Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value The Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value
skipping to change at page 48, line 40 skipping to change at page 48, line 45
MPLS labels be accepted only from valid interfaces. For a PE, valid MPLS labels be accepted only from valid interfaces. For a PE, valid
interfaces comprise links from other routers in the PE's own AS. For interfaces comprise links from other routers in the PE's own AS. For
an ASBR, valid interfaces comprise links from other routers in the an ASBR, valid interfaces comprise links from other routers in the
ASBR's own AS, and links from other ASBRs in ASes that have instances ASBR's own AS, and links from other ASBRs in ASes that have instances
of a given EVPN. It is especially important in the case of multi-AS of a given EVPN. It is especially important in the case of multi-AS
EVPN instances that one accept EVPN packets only from valid EVPN instances that one accept EVPN packets only from valid
interfaces. interfaces.
It is also important to help limit malicious traffic into a network It is also important to help limit malicious traffic into a network
for an imposter MAC address. The mechanism described in section 15.1, for an imposter MAC address. The mechanism described in section 15.1,
shows how duplicate MAC addresses can be detected and continous false shows how duplicate MAC addresses can be detected and continuous
MAC mobility can be prevented. The mechanism described in section false MAC mobility can be prevented. The mechanism described in
15.2, shows how MAC addresses can be pinned to a given Ethernet section 15.2 shows how MAC addresses can be pinned to a given
Segment, such that if they appear behind any other Ethernet Segments, Ethernet Segment, such that if they appear behind any other Ethernet
the traffic for those MAC addresses be prevented from entering the Segments, the traffic for those MAC addresses can be prevented from
EVPN network from the other Ethernet Segments. entering the EVPN network from the other Ethernet Segments.
21. Contributors 21. Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
individuals have also helped to shape this document: individuals have also helped to shape this document:
Keyur Patel Keyur Patel
Samer Salam Samer Salam
Sami Boutros Sami Boutros
Cisco Cisco
skipping to change at page 49, line 21 skipping to change at page 49, line 28
Florin Balus Florin Balus
Nuage Networks Nuage Networks
22. IANA Considerations 22. IANA Considerations
This document defines a new NLRI, called "EVPN", to be carried in BGP This document defines a new NLRI, called "EVPN", to be carried in BGP
using multiprotocol extensions. This NLRI uses the existing AFI of using multiprotocol extensions. This NLRI uses the existing AFI of
25 (L2VPN). IANA has assigned it a SAFI value of 70. 25 (L2VPN). IANA has assigned it a SAFI value of 70.
IANA allocated a new transitive extended community Type of 0x06 and IANA has allocated the following EVPN Extended Community sub-types
Sub-Type of 0x00 for EVPN MAC Mobility Extended Community. and this document is the only reference for them.
IANA allocated a new transitive extended community Type of 0x06 and 0x00 MAC Mobility [this document]
Sub-Type of 0x01 for EVPN ESI Label Extended Community. 0x01 ESI Label [this document]
0x02 ES-Import Route Target [this document]
IANA allocated a new transitive extended community Type of 0x06 and This document is creating a registry called "EVPN Route Types." New
Sub-Type of 0x02 for EVPN ES-Import Route Target. registrations will be made through the "RFC Required" procedure
defined in [RFC5226]. The registry has no maximum value. Initial
registrations are as follows:
For EVPN NLRI (with AFI=25, SAFI = 70), the following route types are 1 Ethernet Auto-Discovery [this document]
requested from IANA: 1 - Ethernet Auto-Discovery (A-D) route 2 MAC/IP Advertisement [this document]
2 - MAC/IP advertisement route 3 - Inclusive Multicast Ethernet 3 Inclusive Multicast Ethernet Tag [this document]
Tag Route 4 - Ethernet Segment Route 4 Ethernet Segment [this document]
23. References 23. References
23.1 Normative References 23.1 Normative References
[RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006 [RFC4364] "BGP/MPLS IP VPNs", Rosen, Rekhter, et. al., February 2006
[RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service [RFC4761] Kompella, K. and Y. Rekhter, "Virtual Private LAN Service
(VPLS) Using BGP for Auto-Discovery and Signaling", RFC (VPLS) Using BGP for Auto-Discovery and Signaling", RFC
4761, January 2007. 4761, January 2007.
skipping to change at page 50, line 30 skipping to change at page 50, line 38
Border Gateway Protocol/MultiProtocol Label Switching Border Gateway Protocol/MultiProtocol Label Switching
(BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks
(VPNs)", RFC 4684, November 2006. (VPNs)", RFC 4684, November 2006.
[RFC6790] K. Kompella et. al, "The Use of Entropy Labels in MPLS [RFC6790] K. Kompella et. al, "The Use of Entropy Labels in MPLS
Forwarding", RFC 6790, November 2012. Forwarding", RFC 6790, November 2012.
[RFC4385] S. Bryant et. al, "PWE3 Control Word for Use over an MPLS [RFC4385] S. Bryant et. al, "PWE3 Control Word for Use over an MPLS
PSN", RFC 4385, February 2006 PSN", RFC 4385, February 2006
[RFC5226] T. Narten et. al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008
24. Author's Address 24. Author's Address
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
Rahul Aggarwal Rahul Aggarwal
Email: raggarwa_1@yahoo.com Email: raggarwa_1@yahoo.com
Nabil Bitar Nabil Bitar
Verizon Communications Verizon Communications
Email : nabil.n.bitar@verizon.com Email : nabil.n.bitar@verizon.com
Aldrin Isaac Aldrin Isaac
Bloomberg Bloomberg
Email: aisaac71@bloomberg.net Email: aisaac71@bloomberg.net
James Uttaro James Uttaro
AT&T AT&T
 End of changes. 16 change blocks. 
36 lines changed or deleted 47 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/