draft-ietf-l2vpn-evpn-09.txt   draft-ietf-l2vpn-evpn-10.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: April 2, 2015 October 2, 2014 Expires: April 3, 2015 October 3, 2014
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-09 draft-ietf-l2vpn-evpn-10
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 1, line 46 skipping to change at page 1, line 46
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
Copyright and License Notice Copyright and License Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Abstract Abstract
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
requirements specified in [EVPN-REQ]. requirements specified in RFC7209 - Requirements for Ethernet VPN.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Specification of requirements . . . . . . . . . . . . . . . . . 5 2. Specification of requirements . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. BGP MPLS Based EVPN Overview . . . . . . . . . . . . . . . . . 6 4. BGP MPLS Based EVPN Overview . . . . . . . . . . . . . . . . . 6
5. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7 5. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7
6. Ethernet Tag ID . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Ethernet Tag ID . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 11 6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 11
skipping to change at page 2, line 50 skipping to change at page 2, line 50
7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 16 7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 16
7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 16 7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 16
7.8 Default Gateway Extended Community . . . . . . . . . . . . . 17 7.8 Default Gateway Extended Community . . . . . . . . . . . . . 17
7.9 Route Distinguisher Assignment per EVI . . . . . . . . . . . 17 7.9 Route Distinguisher Assignment per EVI . . . . . . . . . . . 17
7.10 Route Targets . . . . . . . . . . . . . . . . . . . . . . . 17 7.10 Route Targets . . . . . . . . . . . . . . . . . . . . . . . 17
7.10.1 Auto-Derivation from the Ethernet Tag ID . . . . . . . 17 7.10.1 Auto-Derivation from the Ethernet Tag ID . . . . . . . 17
8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 18 8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 18
8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 18 8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 18
8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 18 8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 18
8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 18 8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 18
8.2.1 Constructing the Ethernet A-D per Ethernet Segment 8.2.1 Constructing Ethernet A-D per Ethernet Segment Route . . 19
(ES) Route . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 20 8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 20
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 Ethernet A-D per EVPN Instance 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 . . . . . . . . . . . . . . . . . . . . . . 28 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 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. Constructing 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 . . . . . . . . . . . . . . . . . . 37 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
skipping to change at page 5, line 9 skipping to change at page 5, line 9
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
requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for requirements specified in [RFC7209]. Please refer to [RFC7209] for
the detailed requirements and motivation. EVPN requires extensions to the detailed requirements and motivation. EVPN requires extensions to
existing IP/MPLS protocols as described in this document. In addition existing IP/MPLS protocols as described in this document. In addition
to these extensions EVPN uses several building blocks from existing to these extensions EVPN uses several building blocks from existing
MPLS technologies. MPLS technologies.
2. Specification of requirements 2. Specification of requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
skipping to change at page 8, line 29 skipping to change at page 8, line 29
specifies the format of the remaining nine octets (ESI Value). The specifies the format of the remaining nine octets (ESI Value). The
following 6 ESI types can be used: following 6 ESI types can be used:
- Type 0 (T=0x00) - This type indicates an arbitrary nine-octet ESI - Type 0 (T=0x00) - This type indicates an arbitrary nine-octet ESI
value, which is managed and configured by the operator. value, which is managed and configured by the operator.
- Type 1 (T=0x01) - When IEEE 802.1AX LACP is used between the PEs - Type 1 (T=0x01) - When IEEE 802.1AX LACP is used between the PEs
and CEs, this ESI type indicates an auto-generated ESI value and CEs, this ESI type indicates an auto-generated ESI value
determined from LACP by concatenating the following parameters: determined from LACP by concatenating the following parameters:
+ CE LACP six octets System MAC address. The CE LACP System MAC + CE LACP six octets System MAC address. The CE LACP System MAC
address MUST be encoded in the high order six octets of the ESI address MUST be encoded in the high order six octets of the ESI
Value field. Value field.
+ CE LACP two octets Port Key. The CE LACP port key MUST be + CE LACP two octets Port Key. The CE LACP port key MUST be
encoded in the two octets next to the System MAC address. encoded in the two octets next to the System MAC address.
+ The remaining octet will be set to 0x00. + The remaining octet will be set to 0x00.
As far as the CE is concerned, it would treat the multiple PEs As far as the CE is concerned, it would treat the multiple PEs
that it is connected to as the same switch. This allows the CE that it is connected to as the same switch. This allows the CE
to aggregate links that are attached to different PEs in the to aggregate links that are attached to different PEs in the
same bundle. same bundle.
This mechanism could be used only if it produces ESIs that satisfy This mechanism could be used only if it produces ESIs that
the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 2 (T=0x02) - This type is used in the case of indirectly - Type 2 (T=0x02) - This type is used in the case of indirectly
connected hosts via a bridged LAN between the CEs and the PEs. The connected hosts via a bridged LAN between the CEs and the PEs. The
ESI Value is auto-generated and determined based on the Layer 2 ESI Value is auto-generated and determined based on the Layer 2
bridge protocol as follows: If MST is used in the bridged LAN then bridge protocol as follows: If MST is used in the bridged LAN then
the value of the ESI is derived by listening to BPDUs on the Ethernet the value of the ESI is derived by listening to BPDUs on the Ethernet
segment. To achieve this the PE is not required to run MST. However segment. To achieve this the PE is not required to run MST. However
the PE must learn the Root Bridge MAC address and Bridge Priority of the PE must learn the Root Bridge MAC address and Bridge Priority of
the root of the Internal Spanning Tree (IST) by listening to the the root of the Internal Spanning Tree (IST) by listening to the
BPDUs. The ESI Value is constructed as follows: BPDUs. The ESI Value is constructed as follows:
+ Root Bridge six octets MAC address. The Root Bridge MAC + Root Bridge six octets MAC address. The Root Bridge MAC
address MUST be encoded in the high order six octets of the address MUST be encoded in the high order six octets of the
ESI Value field. ESI Value field.
+ Root Bridge two octets Priority. The CE Root Bridge Priority + Root Bridge two octets Priority. The CE Root Bridge Priority
MUST be encoded in the two octets next to the Root Bridge MUST be encoded in the two octets next to the Root Bridge
MAC address. MAC address.
+ The remaining octet will be set to 0x00. + The remaining octet will be set to 0x00.
This mechanism could be used only if it produces ESIs that This mechanism could be used only if it produces ESIs that
satisfy the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 3 (T=0x03) - This type indicates a MAC-based ESI Value that - Type 3 (T=0x03) - This type indicates a MAC-based ESI Value that
can be auto-generated or configured by the operator. The ESI Value is can be auto-generated or configured by the operator. The ESI Value is
constructed as follows: constructed as follows:
+ System MAC address (six octets). The PE MAC address MUST + System MAC address (six octets). The PE MAC address MUST
be encoded in the high order six octets of the ESI Value field. be encoded in the high order six octets of the ESI Value field.
+ Local Discriminator value (three octets). The Local + Local Discriminator value (three octets). The Local
Discriminator MUST be encoded in the low order three octets Discriminator MUST be encoded in the low order three octets
of the ESI Value. of the ESI Value.
This mechanism could be used only if it produces ESIs that This mechanism could be used only if it produces ESIs that
satisfy the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 4 (T=0x04) - This type indicates a router-ID ESI Value that - Type 4 (T=0x04) - This type indicates a router-ID ESI Value that
can be auto-generated or configured by the operator. The ESI Value is can be auto-generated or configured by the operator. The ESI Value is
constructed as follows: constructed as follows:
+ Router ID (four octets). The system router ID MUST be encoded in + Router ID (four octets). The system router ID MUST be encoded
the high order four octets of the ESI Value field. in the high order four octets of the ESI Value field.
+ Local Discriminator value (four octets). The Local + Local Discriminator value (four octets). The Local
Discriminator MUST be encoded in the four octets next to the Discriminator MUST be encoded in the four octets next to the
IP address. IP address.
+ The low order octet of the ESI Value will be set to 0x00. + The low order octet of the ESI Value will be set to 0x00.
This mechanism could be used only if it produces ESIs that This mechanism could be used only if it produces ESIs that
satisfy the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 5 (T=0x05) - This type indicates an AS-based ESI Value that - Type 5 (T=0x05) - This type indicates an AS-based ESI Value that
can be auto-generated or configured by the operator. The ESI Value is can be auto-generated or configured by the operator. The ESI Value is
constructed as follows: constructed as follows:
+ AS number (four octets). This is an AS number owned by the + AS number (four octets). This is an AS number owned by the
system and MUST be encoded in the high order four octets of the system and MUST be encoded in the high order four octets of the
ESI Value field. If a two-octet AS number is used, the high order ESI Value field. If a two-octet AS number is used, the high
extra two octets will be 0x0000. order extra two octets will be 0x0000.
+ Local Discriminator value (four octets). The Local Discriminator + Local Discriminator value (four octets). The Local
MUST be encoded in the four octets next to the AS number. Discriminator MUST be encoded in the four octets next to
the AS number.
+ The low order octet of the ESI Value will be set to 0x00. + The low order octet of the ESI Value will be set to 0x00.
This mechanism could be used only if it produces ESIs that satisfy This mechanism could be used only if it produces ESIs that
the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
6. Ethernet Tag ID 6. Ethernet Tag ID
An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a
24-bit identifier that identifies a particular broadcast domain 24-bit identifier that identifies a particular broadcast domain
(e.g., a VLAN) in an EVPN Instance. The 12-bit identifier is called (e.g., a VLAN) in an EVPN Instance. The 12-bit identifier is called
VLAN ID (VID). An EVPN Instance consists of one or more broadcast VLAN ID (VID). An EVPN Instance consists of one or more broadcast
domains (one or more VLANs). VLANs are assigned to a given EVPN domains (one or more VLANs). VLANs are assigned to a given EVPN
Instance by the provider of the EVPN service. A given VLAN can itself Instance by the provider of the EVPN service. A given VLAN can itself
be represented by multiple VLAN IDs (VIDs). In such cases, the PEs be represented by multiple VLAN IDs (VIDs). In such cases, the PEs
skipping to change at page 10, line 46 skipping to change at page 10, line 47
scenarios guarantee uniqueness of VIDs across all EVPN instances; scenarios guarantee uniqueness of VIDs across all EVPN instances;
all points of attachment for a given EVPN instance use the same VID all points of attachment for a given EVPN instance use the same VID
and no other EVPN instances use that VID. This allows the RT(s) for and no other EVPN instances use that VID. This allows the RT(s) for
each EVPN instance to be derived automatically from the corresponding each EVPN instance to be derived automatically from the corresponding
VID, as described in section 7.10.1. VID, as described in section 7.10.1.
The following subsections discuss the relationship between broadcast The following subsections discuss the relationship between broadcast
domains (e.g., VLANs), Ethernet Tag IDs (e.g., VIDs), and MAC-VRFs as domains (e.g., VLANs), Ethernet Tag IDs (e.g., VIDs), and MAC-VRFs as
well as the setting of the Ethernet Tag ID, in the various EVPN BGP well as the setting of the Ethernet Tag ID, in the various EVPN BGP
routes (defined in section 8), for the different types of service routes (defined in section 8), for the different types of service
interfaces described in [EVPN-REQ]. interfaces described in [RFC7209].
The following value of Ethernet Tag ID is reserved: The following value of Ethernet Tag ID is reserved:
- Ethernet Tag ID {0xFFFFFFFF} is known as MAX-ET - Ethernet Tag ID {0xFFFFFFFF} is known as MAX-ET
6.1 VLAN Based Service Interface 6.1 VLAN Based Service Interface
With this service interface, an EVPN instance consists of only a With this service interface, an EVPN instance consists of only a
single broadcast domain (e.g., a single VLAN). Therefore, there is a single broadcast domain (e.g., a single VLAN). Therefore, there is a
one to one mapping between a VID on this interface and a MAC-VRF. one to one mapping between a VID on this interface and a MAC-VRF.
skipping to change at page 18, line 10 skipping to change at page 18, line 10
7.10.1 Auto-Derivation from the Ethernet Tag ID 7.10.1 Auto-Derivation from the Ethernet Tag ID
For the "Unique VLAN EVPN" scenario, it is highly desirable to auto- For the "Unique VLAN EVPN" scenario, it is highly desirable to auto-
derive the RT from the Ethernet Tag ID (VLAN ID) for that EVPN derive the RT from the Ethernet Tag ID (VLAN ID) for that EVPN
instance. The following is the procedure for performing such auto- instance. The following is the procedure for performing such auto-
derivation. derivation.
+ The Global Administrator field of the RT MUST be set + The Global Administrator field of the RT MUST be set
to the Autonomous System (AS) number that the PE is to the Autonomous System (AS) number that the PE is
associated with. associated with.
+ The 12-bit VLAN ID MUST be encoded in the lowest 12 bits of + The 12-bit VLAN ID MUST be encoded in the lowest 12 bits of
the Local Administrator field. the Local Administrator field.
8. Multi-homing Functions 8. Multi-homing Functions
This section discusses the functions, procedures and associated BGP This section discusses the functions, procedures and associated BGP
routes used to support multi-homing in EVPN. This covers both multi- routes used to support multi-homing in EVPN. This covers both multi-
homed device (MHD) as well as multi-homed network (MHN) scenarios. homed device (MHD) as well as multi-homed network (MHN) scenarios.
skipping to change at page 19, line 30 skipping to change at page 19, line 30
Upon a failure in connectivity to the attached segment, the PE Upon a failure in connectivity to the attached segment, the PE
withdraws the corresponding set of Ethernet A-D Per ES routes. This withdraws the corresponding set of Ethernet A-D Per ES routes. This
triggers all PEs that receive the withdrawal to update their next-hop triggers all PEs that receive the withdrawal to update their next-hop
adjacencies for all MAC addresses associated with the Ethernet adjacencies for all MAC addresses associated with the Ethernet
segment in question. If no other PE had advertised an Ethernet A-D 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 route for the same segment, then the PE that received the withdrawal
simply invalidates the MAC entries for that segment. Otherwise, the simply invalidates the MAC entries for that segment. Otherwise, the
PE updates the next-hop adjacencies to point to the backup PE(s). 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 Ethernet A-D per Ethernet Segment 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
field comprises an IP address of the PE (typically, the loopback field comprises an IP address of the PE (typically, the loopback
address) followed by a number unique to the PE. address) followed by a number unique to the PE.
skipping to change at page 24, line 26 skipping to change at page 24, line 26
Active redundancy mode. In this case a PE also advertises that it Active redundancy mode. In this case a PE also advertises that it
has reachability to a give EVI/ES using same combination of Ethernet has reachability to a give EVI/ES using same combination of Ethernet
A-D per EVI route and Ethernet A-D per ES route as above, but with A-D per EVI route and Ethernet A-D per ES route as above, but with
the 'Single-Active' bit in the flags of the ESI Label Extended the 'Single-Active' bit in the flags of the ESI Label Extended
Community set to 1. A remote PE that receives a MAC advertisement Community set to 1. A remote PE that receives a MAC advertisement
route with non-reserved ESI SHOULD consider the advertised MAC route with non-reserved ESI SHOULD consider the advertised MAC
address to be reachable via any PE that has advertised this address to be reachable via any PE that has advertised this
combination of Ethernet A-D routes and it SHOULD install a backup- combination of Ethernet A-D routes and it SHOULD install a backup-
path for that MAC address. path for that MAC address.
8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route 8.4.1 Constructing Ethernet A-D per EVPN Instance Route
This section describes the procedures used to construct the Ethernet This section describes the procedures used to construct the Ethernet
A-D per EVPN Instance (EVI) route, which is used for aliasing (as A-D per EVPN Instance (EVI) route, which is used for aliasing (as
discussed above). Support of this route is OPTIONAL. discussed above). Support of this route is OPTIONAL.
Route-Distinguisher (RD) MUST be set to the RD of the EVI that is Route-Distinguisher (RD) MUST be set to the RD of the EVI that is
advertising the NLRI per section 7.9. advertising the NLRI per section 7.9.
The Ethernet Segment Identifier MUST be a ten octet entity as The Ethernet Segment Identifier MUST be a ten octet entity as
described in section "Ethernet Segment Identifier". The Ethernet A-D described in section "Ethernet Segment Identifier". The Ethernet A-D
skipping to change at page 28, line 44 skipping to change at page 28, line 44
addresses that belong to or are behind CEs connected to other PEs addresses that belong to or are behind CEs connected to other PEs
i.e. to remote CEs or hosts behind remote CEs. We call such MAC i.e. to remote CEs or hosts behind remote CEs. We call such MAC
addresses "remote" MAC addresses. addresses "remote" MAC addresses.
This document requires a PE to learn remote MAC addresses in the This document requires a PE to learn remote MAC addresses in the
control plane. In order to achieve this, each PE advertises the MAC control plane. In order to achieve this, each PE advertises the MAC
addresses it learns from its locally attached CEs in the control addresses it learns from its locally attached CEs in the control
plane, to all the other PEs in that EVPN instance, using MP-BGP and plane, to all the other PEs in that EVPN instance, using MP-BGP and
specifically the MAC Advertisement route. specifically the MAC Advertisement route.
9.2.1. Constructing the BGP EVPN MAC/IP Address Advertisement 9.2.1. Constructing MAC/IP Address Advertisement
BGP is extended to advertise these MAC addresses using the MAC/IP BGP is extended to advertise these MAC addresses using the MAC/IP
Advertisement route type in the EVPN NLRI. Advertisement route type in the EVPN NLRI.
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be the RD of the EVI that is advertising the NLRI. The
procedures for setting the RD for a given EVI are described in procedures for setting the RD for a given EVI are described in
section 7.9. section 7.9.
The Ethernet Segment Identifier is set to the ten octet ESI described The Ethernet Segment Identifier is set to the ten octet ESI described
in section "Ethernet Segment". in section "Ethernet Segment".
skipping to change at page 31, line 28 skipping to change at page 31, line 28
T2- If after T1, PE1 withdraws its set of Ethernet A-D per ES routes, T2- If after T1, PE1 withdraws its set of Ethernet A-D per ES routes,
then PE3 forwards traffic destined to M1 to PE2 only. then PE3 forwards traffic destined to M1 to PE2 only.
T2'- If after T1, PE2 withdraws its set of Ethernet A-D per ES T2'- If after T1, PE2 withdraws its set of Ethernet A-D per ES
routes, then PE3 forwards traffic destined to M1 to PE1 only. routes, then PE3 forwards traffic destined to M1 to PE1 only.
T2''- If after T1, PE1 withdraws its MAC Advertisement route, then T2''- If after T1, PE1 withdraws its MAC Advertisement route, then
PE3 treats traffic to M1 as unknown unicast. PE3 treats traffic to M1 as unknown unicast.
T3- PE2 also advertises a MAC route for M1 and then PE1 withdraws its T3- PE2 also advertises a MAC route for M1 and then PE1 withdraws its
MAC route for M1. PE3 continues forwarding traffic destined to M1 MAC route for M1. PE3 continues forwarding traffic destined to M1 to
to both PE1 and PE2. In other words, despite M1 withdrawal by PE1, both PE1 and PE2. In other words, despite M1 withdrawal by PE1, PE3
PE3 forwards the traffic destined to M1 to both PE1 and PE2. This is forwards the traffic destined to M1 to both PE1 and PE2. This is
because a flow from the CE, resulting in M1 traffic getting hashed to because a flow from the CE, resulting in M1 traffic getting hashed to
PE1, can get terminated resulting in M1 to aged out in PE1; however, PE1, can get terminated resulting in M1 to aged out in PE1; however,
M1 can be reachable by both PE1 and PE2. M1 can be reachable by both PE1 and PE2.
10. ARP and ND 10. ARP and ND
The IP address field in the MAC advertisement route may optionally The IP address field in the MAC advertisement route may optionally
carry one of the IP addresses associated with the MAC address. This carry one of the IP addresses associated with the MAC address. This
provides an option which can be used to minimize the flooding of ARP provides an option which can be used to minimize the flooding of ARP
or Neighbor Discovery (ND) messages over the MPLS network and to or Neighbor Discovery (ND) messages over the MPLS network and to
skipping to change at page 34, line 15 skipping to change at page 34, line 15
The PEs in a particular EVPN instance may use ingress replication, The PEs in a particular EVPN instance may use ingress replication,
P2MP LSPs or MP2MP LSPs to send unknown unicast, broadcast or P2MP LSPs or MP2MP LSPs to send unknown unicast, broadcast or
multicast traffic to other PEs. multicast traffic to other PEs.
Each PE MUST advertise an "Inclusive Multicast Ethernet Tag Route" to Each PE MUST advertise an "Inclusive Multicast Ethernet Tag Route" to
enable the above. The following subsection provides the procedures to enable the above. The following subsection provides the procedures to
construct the Inclusive Multicast Ethernet Tag route. Subsequent construct the Inclusive Multicast Ethernet Tag route. Subsequent
subsections describe in further detail its usage. subsections describe in further detail its usage.
11.1. Construction of the Inclusive Multicast Ethernet Tag Route 11.1. Constructing Inclusive Multicast Ethernet Tag Route
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be the RD of the EVI that is advertising the NLRI. The
procedures for setting the RD for a given EVPN instance on a PE are procedures for setting the RD for a given EVPN instance on a PE are
described in section 7.9. described in section 7.9.
The Ethernet Tag ID is the identifier of the Ethernet Tag. It may be The Ethernet Tag ID is the identifier of the Ethernet Tag. It may be
set to 0 or to a valid Ethernet Tag value. set to 0 or to a valid Ethernet Tag value.
The Originating Router's IP address MUST be set to an IP address of The Originating Router's IP address MUST be set to an IP address of
the PE. This address SHOULD be common for all the EVIs on the PE the PE. This address SHOULD be common for all the EVIs on the PE
skipping to change at page 36, line 36 skipping to change at page 36, line 36
instance to this particular PE. instance to this particular PE.
The PE that receives a packet with this particular MPLS label MUST The PE that receives a packet with this particular MPLS label MUST
treat the packet as a broadcast, multicast or unknown unicast packet. treat the packet as a broadcast, multicast or unknown unicast packet.
Further if the MAC address is a unicast MAC address, the PE MUST Further if the MAC address is a unicast MAC address, the PE MUST
treat the packet as an unknown unicast packet. treat the packet as an unknown unicast packet.
12.2. P2MP MPLS LSPs 12.2. P2MP MPLS LSPs
The procedures for using P2MP LSPs are very similar to VPLS The procedures for using P2MP LSPs are very similar to VPLS
procedures [VPLS-MCAST]. The P-Tunnel attribute used by a PE for procedures [RFC7117]. The P-Tunnel attribute used by a PE for sending
sending unknown unicast, broadcast or multicast traffic for a unknown unicast, broadcast or multicast traffic for a particular EVPN
particular EVPN instance is advertised in the Inclusive Ethernet Tag instance is advertised in the Inclusive Ethernet Tag Multicast route
Multicast route as described in section "Handling of Multi- as described in section "Handling of Multi-Destination Traffic".
Destination Traffic".
The P-Tunnel attribute specifies the P2MP LSP identifier. This is the The P-Tunnel attribute specifies the P2MP LSP identifier. This is the
equivalent of an Inclusive tree in [VPLS-MCAST]. Note that multiple equivalent of an Inclusive tree in [RFC7117]. Note that multiple
Ethernet Tags, which may be in different EVPN instances, may use the Ethernet Tags, which may be in different EVPN instances, may use the
same P2MP LSP, using upstream labels [VPLS-MCAST]. This is the same P2MP LSP, using upstream labels [RFC7117]. This is the
equivalent of an Aggregate Inclusive tree in [VPLS-MCAST]. When P2MP equivalent of an Aggregate Inclusive tree in [RFC7117]. When P2MP
LSPs are used for flooding unknown unicast traffic, packet re- LSPs are used for flooding unknown unicast traffic, packet re-
ordering is possible. ordering is possible.
The PE that receives a packet on the P2MP LSP specified in the PMSI The PE that receives a packet on the P2MP LSP specified in the PMSI
Tunnel Attribute MUST treat the packet as a broadcast, multicast or Tunnel Attribute MUST treat the packet as a broadcast, multicast or
unknown unicast packet. Further if the MAC address is a unicast MAC unknown unicast packet. Further if the MAC address is a unicast MAC
address, the PE MUST treat the packet as an unknown unicast packet. address, the PE MUST treat the packet as an unknown unicast packet.
13. Forwarding Unicast Packets 13. Forwarding Unicast Packets
skipping to change at page 45, line 4 skipping to change at page 45, line 4
broadcast packet must be sent to all the remote PEs. However a given broadcast packet must be sent to all the remote PEs. However a given
multicast packet for a multicast flow may be sent to only a subset of multicast packet for a multicast flow may be sent to only a subset of
the PEs. Specifically a given multicast flow may be sent to only the PEs. Specifically a given multicast flow may be sent to only
those PEs that have receivers that are interested in the multicast those PEs that have receivers that are interested in the multicast
flow. Determining which of the PEs have receivers for a given flow. Determining which of the PEs have receivers for a given
multicast flow is done using explicit tracking described below. multicast flow is done using explicit tracking described below.
16.2. P2MP LSPs 16.2. P2MP LSPs
A PE may use an "Inclusive" tree for sending an BUM packet. This A PE may use an "Inclusive" tree for sending an BUM packet. This
terminology is borrowed from [VPLS-MCAST]. terminology is borrowed from [RFC7117].
A variety of transport technologies may be used in the SP network. A variety of transport technologies may be used in the SP network.
For inclusive P-Multicast trees, these transport technologies include For inclusive P-Multicast trees, these transport technologies include
point-to-multipoint LSPs created by RSVP-TE or mLDP. point-to-multipoint LSPs created by RSVP-TE or mLDP.
16.2.1. Inclusive Trees 16.2.1. Inclusive Trees
An Inclusive Tree allows the use of a single multicast distribution An Inclusive Tree allows the use of a single multicast distribution
tree, referred to as an Inclusive P-Multicast tree, in the SP network tree, referred to as an Inclusive P-Multicast tree, in the SP network
to carry all the multicast traffic from a specified set of EVPN to carry all the multicast traffic from a specified set of EVPN
skipping to change at page 45, line 32 skipping to change at page 45, line 32
include every PE that is a member of any of the EVPN instances that include every PE that is a member of any of the EVPN instances that
are using the tree. This implies that a PE may receive BUM traffic are using the tree. This implies that a PE may receive BUM traffic
even if it doesn't have any receivers that are interested in even if it doesn't have any receivers that are interested in
receiving that traffic. receiving that traffic.
An Inclusive or Aggregate Inclusive tree as defined in this document An Inclusive or Aggregate Inclusive tree as defined in this document
is a P2MP tree. A P2MP tree is used to carry traffic only for EVPN is a P2MP tree. A P2MP tree is used to carry traffic only for EVPN
CEs that are connected to the PE that is the root of the tree. CEs that are connected to the PE that is the root of the tree.
The procedures for signaling an Inclusive tree are the same as those The procedures for signaling an Inclusive tree are the same as those
in [VPLS-MCAST] with the VPLS-AD route replaced with the Inclusive in [RFC7117] with the VPLS-AD route replaced with the Inclusive
Multicast Ethernet Tag route. The P-Tunnel attribute [VPLS-MCAST] for Multicast Ethernet Tag route. The P-Tunnel attribute [RFC7117] for an
an Inclusive tree is advertised with the Inclusive Multicast Ethernet Inclusive tree is advertised with the Inclusive Multicast Ethernet
Tag route as described in section "Handling of Multi-Destination Tag route as described in section "Handling of Multi-Destination
Traffic". Note that for an Aggregate Inclusive tree, a PE can Traffic". Note that for an Aggregate Inclusive tree, a PE can
"aggregate" multiple EVPN instances on the same P2MP LSP using "aggregate" multiple EVPN instances on the same P2MP LSP using
upstream labels. The procedures for aggregation are the same as those upstream labels. The procedures for aggregation are the same as those
described in [VPLS-MCAST], with VPLS A-D routes replaced by EVPN described in [RFC7117], with VPLS A-D routes replaced by EVPN
Inclusive Multicast Ethernet Tag routes. Inclusive Multicast Ethernet Tag routes.
17. Convergence 17. Convergence
This section describes failure recovery from different types of This section describes failure recovery from different types of
network failures. network failures.
17.1. Transit Link and Node Failures between PEs 17.1. Transit Link and Node Failures between PEs
The use of existing MPLS Fast-Reroute mechanisms can provide failure The use of existing MPLS Fast-Reroute mechanisms can provide failure
skipping to change at page 49, line 31 skipping to change at page 49, line 31
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 has allocated the following EVPN Extended Community sub-types IANA has allocated the following EVPN Extended Community sub-types
and this document is the only reference for them. and this document is the only reference for them.
0x00 MAC Mobility [this document] 0x00 MAC Mobility [this document]
0x01 ESI Label [this document] 0x01 ESI Label [this document]
0x02 ES-Import Route Target [this document] 0x02 ES-Import Route Target [this document]
This document is creating a registry called "EVPN Route Types." New This document is creating a registry called "EVPN Route Types." New
registrations will be made through the "RFC Required" procedure registrations will be made through the "RFC Required" procedure
defined in [RFC5226]. The registry has no maximum value. Initial defined in [RFC5226]. The registry has no maximum value. Initial
registrations are as follows: registrations are as follows:
1 Ethernet Auto-Discovery [this document] 1 Ethernet Auto-Discovery [this document]
2 MAC/IP Advertisement [this document] 2 MAC/IP Advertisement [this document]
3 Inclusive Multicast Ethernet Tag [this document] 3 Inclusive Multicast Ethernet Tag [this document]
4 Ethernet Segment [this document] 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 22 skipping to change at page 50, line 22
[RFC4760] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC [RFC4760] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC
4760, January 2007 4760, January 2007
23.2 Informative References 23.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet
VPN", draft-ietf-l2vpn-evpn-req-04.txt, July 2013. VPN", May 2014.
[RFC7117] "Multicast in VPLS". R. Aggarwal et.al., draft-ietf-l2vpn- [RFC7117] R. Aggarwal et.al., "Multicast in Virtual Private LAN
vpls-mcast-14.txt, July 2013. Service (VPLS)", February 2014.
[RFC4684] P. Marques et. al., "Constrained Route Distribution for [RFC4684] P. Marques et. al., "Constrained Route Distribution for
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
[RFC5925] J. Touch et. al., "The TCP Authentication Option", RFC
5925, June 2010
[RFC5226] T. Narten et. al., "Guidelines for Writing an IANA [RFC5226] T. Narten et. al., "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC 5226, May 2008 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
 End of changes. 48 change blocks. 
91 lines changed or deleted 89 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/