draft-ietf-l2vpn-evpn-07.txt   draft-ietf-l2vpn-evpn-08.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: November 7, 2014 May 7, 2014 Expires: March 12, 2015 September 12, 2014
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-07 draft-ietf-l2vpn-evpn-08
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 2, line 18 skipping to change at page 2, line 18
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). (EVPN). The procedures described here are intended to meet the
requirements specified in [EVPN-REQ].
Table of Contents Table of Contents
1. Specification of requirements . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Specification of requirements . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . 10 6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 11
6.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 11 6.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 11
6.2.1 Port Based Service Interface . . . . . . . . . . . . . . 11 6.2.1 Port Based Service Interface . . . . . . . . . . . . . . 11
6.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 11 6.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 11
6.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 12 6.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 12
7. BGP EVPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. BGP EVPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 13 7.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 13
7.2. MAC/IP Advertisement Route . . . . . . . . . . . . . . . . 13 7.2. MAC/IP Advertisement Route . . . . . . . . . . . . . . . . 13
7.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 14 7.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 14
7.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 15 7.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 15
7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 15 7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 15
skipping to change at page 3, line 22 skipping to change at page 3, line 24
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 . . . . . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 33 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 . . . . . . . . . . . . . . . . . . . 35 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 . . . . . . . . . . . . . . . . . . 36
13.1. Forwarding packets received from a CE . . . . . . . . . . 36 13.1. Forwarding packets received from a CE . . . . . . . . . . 37
13.2. Forwarding packets received from a remote PE . . . . . . . 37 13.2. Forwarding packets received from a remote PE . . . . . . . 38
13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 37 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 . . . . 38
14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 38 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 . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43 15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43
15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 43 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 . . . . . . . . . . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . . . . . . . . . 45
17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 45 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. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 48 21. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 48
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 . . . . . . . . . . . . . . . . . . 49 23.2 Informative References . . . . . . . . . . . . . . . . . . 50
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50 24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50
1. Specification of requirements 1. Introduction
This document describes procedures for BGP MPLS based Ethernet VPNs
(EVPN). The procedures described here are intended to meet the
requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for
the detailed requirements and motivation. EVPN requires extensions to
existing IP/MPLS protocols as described in this document. In addition
to these extensions EVPN uses several building blocks from existing
MPLS technologies.
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].
2. Terminology 3. Terminology
Broadcast Domain: in a bridged network, it corresponds to a Virtual Broadcast Domain: in a bridged network, it corresponds to a Virtual
LAN (VLAN); where a VLAN is typically represented by a single VLAN ID LAN (VLAN); where a VLAN is typically represented by a single VLAN ID
(VID), but can be represented by several VIDs. (VID), but can be represented by several VIDs.
Bridge Domain: An instantiation of a broadcast domain on a bridge Bridge Domain: An instantiation of a broadcast domain on a bridge
node node
CE: Customer Edge device e.g., host or router or switch CE: Customer Edge device e.g., host or router or switch
skipping to change at page 6, line 11 skipping to change at page 6, line 23
Single-Active Redundancy Mode: When only a single PE, among a group Single-Active Redundancy Mode: When only a single PE, among a group
of PEs attached to an Ethernet segment, is allowed to forward traffic of PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet Segment, then the Ethernet segment is defined to/from that Ethernet Segment, then the Ethernet segment is defined
to be operating in Single-Active redundancy mode. to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward traffic to/from that Ethernet Segment, segment are allowed to forward traffic to/from that Ethernet Segment,
then the Ethernet segment is defined to be operating in All-Active then the Ethernet segment is defined to be operating in All-Active
redundancy mode. redundancy mode.
3. Introduction
This document describes procedures for BGP MPLS based Ethernet VPNs
(EVPN). The procedures described here are intended to meet the
requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for
the detailed requirements and motivation. EVPN requires extensions to
existing IP/MPLS protocols as described in this document. In addition
to these extensions EVPN uses several building blocks from existing
MPLS technologies.
4. BGP MPLS Based EVPN Overview 4. BGP MPLS Based EVPN Overview
This section provides an overview of EVPN. An EVPN instance comprises This section provides an overview of EVPN. An EVPN instance comprises
CEs that are connected to PEs that form the edge of the MPLS CEs that are connected to PEs that form the edge of the MPLS
infrastructure. A CE may be a host, a router or a switch. The PEs infrastructure. A CE may be a host, a router or a switch. The PEs
provide virtual Layer 2 bridged connectivity between the CEs. There provide virtual Layer 2 bridged connectivity between the CEs. There
may be multiple EVPN instances in the provider's network. may be multiple EVPN instances in the provider's network.
The PEs may be connected by an MPLS LSP infrastructure which provides The PEs may be connected by an MPLS LSP infrastructure which provides
the benefits of MPLS technology such as fast-reroute, resiliency, the benefits of MPLS technology such as fast-reroute, resiliency,
skipping to change at page 7, line 22 skipping to change at page 7, line 22
suited to the CE: data plane learning, IEEE 802.1x, LLDP, 802.1aq, suited to the CE: data plane learning, IEEE 802.1x, LLDP, 802.1aq,
ARP, management plane or other protocols. ARP, management plane or other protocols.
It is a local decision as to whether the Layer 2 forwarding table on It is a local decision as to whether the Layer 2 forwarding table on
a PE is populated with all the MAC destination addresses known to the a PE is populated with all the MAC destination addresses known to the
control plane, or whether the PE implements a cache based scheme. For control plane, or whether the PE implements a cache based scheme. For
instance the MAC forwarding table may be populated only with the MAC instance the MAC forwarding table may be populated only with the MAC
destinations of the active flows transiting a specific PE. destinations of the active flows transiting a specific PE.
The policy attributes of EVPN are very similar to those of IP-VPN. A The policy attributes of EVPN are very similar to those of IP-VPN. A
EVPN instance requires a Route-Distinguisher (RD) which is unique per EVPN instance requires a Route Distinguisher (RD) which is unique per
PE and one or more globally unique Route-Targets (RTs). A CE attaches PE and one or more globally unique Route-Targets (RTs). A CE attaches
to a MAC-VRF on a PE, on an Ethernet interface which may be to a MAC-VRF on a PE, on an Ethernet interface which may be
configured for one or more Ethernet Tags, e.g., VLAN IDs. Some configured for one or more Ethernet Tags, e.g., VLAN IDs. Some
deployment scenarios guarantee uniqueness of VLAN IDs across EVPN deployment scenarios guarantee uniqueness of VLAN IDs across EVPN
instances: all points of attachment for a given EVPN instance use the instances: all points of attachment for a given EVPN instance use the
same VLAN ID, and no other EVPN instance uses this VLAN ID. This same VLAN ID, and no other EVPN instance uses this VLAN ID. This
document refers to this case as a "Unique VLAN EVPN" and describes document refers to this case as a "Unique VLAN EVPN" and describes
simplified procedures to optimize for it. simplified procedures to optimize for it.
5. Ethernet Segment 5. Ethernet Segment
If a CE is multi-homed to two or more PEs, the set of Ethernet links If a CE is multi-homed to two or more PEs, the set of Ethernet links
constitutes an "Ethernet Segment". An Ethernet segment may appear to constitutes an "Ethernet Segment". An Ethernet segment may appear to
the CE as a Link Aggregation Group (LAG). Ethernet segments have an the CE as a Link Aggregation Group (LAG). Ethernet segments have an
identifier, called the "Ethernet Segment Identifier" (ESI) which is identifier, called the "Ethernet Segment Identifier" (ESI) which is
encoded as a ten octets integer. The following two ESI values are encoded as a ten octets integer in line format with the most
significant octet sent first. The following two ESI values are
reserved: reserved:
- ESI 0 denotes a single-homed CE. - ESI 0 denotes a single-homed CE.
- ESI {0xFF} (repeated 10 times) is known as MAX-ESI and is - ESI {0xFF} (repeated 10 times) is known as MAX-ESI and is
reserved. reserved.
In general, an Ethernet segment MUST have a non-reserved ESI that is In general, an Ethernet segment SHOULD have a non-reserved ESI that
unique network wide (i.e., across all EVPN instances on all the PEs). is unique network wide (i.e., across all EVPN instances on all the
If the CE(s) constituting an Ethernet Segment is (are) managed by the PEs). If the CE(s) constituting an Ethernet Segment is (are) managed
network operator, then ESI uniqueness should be guaranteed; however, by the network operator, then ESI uniqueness should be guaranteed;
if the CE(s) is (are) not managed, then the operator MUST configure a however, if the CE(s) is (are) not managed, then the operator MUST
network-wide unique ESI for that Ethernet Segment. This is required configure a network-wide unique ESI for that Ethernet Segment. This
to enable auto-discovery of Ethernet Segments and DF election. is required to enable auto-discovery of Ethernet Segments and DF
election.
In a network with managed and not-managed CEs, the ESI has the In a network with managed and not-managed CEs, the ESI has the
following format: following format:
+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+
| T | ESI Value | | T | ESI Value |
+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+
Where: Where:
T (ESI Type) is a 1-byte field (most significant octet) that T (ESI Type) is a 1-octet field (most significant octet) that
specifies the format of the remaining nine bytes (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
skipping to change at page 10, line 8 skipping to change at page 10, line 10
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 order
extra two bytes will be 0x0000. extra two octets will be 0x0000.
+ Local Discriminator value (four octets). The Local Discriminator + Local Discriminator value (four octets). The Local Discriminator
MUST be encoded in the four octets next to the AS number. 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 satisfy
the uniqueness requirement specified above. the uniqueness requirement specified above.
6. Ethernet Tag ID 6. Ethernet Tag ID
skipping to change at page 10, line 41 skipping to change at page 10, line 43
If a VLAN is represented by a single VID across all PE devices If a VLAN is represented by a single VID across all PE devices
participating in that VLAN for that EVPN instance, then there is no participating in that VLAN for that EVPN instance, then there is no
need for VID translation at the PEs. Furthermore, some deployment need for VID translation at the PEs. Furthermore, some deployment
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 Tags (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 Identifier, in the various well as the setting of the Ethernet Tag ID, in the various EVPN BGP
EVPN BGP routes (defined in section 8), for the different types of routes (defined in section 8), for the different types of service
service interfaces described in [EVPN-REQ]. interfaces described in [EVPN-REQ].
The following value of Ethernet Tag is reserved: The following value of Ethernet Tag ID is reserved:
- Ethernet Tag {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.
Since a MAC-VRF corresponds to a single VLAN, it consists of a single Since a MAC-VRF corresponds to a single VLAN, it consists of a single
bridge domain corresponding to that VLAN. If the VLAN is represented bridge domain corresponding to that VLAN. If the VLAN is represented
by different VIDs on different PEs, then each PE needs to perform VID by multiple VIDs (e.g., a different VID per Ethernet Segment per PE),
translation for frames destined to its attached CEs. In such then each PE needs to perform VID translation for frames destined to
scenarios, the Ethernet frames transported over MPLS/IP network its Ethernet Segment(s). In such scenarios, the Ethernet frames
SHOULD remain tagged with the originating VID and a VID translation transported over MPLS/IP network SHOULD remain tagged with the
MUST be supported in the data path and MUST be performed on the originating VID and a VID translation MUST be supported in the data
disposition PE. The Ethernet Tag Identifier in all EVPN routes MUST path and MUST be performed on the disposition PE. The Ethernet Tag ID
be set to 0. in all EVPN routes MUST be set to 0.
6.2 VLAN Bundle Service Interface 6.2 VLAN Bundle Service Interface
With this service interface, an EVPN instance corresponds to several With this service interface, an EVPN instance corresponds to several
broadcast domains (e.g., several VLANs); however, only a single broadcast domains (e.g., several VLANs); however, only a single
bridge domain is maintained per MAC-VRF which means multiple VLANs bridge domain is maintained per MAC-VRF which means multiple VLANs
share the same bridge domain. This implies MAC addresses MUST be share the same bridge domain. This implies MAC addresses MUST be
unique across different VLANs for this service to work. In other unique across different VLANs for this service to work. In other
words, there is a many-to-one mapping between VLANs and a MAC-VRF, words, there is a many-to-one mapping between VLANs and a MAC-VRF,
and the MAC-VRF consists of a single bridge domain. Furthermore, a and the MAC-VRF consists of a single bridge domain. Furthermore, a
single VLAN must be represented by a single VID - e.g., no VID single VLAN must be represented by a single VID - e.g., no VID
translation is allowed for this service interface type. The MPLS translation is allowed for this service interface type. The MPLS
encapsulated frames MUST remain tagged with the originating VID. Tag encapsulated frames MUST remain tagged with the originating VID. Tag
translation is NOT permitted. The Ethernet Tag Identifier in all EVPN translation is NOT permitted. The Ethernet Tag ID in all EVPN routes
routes MUST be set to 0. MUST be set to 0.
6.2.1 Port Based Service Interface 6.2.1 Port Based Service Interface
This service interface is a special case of the VLAN Bundle service This service interface is a special case of the VLAN Bundle service
interface, where all of the VLANs on the port are part of the same interface, where all of the VLANs on the port are part of the same
service and map to the same bundle. The procedures are identical to service and map to the same bundle. The procedures are identical to
those described in section 6.2. those described in section 6.2.
6.3 VLAN Aware Bundle Service Interface 6.3 VLAN Aware Bundle Service Interface
With this service interface, an EVPN instance consists of several With this service interface, an EVPN instance consists of several
broadcast domains (e.g., several VLANs) with each VLAN having its own broadcast domains (e.g., several VLANs) with each VLAN having its own
bridge domain - i.e., multiple bridge domains (one per VLAN) is bridge domain - i.e., multiple bridge domains (one per VLAN) is
maintained by a single MAC-VRF corresponding to the EVPN instance. In maintained by a single MAC-VRF corresponding to the EVPN instance. In
the case where a single VLAN is represented by different VIDs on the case where a single VLAN is represented by different VIDs on
different CEs and thus tag (VID) translation is required, a different CEs and thus VID translation is required, a normalized
normalized Ethernet Tag (VID) MUST be carried in the MPLS Ethernet Tag ID (VID) MUST be carried in the MPLS encapsulated frames
encapsulated frames and a tag translation function MUST be supported and a Ethernet Tag ID translation function MUST be supported in the
in the data path. This translation MUST be performed in data path on data path. This translation MUST be performed in data path on both
both the imposition as well as the disposition PEs (translating to the imposition as well as the disposition PEs (translating to
normalized tag on imposition PE and translating to local tag on normalized Ethernet Tag ID on imposition PE and translating to local
disposition PE). The Ethernet Tag Identifier in all EVPN routes MUST Ethernet Tag ID on disposition PE). The Ethernet Tag ID in all EVPN
be set to the normalized Ethernet Tag assigned by the EVPN provider. routes MUST be set to the normalized value assigned by the EVPN
provider.
6.3.1 Port Based VLAN Aware Service Interface 6.3.1 Port Based VLAN Aware Service Interface
This service interface is a special case of the VLAN Aware Bundle This service interface is a special case of the VLAN Aware Bundle
service interface, where all of the VLANs on the port are part of the service interface, where all of the VLANs on the port are part of the
same service and are mapped to a single bundle but without any VID same service and are mapped to a single bundle but without any VID
translation. The procedures are subset of those described in section translation. The procedures are subset of those described in section
6.3. 6.3.
7. BGP EVPN NLRI 7. BGP EVPN NLRI
skipping to change at page 13, line 14 skipping to change at page 13, line 17
capable of properly processing such NLRI. This is done as specified capable of properly processing such NLRI. This is done as specified
in [RFC4760], by using capability code 1 (multiprotocol BGP) with an in [RFC4760], by using capability code 1 (multiprotocol BGP) with an
AFI of 25 (L2VPN) and a SAFI of 70 (EVPN). AFI of 25 (L2VPN) and a SAFI of 70 (EVPN).
7.1. Ethernet Auto-Discovery Route 7.1. Ethernet Auto-Discovery Route
A Ethernet A-D route type specific EVPN NLRI consists of the A Ethernet A-D route type specific EVPN NLRI consists of the
following: following:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | Route Distinguisher (RD) (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +---------------------------------------+
For the purpose of BGP route key processing, only the Ethernet For the purpose of BGP route key processing, only the Ethernet
Segment Identifier and the Ethernet Tag ID are considered to be part Segment Identifier and the Ethernet Tag ID are considered to be part
skipping to change at page 14, line 28 skipping to change at page 14, line 28
| IP Address (0 or 4 or 16 octets) | | IP Address (0 or 4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label1 (3 octets) | | MPLS Label1 (3 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label2 (0 or 3 octets) | | MPLS Label2 (0 or 3 octets) |
+---------------------------------------+ +---------------------------------------+
For the purpose of BGP route key processing, only the Ethernet Tag For the purpose of BGP route key processing, only the Ethernet Tag
ID, MAC Address Length, MAC Address, IP Address Length, and IP ID, MAC Address Length, MAC Address, IP Address Length, and IP
Address Address fields are considered to be part of the prefix in the Address Address fields are considered to be part of the prefix in the
NLRI. The Ethernet Segment Identifier and MPLS Label fields are to be NLRI. The Ethernet Segment Identifier and MPLS Label1 and MPLS Label2
treated as route attributes as opposed to being part of the "route". fields are to be treated as route attributes as opposed to being part
The IP address length is in bits. of the "route". The IP address length is in bits.
For procedures and usage of this route please see section 9 For procedures and usage of this route please see section 9
"Determining Reachability to Unicast MAC Addresses" and section 14 "Determining Reachability to Unicast MAC Addresses" and section 14
"Load Balancing of Unicast Packets". "Load Balancing of Unicast Packets".
7.3. Inclusive Multicast Ethernet Tag Route 7.3. Inclusive Multicast Ethernet Tag Route
An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI An Inclusive Multicast Ethernet Tag route type specific EVPN NLRI
consists of the following: consists of the following:
skipping to change at page 15, line 40 skipping to change at page 15, line 40
For the purpose of BGP route key processing, only the Ethernet For the purpose of BGP route key processing, only the Ethernet
Segment ID, IP Address Length, and Originating Router's IP Address Segment ID, IP Address Length, and Originating Router's IP Address
fields are considered to be part of the prefix in the NLRI. fields are considered to be part of the prefix in the NLRI.
7.5 ESI Label Extended Community 7.5 ESI Label Extended Community
This extended community is a new transitive extended community with This extended community is a new transitive extended community with
the Type field is 0x06, and the Sub-Type of 0x01. It may be the Type field is 0x06, and the Sub-Type of 0x01. It may be
advertised along with Ethernet Auto-Discovery routes and it enables advertised along with Ethernet Auto-Discovery routes and it enables
split-horizon procedures for multi-homed sites as described in split-horizon procedures for multi-homed sites as described in
section 8.3 "Split Horizon". section 8.3 "Split Horizon". ESI Label represents an ES by the
advertising PE and it is used in split-horizon filtering by other PEs
that are connected to the same multi-homed Ethernet Segment.
Each ESI Label Extended Community is encoded as a 8-octet value as Each ESI Label Extended Community is encoded as a 8-octet value as
follows: follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x01 | Flags(1 Octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0 | ESI Label | | Reserved = 0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 16, line 14 skipping to change at page 16, line 16
Active" bit. A value of 0 means that the multi-homed site is Active" bit. A value of 0 means that the multi-homed site is
operating in All-Active redundancy mode and a value of 1 means that operating in All-Active redundancy mode and a value of 1 means that
the multi-homed site is operating in Single-Active redundancy mode. the multi-homed site is operating in Single-Active redundancy mode.
7.6 ES-Import Route Target 7.6 ES-Import Route Target
This is a new transitive Route Target extended community carried with This is a new transitive Route Target extended community carried with
the Ethernet Segment route. When used, it enables all the PEs the Ethernet Segment route. When used, it enables all the PEs
connected to the same multi-homed site to import the Ethernet Segment connected to the same multi-homed site to import the Ethernet Segment
routes. The value is derived automatically from the ESI by encoding routes. The value is derived automatically from the ESI by encoding
the high order 6-byte portion of the 9-byte ESI Value in the ES- the high order 6-octet portion of the 9-octet ESI Value in the ES-
Import Route Target. The high order 6-byte of the ESI incorporates Import Route Target. The high order 6-octet of the ESI incorporates
MAC address of ESI (for type 1, 2, and 3) which when encoded in this MAC address of ESI (for type 1, 2, and 3) which when encoded in this
RT and used in the RT constrain feature, it enables proper route- RT and used in the RT constrain feature, it enables proper route-
target filtering. The format of this extended community is as target filtering. The format of this extended community is as
follows: follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type=0x06 | Sub-Type=0x02 | ES-Import | | Type=0x06 | Sub-Type=0x02 | ES-Import |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ES-Import Cont'd | | ES-Import Cont'd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This document expands the definition of the Route Target extended This document expands the definition of the Route Target extended
community to allow the value of high order octet (Type field) to be community to allow the value of high order octet (Type field) to be
0x06 (in addition to the values specified in rfc4360). The value of 0x06 (in addition to the values specified in rfc4360). The value of
low order octet (Sub-Type field) of 0x02 indicates that this extended low order octet (Sub-Type field) of 0x02 indicates that this extended
community is of type "Route Target". The new value for Type field of community is of type "Route Target". The new value for Type field of
0x06 indicates that the structure of this RT is a six bytes value 0x06 indicates that the structure of this RT is a six-octet value
(e.g., a MAC address). A BGP speaker that implements RT-Constrain (e.g., a MAC address). A BGP speaker that implements RT-Constrain
[RFC4684] MUST apply the RT Constraint procedures to the ES-import RT [RFC4684] MUST apply the RT Constraint procedures to the ES-import RT
as well. as well.
For procedures and usage of this attribute, please see section 8.1 For procedures and usage of this attribute, please see section 8.1
"Multi-homed Ethernet Segment Auto-Discovery". "Multi-homed Ethernet Segment Auto-Discovery".
7.7 MAC Mobility Extended Community 7.7 MAC Mobility Extended Community
This extended community is a new transitive extended community with This extended community is a new transitive extended community with
skipping to change at page 17, line 44 skipping to change at page 17, line 44
unique to the PE. This number may be generated by the PE. Or in the unique to the PE. This number may be generated by the PE. Or in the
Unique VLAN EVPN case, the low order 12 bits may be the 12 bit VLAN Unique VLAN EVPN case, the low order 12 bits may be the 12 bit VLAN
ID, with the remaining high order 4 bits set to 0. ID, with the remaining high order 4 bits set to 0.
7.10 Route Targets 7.10 Route Targets
The EVPN route MAY carry one or more Route Target (RT) attributes. The EVPN route MAY carry one or more Route Target (RT) attributes.
RTs may be configured (as in IP VPNs), or may be derived RTs may be configured (as in IP VPNs), or may be derived
automatically. automatically.
If a PE uses RT-Constrain, the PE SHOULD advertise all such RTs using If a PE uses RT-Constrain, the PE advertises all such RTs using RT
RT Constraints. The use of RT Constrains allows each Ethernet A-D Constraints per [RFC4684]. The use of RT Constrains allows each
route to reach only those PEs that are configured to import at least Ethernet A-D route to reach only those PEs that are configured to
one RT from the set of RTs carried in the EVPN route. import at least one RT from the set of RTs carried in the EVPN route.
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
skipping to change at page 18, line 33 skipping to change at page 18, line 33
PEs connected to the same Ethernet segment can automatically discover PEs connected to the same Ethernet segment can automatically discover
each other with minimal to no configuration through the exchange of each other with minimal to no configuration through the exchange of
the Ethernet Segment route. the Ethernet Segment route.
8.1.1 Constructing the Ethernet Segment Route 8.1.1 Constructing the Ethernet Segment Route
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 0's. address) followed by 0's.
The Ethernet Segment Identifier MUST be set to the ten octet ESI The Ethernet Segment Identifier (ESI) MUST be set to the ten octet
identifier described in section 5. value described in section 5.
The BGP advertisement that advertises the Ethernet Segment route MUST The BGP advertisement that advertises the Ethernet Segment route MUST
also carry an ES-Import route target, as defined in section 7.6. also carry an ES-Import route target, as defined in section 7.6.
The Ethernet Segment Route filtering MUST be done such that the The Ethernet Segment Route filtering MUST be done such that the
Ethernet Segment Route is imported only by the PEs that are multi- Ethernet Segment Route is imported only by the PEs that are multi-
homed to the same Ethernet Segment. To that end, each PE that is homed to the same Ethernet Segment. To that end, each PE that is
connected to a particular Ethernet segment constructs an import connected to a particular Ethernet segment constructs an import
filtering rule to import a route that carries the ES-Import extended filtering rule to import a route that carries the ES-Import extended
community, constructed from the ESI. community, constructed from the ESI.
skipping to change at page 19, line 30 skipping to change at page 19, line 30
the withdrawal simply invalidates the MAC entries for that segment. the withdrawal simply invalidates the MAC entries for that segment.
Otherwise, the PE updates the next-hop adjacencies to point to the Otherwise, the PE updates the next-hop adjacencies to point to the
backup PE(s). 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
MANDATORY. 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.
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". The Ethernet A-D route is described in section "Ethernet Segment". The Ethernet A-D route is
not needed when the Segment Identifier is set to 0 (e.g., single- not needed when the Segment Identifier is set to 0 (e.g., single-
homed scenarios). homed scenarios).
skipping to change at page 20, line 13 skipping to change at page 20, line 13
per ES route advertised for the ES. This label MUST be a downstream per ES route advertised for the ES. This label MUST be a downstream
assigned MPLS label if the advertising PE is using ingress assigned MPLS label if the advertising PE is using ingress
replication for receiving multicast, broadcast or unknown unicast replication for receiving multicast, broadcast or unknown unicast
traffic from other PEs. If the advertising PE is using P2MP MPLS LSPs traffic from other PEs. If the advertising PE is using P2MP MPLS LSPs
for sending multicast, broadcast or unknown unicast traffic, then for sending multicast, broadcast or unknown unicast traffic, then
this label MUST be an upstream assigned MPLS label. The usage of this this label MUST be an upstream assigned MPLS label. The usage of this
label is described in section 8.3. label is described in section 8.3.
If Single-Active redundancy mode is desired, then the "Single-Active" If Single-Active redundancy mode is desired, then the "Single-Active"
bit in the flags of the ESI Label Extended Community MUST be set to 1 bit in the flags of the ESI Label Extended Community MUST be set to 1
and the ESI label MUST be set to zero. and the ESI label SHOULD be set to a valid MPLS label value.
8.2.1.1. Ethernet A-D Route Targets 8.2.1.1. Ethernet A-D Route Targets
Each Ethernet A-D per ES route MUST carry one or more Route Target Each Ethernet A-D per ES route MUST carry one or more Route Target
(RT) attributes. The set of Ethernet A-D routes per ES MUST carry the (RT) attributes. The set of Ethernet A-D routes per ES MUST carry the
entire set of RTs for all the EVPN instances to which the Ethernet entire set of RTs for all the EVPN instances to which the Ethernet
Segment belongs. Segment belongs.
8.3 Split Horizon 8.3 Split Horizon
Consider a CE that is multi-homed to two or more PEs on an Ethernet Consider a CE that is multi-homed to two or more PEs on an Ethernet
segment ES1 operating in All-Active redundancy mode. If the CE sends segment ES1 operating in All-Active redundancy mode. If the CE sends
a broadcast, unknown unicast, or multicast (BUM) packet to one of the a broadcast, unknown unicast, or multicast (BUM) packet to one of the
non-DF (Designated Forwarder) PEs, say PE1, then PE1 will forward non-Designated Forwarder (non-DF) PEs, say PE1, then PE1 will forward
that packet to all or subset of the other PEs in that EVPN instance that packet to all or subset of the other PEs in that EVPN instance
including the DF PE for that Ethernet segment. In this case the DF PE including the Designated Forwarder (DF) PE for that Ethernet segment.
that the CE is multi-homed to MUST drop the packet and not forward In this case the DF PE that the CE is multi-homed to MUST drop the
back to the CE. This filtering is referred to as "split horizon" packet and not forward back to the CE. This filtering is referred to
filtering in this document. as "split horizon" filtering in this document.
When a set of PEs operating in Single-Active redundancy mode, the use When a set of PEs operating in Single-Active redundancy mode, the use
of this split-horizon filtering mechanism is highly recommended of this split-horizon filtering mechanism is highly recommended
because it prevents transient loop at the time of failure or recovery because it prevents transient loop at the time of failure or recovery
impacting the Ethernet Segment - e.g., when two PEs thinks that both impacting the Ethernet Segment - e.g., when two PEs thinks that both
are DFs for that segment before DF election procedure settles down. are DFs for that segment before DF election procedure settles down.
In order to achieve this split horizon function, every BUM packet In order to achieve this split horizon function, every BUM packet
originating from a non-DF PE is encapsulated with an MPLS label that originating from a non-DF PE is encapsulated with an MPLS label that
identifies the Ethernet segment of origin (i.e. the segment from identifies the Ethernet segment of origin (i.e. the segment from
skipping to change at page 30, line 21 skipping to change at page 30, line 21
The MPLS label2 field is an optional field and if it is present, then The MPLS label2 field is an optional field and if it is present, then
it is encoded as 3 octets, where the high-order 20 bits contain the it is encoded as 3 octets, where the high-order 20 bits contain the
label value. label value.
The Next Hop field of the MP_REACH_NLRI attribute of the route MUST The Next Hop field of the MP_REACH_NLRI attribute of the route MUST
be set to the IPv4 or IPv6 address of the advertising PE. be set to the IPv4 or IPv6 address of the advertising PE.
The BGP advertisement for the MAC advertisement route MUST also carry The BGP advertisement for the MAC advertisement route MUST also carry
one or more Route Target (RT) attributes. RTs may be configured (as one or more Route Target (RT) attributes. RTs may be configured (as
in IP VPNs), or may be derived automatically from the Ethernet Tag in IP VPNs), or may be derived automatically from the Ethernet Tag
ID, in the Unique VLAN case, as described in section 8.4.1.1.1. ID, in the Unique VLAN case, as described in section 7.10.1.
It is to be noted that this document does not require PEs to create It is to be noted that this document does not require PEs to create
forwarding state for remote MACs when they are learnt in the control forwarding state for remote MACs when they are learnt in the control
plane. When this forwarding state is actually created is a local plane. When this forwarding state is actually created is a local
implementation matter. implementation matter.
9.2.2 Route Resolution 9.2.2 Route Resolution
If the Ethernet Segment Identifier field in a received MAC If the Ethernet Segment Identifier field in a received MAC
Advertisement route is set to the reserved ESI value of 0 or MAX-ESI, Advertisement route is set to the reserved ESI value of 0 or MAX-ESI,
skipping to change at page 31, line 51 skipping to change at page 31, line 51
learns the IP address associated with a MAC address, of a locally learns the IP address associated with a MAC address, of a locally
connected CE, it may advertise this address to other PEs by including connected CE, it may advertise this address to other PEs by including
it in the MAC Advertisement route. The IP Address may be an IPv4 it in the MAC Advertisement route. The IP Address may be an IPv4
address encoded using four octets, or an IPv6 address encoded using address encoded using four octets, or an IPv6 address encoded using
sixteen octets. For ARP and ND purposes, the IP Address length field sixteen octets. For ARP and ND purposes, the IP Address length field
MUST be set to 32 for an IPv4 address or to 128 for an IPv6 address. MUST be set to 32 for an IPv4 address or to 128 for an IPv6 address.
If there are multiple IP addresses associated with a MAC address, If there are multiple IP addresses associated with a MAC address,
then multiple MAC advertisement routes MUST be generated, one for then multiple MAC advertisement routes MUST be generated, one for
each IP address. For instance, this may be the case when there are each IP address. For instance, this may be the case when there are
both an IPv4 and an IPv6 address associated with the MAC address. both an IPv4 and an IPv6 address associated with the same MAC address
for dual-IP stack scenarios. When the IP address is dissociated with
the MAC address, then the MAC advertisement route with that
particular IP address MUST be withdrawn.
When the IP address is dissociated with the MAC address, then the MAC Note that a MAC-only route can be advertised along with but
advertisement route with that particular IP address MUST be independent from MAC/IP route for scenarios where the MAC learning
withdrawn. over access network/node is done in data-plane and independent from
ARP snooping that generates MAC/IP route. In such scenarios when the
ARP entry times out and causes the MAC/IP to be withdrawn, then the
MAC information will not be lost. In scenarios where host MAC/IP is
learned via management or control plane, then the sender PE may only
generates and advertises MAC/IP route. If the receiving PE receives
both the MAC-only route and the MAC/IP route, then when it receives a
withdraw message for the MAC/IP route, it MUST delete the
corresponding entry from the ARP table but not the MAC entry from the
MAC-VRF table unless it receives a withdraw message for MAC-only
route.
When a PE receives an ARP request for an IP address from a CE, and if When a PE receives an ARP request for an IP address from a CE, and if
the PE has the MAC address binding for that IP address, the PE SHOULD the PE has the MAC address binding for that IP address, the PE SHOULD
perform ARP proxy by responding to the ARP request. perform ARP proxy by responding to the ARP request.
10.1 Default Gateway 10.1 Default Gateway
When a PE needs to perform inter-subnet forwarding where each subnet When a PE needs to perform inter-subnet forwarding where each subnet
is represented by a different broadcast domain (e.g., different VLAN) is represented by a different broadcast domain (e.g., different VLAN)
the inter-subnet forwarding is performed at layer 3 and the PE that the inter-subnet forwarding is performed at layer 3 and the PE that
skipping to change at page 36, line 38 skipping to change at page 37, line 4
equivalent of an Aggregate Inclusive tree in [VPLS-MCAST]. When P2MP equivalent of an Aggregate Inclusive tree in [VPLS-MCAST]. 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
This section describes procedures for forwarding unicast packets by This section describes procedures for forwarding unicast packets by
PEs, where such packets are received from either directly connected PEs, where such packets are received from either directly connected
CEs, or from some other PEs. CEs, or from some other PEs.
13.1. Forwarding packets received from a CE 13.1. Forwarding packets received from a CE
When a PE receives a packet from a CE, on a given Ethernet Tag, it When a PE receives a packet from a CE, on a given Ethernet Tag ID, it
must first look up the source MAC address of the packet. In certain must first look up the source MAC address of the packet. In certain
environments the source MAC address MAY be used to authenticate the environments that enable MAC security, the source MAC address MAY be
CE and determine that traffic from the host can be allowed into the used to validate the host identity and determine that traffic from
network. Source MAC lookup MAY also be used for local MAC address the host can be allowed into the network. Source MAC lookup MAY also
learning. be used for local MAC address learning.
If the PE decides to forward the packet, the destination MAC address If the PE decides to forward the packet, the destination MAC address
of the packet must be looked up. If the PE has received MAC address of the packet must be looked up. If the PE has received MAC address
advertisements for this destination MAC address from one or more advertisements for this destination MAC address from one or more
other PEs or learned it from locally connected CEs, it is considered other PEs or learned it from locally connected CEs, it is considered
as a known MAC address. Otherwise, the MAC address is considered as as a known MAC address. Otherwise, the MAC address is considered as
an unknown MAC address. an unknown MAC address.
For known MAC addresses the PE forwards this packet to one of the For known MAC addresses the PE forwards this packet to one of the
remote PEs or to a locally attached CE. When forwarding to a remote remote PEs or to a locally attached CE. When forwarding to a remote
skipping to change at page 40, line 27 skipping to change at page 40, line 39
LAG interface (ES1), and is sending packets with source MAC address LAG interface (ES1), and is sending packets with source MAC address
MAC1 on VLAN1 (mapped to EVI1). A remote PE, say PE3, is able to MAC1 on VLAN1 (mapped to EVI1). A remote PE, say PE3, is able to
learn that MAC1 is reachable via PE1 and PE2. Both PE1 and PE2 may learn that MAC1 is reachable via PE1 and PE2. Both PE1 and PE2 may
advertise MAC1 in BGP if they receive packets with MAC1 from CE1. If advertise MAC1 in BGP if they receive packets with MAC1 from CE1. If
this is not the case, and if MAC1 is advertised only by PE1, PE3 this is not the case, and if MAC1 is advertised only by PE1, PE3
still considers MAC1 as reachable via both PE1 and PE2 as both PE1 still considers MAC1 as reachable via both PE1 and PE2 as both PE1
and PE2 advertise a set of Ethernet A-D per ES routes for ES1 as well and PE2 advertise a set of Ethernet A-D per ES routes for ES1 as well
as an Ethernet A-D per EVI route for <EVI1, ES1>. as an Ethernet A-D per EVI route for <EVI1, ES1>.
The MPLS label stack to send the packets to PE1 is the MPLS LSP stack The MPLS label stack to send the packets to PE1 is the MPLS LSP stack
to get to PE1 and the EVPN label advertised by PE1 for CE1's MAC. to get to PE1 (at top of the stack) followed by the EVPN label
advertised by PE1 for CE1's MAC .
The MPLS label stack to send packets to PE2 is the MPLS LSP stack to The MPLS label stack to send packets to PE2 is the MPLS LSP stack to
get to PE2 and the MPLS label in the Ethernet A-D route advertised by get to PE2 (at top of the stack) followed by the MPLS label in the
PE2 for <ES1, VLAN1>, if PE2 has not advertised MAC1 in BGP. Ethernet A-D route advertised by PE2 for <ES1, VLAN1>, if PE2 has not
advertised MAC1 in BGP.
We will refer to these label stacks as MPLS next-hops. We will refer to these label stacks as MPLS next-hops.
The remote PE (PE3) can now load balance the traffic it receives from The remote PE (PE3) can now load balance the traffic it receives from
its CEs, destined for CE1, between PE1 and PE2. PE3 may use N-Tuple its CEs, destined for CE1, between PE1 and PE2. PE3 may use N-Tuple
flow information to hash traffic into one of the MPLS next-hops for flow information to hash traffic into one of the MPLS next-hops for
load balancing of IP traffic. Alternatively PE3 may rely on the load balancing of IP traffic. Alternatively PE3 may rely on the
source MAC addresses for load balancing. source MAC addresses for load balancing.
Note that once PE3 decides to send a particular packet to PE1 or PE2 Note that once PE3 decides to send a particular packet to PE1 or PE2
skipping to change at page 46, line 23 skipping to change at page 46, line 37
optimize the withdrawal of MAC advertisement routes. When a PE optimize the withdrawal of MAC advertisement routes. When a PE
receives a withdrawal of a particular Ethernet A-D route from a PE it receives a withdrawal of a particular Ethernet A-D route from a PE it
SHOULD consider all the MAC advertisement routes, that are learned SHOULD consider all the MAC advertisement routes, that are learned
from the same ESI as in the Ethernet A-D route, from the advertising from the same ESI as in the Ethernet A-D route, from the advertising
PE, as having been withdrawn. This optimizes the network convergence PE, as having been withdrawn. This optimizes the network convergence
times in the event of PE to CE failures. times in the event of PE to CE failures.
18. Frame Ordering 18. Frame Ordering
In a MAC address, if the value of the 1st nibble (bits 8 thorough 5) In a MAC address, if the value of the 1st nibble (bits 8 thorough 5)
of the most significant byte of the destination MAC address (which of the most significant octet of the destination MAC address (which
follows the last MPLS label) happens to be 0x4 or 0x6, then the follows the last MPLS label) happens to be 0x4 or 0x6, then the
Ethernet frame can be misinterpreted as an IPv4 or IPv6 packet by Ethernet frame can be misinterpreted as an IPv4 or IPv6 packet by
intermediate P nodes performing ECMP based on deep packet inspection, intermediate P nodes performing ECMP based on deep packet inspection,
thus resulting in load balancing packets belonging to the same flow thus resulting in load balancing packets belonging to the same flow
on different ECMP paths and subjecting them to different delays. on different ECMP paths and subjecting them to different delays.
Therefore, packets belonging to the same flow can arrive at the Therefore, packets belonging to the same flow can arrive at the
destination out of order. This out of order delivery can happen destination out of order. This out of order delivery can happen
during steady state in absence of any failures resulting in during steady state in absence of any failures resulting in
significant impact to the network operation. significant impact to the network operation.
In order to avoid any such mis-ordering, the following rules are In order to avoid any such mis-ordering, the following rules are
applied: applied:
- If a network uses deep packet inspection for its ECMP, then the - If a network uses deep packet inspection for its ECMP, then the
control word SHOULD be used when sending EVPN encapsulated packets "Preferred PW MPLS Control Word" per [RFC4385] SHOULD be used with
over a MP2P LSP. the value of 0 (e.g., a 4-octet field with value of zero) when
sending EVPN encapsulated packets over a MP2P LSP.
- If a network uses Entropy label [RFC6790], then the control word - If a network uses Entropy label [RFC6790], then the control word
SHOULD NOT be used when sending EVPN encapsulated packet over a MP2P SHOULD NOT be used when sending EVPN encapsulated packet over a MP2P
LSP. LSP.
- When sending EVPN encapsulated packets over a P2MP LSP or P2P LSP, - When sending EVPN encapsulated packets over a P2MP LSP or P2P LSP,
then the control world SHOULD NOT be used. then the control world SHOULD NOT be used.
The control word is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram the first 4 bits MUST be set to 0. The rest of
the first 16 bits are reserved for future use. They MUST be set to 0
when transmitting, and MUST be ignored upon receipt. The next 16 bits
provide a sequence number that MUST also be set to zero by default.
19. Acknowledgements 19. Acknowledgements
Special thanks to Yakov Rekhter for reviewing this draft several Special thanks to Yakov Rekhter for reviewing this draft several
times and providing valuable comments and for his very engaging times and providing valuable comments and for his very engaging
discussions on several topics of this draft that helped shape this discussions on several topics of this draft that helped shape this
document. We would also like to thank Pedro Marques, Kaushik Ghosh, document. We would also like to thank Pedro Marques, Kaushik Ghosh,
Nischal Sheth, Robert Raszuk, Amit Shukla, and Nadeem Mohammed for Nischal Sheth, Robert Raszuk, Amit Shukla, and Nadeem Mohammed for
discussions that helped shape this document. We would also like to discussions that helped shape this document. We would also like to
thank Han Nguyen for his comments and support of this work. We would thank Han Nguyen for his comments and support of this work. We would
also like to thank Steve Kensil and Reshad Rahman for their reviews. also like to thank Steve Kensil and Reshad Rahman for their reviews.
skipping to change at page 48, line 47 skipping to change at page 48, line 47
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 continous false
MAC mobility can be prevented. The mechanism described in section MAC mobility can be prevented. The mechanism described in section
15.2, shows how MAC addresses can be pinned to a given Ethernet 15.2, shows how MAC addresses can be pinned to a given Ethernet
Segment, such that if they appear behind any other Ethernet Segments, Segment, such that if they appear behind any other Ethernet Segments,
the traffic for those MAC addresses be prevented from entering the the traffic for those MAC addresses be prevented from entering the
EVPN network from the other Ethernet Segments. EVPN network from the other Ethernet Segments.
21. Co-authors 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
Yakov Rekhter Yakov Rekhter
Ravi Shekhar Ravi Shekhar
Juniper Networks Juniper Networks
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
Sub-Type of 0x00 for EVPN MAC Mobility Extended Community.
IANA allocated a new transitive extended community Type of 0x06 and
Sub-Type of 0x01 for EVPN ESI Label Extended Community.
IANA allocated a new transitive extended community Type of 0x06 and
Sub-Type of 0x02 for EVPN ES-Import Route Target.
For EVPN NLRI (with AFI=25, SAFI = 70), the following route types are
requested from IANA: 1 - Ethernet Auto-Discovery (A-D) route
2 - MAC/IP advertisement route 3 - Inclusive Multicast Ethernet
Tag Route 4 - Ethernet Segment Route
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 13 skipping to change at page 50, line 27
vpls-mcast-14.txt, July 2013. vpls-mcast-14.txt, July 2013.
[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
PSN", RFC 4385, February 2006
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
 End of changes. 54 change blocks. 
118 lines changed or deleted 144 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/