draft-ietf-l2vpn-evpn-02.txt   draft-ietf-l2vpn-evpn-03.txt 
skipping to change at page 1, line 19 skipping to change at page 1, line 19
W. Henderickx W. Henderickx
S. Boutros F. Balus S. Boutros F. Balus
K. Patel Alcatel-Lucent K. Patel Alcatel-Lucent
S. Salam S. Salam
Cisco Aldrin Isaac Cisco Aldrin Isaac
Bloomberg Bloomberg
J. Drake J. Drake
R. Shekhar J. Uttaro R. Shekhar J. Uttaro
Juniper Networks AT&T Juniper Networks AT&T
Expires: April 22, 2013 October 22, 2012 Expires: August 25, 2013 February 25, 2013
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-02 draft-ietf-l2vpn-evpn-03
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 28 skipping to change at page 2, line 28
(E-VPN). (E-VPN).
Table of Contents Table of Contents
1. Specification of requirements . . . . . . . . . . . . . . . . . 5 1. Specification of requirements . . . . . . . . . . . . . . . . . 5
2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5. BGP MPLS Based E-VPN Overview . . . . . . . . . . . . . . . . . 6 5. BGP MPLS Based E-VPN Overview . . . . . . . . . . . . . . . . . 6
6. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7 6. Ethernet Segment . . . . . . . . . . . . . . . . . . . . . . . 7
7. Ethernet Tag . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Ethernet Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 9 7.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 9
7.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 9 7.2 VLAN Bundle Service Interface . . . . . . . . . . . . . . . 9
7.2.1 Port Based Service Interface . . . . . . . . . . . . . . 9 7.2.1 Port Based Service Interface . . . . . . . . . . . . . . 10
7.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 9 7.3 VLAN Aware Bundle Service Interface . . . . . . . . . . . . 10
7.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 10 7.3.1 Port Based VLAN Aware Service Interface . . . . . . . . 10
8. BGP E-VPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . 10 8. BGP E-VPN NLRI . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 11 8.1. Ethernet Auto-Discovery Route . . . . . . . . . . . . . . . 11
8.2. MAC Advertisement Route . . . . . . . . . . . . . . . . . 11 8.2. MAC Advertisement Route . . . . . . . . . . . . . . . . . 12
8.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 11 8.3. Inclusive Multicast Ethernet Tag Route . . . . . . . . . . 12
8.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 12 8.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 13
8.5 ESI MPLS Label Extended Community . . . . . . . . . . . . . 12 8.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 13
8.6 ES-Import Extended Community . . . . . . . . . . . . . . . . 13 8.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 14
8.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 13 8.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 14
8.8 Default Gateway Extended Community . . . . . . . . . . . . . 13 8.8 Default Gateway Extended Community . . . . . . . . . . . . . 15
9. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 14 9. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 15
9.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 14 9.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 15
9.1.1 Constructing the Ethernet Segment Route . . . . . . . . 14 9.1.1 Constructing the Ethernet Segment Route . . . . . . . . 15
9.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 14 9.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1 Constructing the Ethernet A-D Route per Ethernet 9.2.1 Constructing the Ethernet A-D Route per Ethernet
Segment . . . . . . . . . . . . . . . . . . . . . . . . 15 Segment . . . . . . . . . . . . . . . . . . . . . . . . 16
9.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 16 9.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 17
9.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 16 9.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 17
9.3.1 ESI MPLS Label Assignment . . . . . . . . . . . . . . . 16 9.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 18
9.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 17 9.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 18
9.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 17 9.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 19
9.3.1.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . 18 9.3.1.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . 20
9.4 Aliasing . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 20
9.4.1 Constructing the Ethernet A-D Route per EVI . . . . . . 19 9.4.1 Constructing the Ethernet A-D Route per EVI . . . . . . 21
9.4.1.1 Ethernet A-D Route Targets . . . . . . . . . . . . . 20 9.4.1.1 Ethernet A-D Route Targets . . . . . . . . . . . . . 22
9.5 Designated Forwarder Election . . . . . . . . . . . . . . . 20 9.5 Designated Forwarder Election . . . . . . . . . . . . . . . 22
9.5.1 Default DF Election Procedure . . . . . . . . . . . . . 22 10. Determining Reachability to Unicast MAC Addresses . . . . . . 24
9.5.2 DF Election with Service Carving . . . . . . . . . . . . 22 10.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 25
10. Determining Reachability to Unicast MAC Addresses . . . . . . 23 10.2. Remote learning . . . . . . . . . . . . . . . . . . . . . 25
10.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 23 10.2.1. Constructing the BGP E-VPN MAC Address Advertisement . 25
10.2. Remote learning . . . . . . . . . . . . . . . . . . . . . 24 10.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . 27
10.2.1. Constructing the BGP E-VPN MAC Address Advertisement . 24 11. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 29
11.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 26 12. Handling of Multi-Destination Traffic . . . . . . . . . . . . 29
12. Handling of Multi-Destination Traffic . . . . . . . . . . . . 27
12.1. Construction of the Inclusive Multicast Ethernet Tag 12.1. Construction of the Inclusive Multicast Ethernet Tag
Route . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 30
12.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 28 12.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 30
13. Processing of Unknown Unicast Packets . . . . . . . . . . . . 29 13. Processing of Unknown Unicast Packets . . . . . . . . . . . . 31
13.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 30 13.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 32
13.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 30 13.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 32
14. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 30 14. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 32
14.1. Forwarding packets received from a CE . . . . . . . . . . 30 14.1. Forwarding packets received from a CE . . . . . . . . . . 32
14.2. Forwarding packets received from a remote PE . . . . . . . 31 14.2. Forwarding packets received from a remote PE . . . . . . . 34
14.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 31 14.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 34
14.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 32 14.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 34
15. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 32 15. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 34
15.1. Load balancing of traffic from an PE to remote CEs . . . . 32 15.1. Load balancing of traffic from an PE to remote CEs . . . . 34
15.1.1 Active-Standby Redundancy Mode . . . . . . . . . . . . 32 15.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 34
15.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 33 15.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 35
15.2. Load balancing of traffic between an PE and a local CE . . 35 15.2. Load balancing of traffic between an PE and a local CE . . 37
15.2.1. Data plane learning . . . . . . . . . . . . . . . . . 35 15.2.1. Data plane learning . . . . . . . . . . . . . . . . . 37
15.2.2. Control plane learning . . . . . . . . . . . . . . . . 35 15.2.2. Control plane learning . . . . . . . . . . . . . . . . 37
16. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 35 16. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 37
17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 37 16.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 39
17.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 37 17. Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . 39
17.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 37 17.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 40
17.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 37 17.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 40
17.3.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 38 17.3. MP2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 40
17.3.2. Selective Trees . . . . . . . . . . . . . . . . . . . 38 17.3.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 40
17.4. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 39 17.3.2. Selective Trees . . . . . . . . . . . . . . . . . . . 41
18. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 39 17.4. Explicit Tracking . . . . . . . . . . . . . . . . . . . . 42
18.1. Transit Link and Node Failures between PEs . . . . . . . . 39 18. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 39 18.1. Transit Link and Node Failures between PEs . . . . . . . . 42
18.2.1. Local Repair . . . . . . . . . . . . . . . . . . . . . 40 18.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 42
18.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 40 18.2.1. Local Repair . . . . . . . . . . . . . . . . . . . . . 42
19. LACP State Synchronization . . . . . . . . . . . . . . . . . . 40 18.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 42
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 19. LACP State Synchronization . . . . . . . . . . . . . . . . . . 43
21. Security Considerations . . . . . . . . . . . . . . . . . . . 42 20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 21. Security Considerations . . . . . . . . . . . . . . . . . . . 44
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
23.1 Normative References . . . . . . . . . . . . . . . . . . . 42 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
23.2 Informative References . . . . . . . . . . . . . . . . . . 42 23.1 Normative References . . . . . . . . . . . . . . . . . . . 44
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 43 23.2 Informative References . . . . . . . . . . . . . . . . . . 45
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 45
1. Specification of requirements 1. 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. Contributors 2. Contributors
In addition to the authors listed above, the following individuals In addition to the authors listed above, the following individuals
skipping to change at page 5, line 38 skipping to change at page 5, line 38
This document describes procedures for BGP MPLS based Ethernet VPNs This document describes procedures for BGP MPLS based Ethernet VPNs
(E-VPN). The procedures described here are intended to meet the (E-VPN). The procedures described here are intended to meet the
requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for requirements specified in [EVPN-REQ]. Please refer to [EVPN-REQ] for
the detailed requirements and motivation. E-VPN requires extensions the detailed requirements and motivation. E-VPN requires extensions
to existing IP/MPLS protocols as described in this document. In to existing IP/MPLS protocols as described in this document. In
addition to these extensions E-VPN uses several building blocks from addition to these extensions E-VPN uses several building blocks from
existing MPLS technologies. existing MPLS technologies.
4. Terminology 4. Terminology
All-Active Mode: When a device is multi-homed to two or more PEs and
when all PEs in such redundancy group can forward traffic to/from the
multi-homed device for a given VLAN, then such multi-homing or
redundancy is referred to as "All-Active".
CE: Customer Edge device e.g., host or router or switch CE: Customer Edge device e.g., host or router or switch
E-VPN Instance (EVI): An E-VPN routing and forwarding instance on a E-VPN Instance (EVI): An E-VPN routing and forwarding instance on a
PE. PE.
Ethernet segment identifier (ESI): If a CE is multi-homed to two or Ethernet segment identifier (ESI): If a CE is multi-homed to two or
more PEs, the set of Ethernet links that attaches the CE to the PEs more PEs, the set of Ethernet links that attaches the CE to the PEs
is an 'Ethernet segment'. Ethernet segments MUST have a unique non- is an 'Ethernet segment'. Ethernet segments MUST have a unique non-
zero identifier, the 'Ethernet Segment Identifier'. zero identifier, the 'Ethernet Segment Identifier'.
skipping to change at page 6, line 15 skipping to change at page 6, line 21
corresponding Ethernet tag. corresponding Ethernet tag.
Link Aggregation Control Protocol (LACP): Link Aggregation Control Protocol (LACP):
Multipoint to Multipoint (MP2MP): Multipoint to Multipoint (MP2MP):
Point to Multipoint (P2MP): Point to Multipoint (P2MP):
Point to Point (P2P): Point to Point (P2P):
Single-Active Mode: When a device or a network is multi-homed to two
or more PEs and when only a single PE in such redundancy group can
forward traffic to/from the multi-homed device or network for a given
VLAN, then such multi-homing or redundancy is referred to as "Single-
Active".
5. BGP MPLS Based E-VPN Overview 5. BGP MPLS Based E-VPN Overview
This section provides an overview of E-VPN. This section provides an overview of E-VPN.
An E-VPN comprises CEs that are connected to PEs that form the edge An E-VPN comprises 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. of the MPLS infrastructure. A CE may be a host, a router or a switch.
The PEs provide virtual Layer 2 bridged connectivity between the CEs. The PEs provide virtual Layer 2 bridged connectivity between the CEs.
There may be multiple E-VPNs in the provider's network. There may be multiple E-VPNs 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
skipping to change at page 7, line 31 skipping to change at page 7, line 42
given EVI use the same VLAN, and no other EVI uses this VLAN. This given EVI use the same VLAN, and no other EVI uses this VLAN. This
document refers to this case as a "Unique VLAN E-VPN" and describes document refers to this case as a "Unique VLAN E-VPN" and describes
simplified procedures to optimize for it. simplified procedures to optimize for it.
6. Ethernet Segment 6. 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. A single-homed CE is considered to encoded as a ten octets integer. The following two ESI values are
be attached to an Ethernet segment with ESI 0. Otherwise, an Ethernet reserved:
segment MUST have a unique non-zero ESI. The ESI can be assigned
using various mechanisms:
1. The ESI may be configured. For instance when E-VPNs are used to
provide a VPLS service the ESI is fairly analogous to the Multi-
homing site ID in [BGP-VPLS-MH].
2. If IEEE 802.1AX LACP is used between the PEs and CEs, then - ESI 0 denotes a single-homed CE.
- ESI {0xFF} (repeated 10 times) is known as MAX-ESI and is reserved.
In general, an Ethernet segment MUST have a non-reserved ESI that is
unique network wide (e.g., across all EVPNs on all the PEs). If the
CE(s) constituting an Ethernet Segment is (are) managed by the
network operator, then ESI uniqueness should be guranteed; however,
if the CE(s) is (are) not managed, then the operator MUST configure a
network-wide unique ESI for that Ethernet Segment. This is required
to enable auto-discovery of Ethernet Segments and DF election. The
ESI can be assigned using various mechanisms:
1. If IEEE 802.1AX LACP is used between the PEs and CEs, then
the ESI is determined from LACP by concatenating the following the ESI is determined from LACP by concatenating the following
parameters: parameters:
+ CE LACP System Identifier comprised of two octets of System + CE LACP System Identifier comprised of two octets of System
Priority and six octets of System MAC address, where the Priority and six octets of System MAC address, where the
System Priority is encoded in the most significant two octets. System Priority is encoded in the most significant two octets.
The CE LACP identifier MUST be encoded in the high order eight The CE LACP identifier MUST be encoded in the high order eight
octets of the ESI. octets of the ESI.
+ 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 low order two octets of the ESI. encoded in the low order two octets of the ESI.
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.
3. If LLDP is used between the PEs and CEs that are hosts, then This mechanism could be used only if it produces ESIs that satisfy
the uniqueness requirement specified above.
2. If LLDP is used between the PEs and CEs that are hosts, then
the ESI is determined by LLDP. The ESI will be specified in a the ESI is determined by LLDP. The ESI will be specified in a
following version. following version.
4. In the case of indirectly connected hosts via a bridged LAN This mechanism could be used only if it produces ESIs that satisfy
the uniqueness requirement specified above.
3. In the case of indirectly connected hosts via a bridged LAN
between the CEs and the PEs, the ESI is determined based on the between the CEs and the PEs, the ESI is determined based on the
Layer 2 bridge protocol as follows: If MST is used in the bridged Layer 2 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 LAN then the value of the ESI is derived by listening to BPDUs on
the Ethernet segment. To achieve this the PE is not required to the Ethernet segment. To achieve this the PE is not required to
run MST. However the PE must learn the Root Bridge MAC address run MST. However the PE must learn the Root Bridge MAC address
and Bridge Priority of the root of the Internal Spanning Tree and Bridge Priority of the root of the Internal Spanning Tree
(IST) by listening to the BPDUs. The ESI is constructed as (IST) by listening to the BPDUs. The ESI is constructed as
follows: follows:
{Bridge Priority (16 bits) , Root Bridge MAC Address (48 bits)} {Bridge Priority (16 bits) , Root Bridge MAC Address (48 bits)}
This mechanism could be used only if it produces ESIs that satisfy
the uniqueness requirement specified above.
4. The ESI may be configured.
7. Ethernet Tag 7. Ethernet Tag
An Ethernet Tag identifies a particular broadcast domain, e.g. a An Ethernet Tag identifies a particular broadcast domain, e.g. a
VLAN, in an EVI. An EVI consists of one or more broadcast domains. VLAN, in an EVI. An EVI consists of one or more broadcast domains.
Ethernet Tags are assigned to the broadcast domains of a given EVI by Ethernet Tags are assigned to the broadcast domains of a given EVI by
the provider of the E-VPN service. Each PE, in a given EVI, performs the provider of the E-VPN service. Each PE, in a given EVI, performs
a mapping between the Ethernet Tag and the corresponding broadcast a mapping between the Ethernet Tag and the corresponding broadcast
domain identifier(s) understood by each of its attached CEs (e.g. CE domain identifier(s) understood by each of its attached CEs (e.g. CE
VLAN Identifiers or CE-VIDs). VLAN Identifiers or CE-VIDs).
skipping to change at page 10, line 43 skipping to change at page 11, line 30
+ 1 - Ethernet Auto-Discovery (A-D) route + 1 - Ethernet Auto-Discovery (A-D) route
+ 2 - MAC advertisement route + 2 - MAC advertisement route
+ 3 - Inclusive Multicast Route + 3 - Inclusive Multicast Route
+ 4 - Ethernet Segment Route + 4 - Ethernet Segment Route
The detailed encoding and procedures for these route types are The detailed encoding and procedures for these route types are
described in subsequent sections. described in subsequent sections.
The E-VPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol The E-VPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol
Extensions [RFC4760] with an AFI of TBD and an SAFI of E-VPN (To be Extensions [RFC4760] with an AFI of 25 (L2VPN) and a SAFI of 70 (E-
assigned by IANA). The NLRI field in the VPN). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute
MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the E-VPN NLRI contains the E-VPN NLRI (encoded as specified above).
(encoded as specified above).
In order for two BGP speakers to exchange labeled E-VPN NLRI, they In order for two BGP speakers to exchange labeled E-VPN NLRI, they
must use BGP Capabilities Advertisement to ensure that they both are must use BGP Capabilities Advertisement to ensure that they both are
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 TBD and an SAFI of E-VPN. AFI of 25 (L2VPN) and a SAFI of 70 (E-VPN).
8.1. Ethernet Auto-Discovery Route 8.1. Ethernet Auto-Discovery Route
A Ethernet A-D route type specific E-VPN NLRI consists of the A Ethernet A-D route type specific E-VPN NLRI consists of the
following: following:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
skipping to change at page 11, line 46 skipping to change at page 12, line 41
+---------------------------------------+ +---------------------------------------+
| MAC Address (6 octets) | | MAC Address (6 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| IP Address (4 or 16 octets) | | IP Address (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
| MPLS Label (3 octets) | | MPLS Label (3 octets) |
+---------------------------------------+ +---------------------------------------+
For the purpose of BGP route key processing, only the Ethernet Tag
ID, MAC Address Length, MAC Address, IP Address Length, and IP
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
treated as route attributes as opposed to being part of the "route".
For procedures and usage of this route please see section 10 For procedures and usage of this route please see section 10
"Determining Reachability to Unicast MAC Addresses" and section 15 "Determining Reachability to Unicast MAC Addresses" and section 15
"Load Balancing of Unicast Packets". "Load Balancing of Unicast Packets".
8.3. Inclusive Multicast Ethernet Tag Route 8.3. Inclusive Multicast Ethernet Tag Route
An Inclusive Multicast Ethernet Tag route type specific E-VPN NLRI An Inclusive Multicast Ethernet Tag route type specific E-VPN NLRI
consists of the following: consists of the following:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
skipping to change at page 12, line 36 skipping to change at page 13, line 37
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
For procedures and usage of this route please see section 9.5 For procedures and usage of this route please see section 9.5
"Designated Forwarder Election". "Designated Forwarder Election".
8.5 ESI MPLS Label Extended Community 8.5 ESI Label Extended Community
This extended community is a new transitive extended community. It This extended community is a new transitive extended community with
may be advertised along with Ethernet Auto-Discovery routes and it the Type field is 0x06, and the Sub-Type of 0x01. It may be
enables split-horizon procedures for multi-homed sites as described advertised along with Ethernet Auto-Discovery routes and it enables
in section 9.3 "Split Horizon". split-horizon procedures for multi-homed sites as described in
section 9.3 "Split Horizon".
Each ESI MPLS Label Extended Community is encoded as a 8-octet value Each ESI Label Extended Community is encoded as a 8-octet value as
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x44 | Sub-Type | Flags (One Octet) |Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags (One Octet) |Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0| ESI MPLS label | | Reserved = 0| ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low order bit of the flags octet is defined as the "Active- The low order bit of the flags octet is defined as the "Active-
Standby" bit and may be set to 1. A value of 0 means that the multi- Standby" bit and may be set to 1. A value of 0 means that the multi-
homed site is operating in Active-Active mode; whereas, a value of 1 homed site is operating in All-Active mode; whereas, a value of 1
means that the multi-homed site is operating in Active-Standby mode. means that the multi-homed site is operating in Single-Active mode.
The second low order bit of the flags octet is defined as the "Root- The second low order bit of the flags octet is defined as the "Root-
Leaf". A value of 0 means that this label is associated with a Root Leaf". A value of 0 means that this label is associated with a Root
site; whereas, a value of 1 means that this label is associate with a site; whereas, a value of 1 means that this label is associate with a
Leaf site. The other bits must be set to 0. Leaf site. The other bits must be set to 0.
8.6 ES-Import Extended Community 8.6 ES-Import Route Target
This is a new transitive extended community carried with the Ethernet This is a new transitive Route Target extended community carried with
Segment route. When used, it enables all the PEs connected to the the Ethernet Segment route. When used, it enables all the PEs
same multi-homed site to import the Ethernet Segment routes. The connected to the same multi-homed site to import the Ethernet Segment
value is derived automatically from the ESI by encoding the 6-byte routes. The value is derived automatically from the ESI by encoding
MAC address portion of the ESI in the ES-Import Extended Community. the 6-byte MAC address portion of the ESI in the ES-Import Route
The format of this extended community is as follows: Target. The format of this extended community is as 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x44 | Sub-Type | 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
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
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
0x06 indicates that the structure of this RT is a six bytes value
(e.g., a MAC address). A BGP speaker that implements RT-Constrain
(RFC4684) MUST apply the RT-Constrain procedures to the ES-import RT
as-well.
For procedures and usage of this attribute, please see section 9.1 For procedures and usage of this attribute, please see section 9.1
"Redundancy Group Discovery". "Redundancy Group Discovery".
8.7 MAC Mobility Extended Community 8.7 MAC Mobility Extended Community
This extended community is a new transitive extended community with
This extended community is a new transitive extended community. It the Type field of 0x06 and the Sub-Type of 0x00. It may be advertised
may be advertised along with MAC Advertisement routes. The procedures along with MAC Advertisement routes. The procedures for using this
for using this Extended Community are described in section 16 "MAC Extended Community are described in section 16 "MAC Mobility".
Mobility".
The MAC Mobility Extended Community is encoded as a 8-octet value as The MAC Mobility 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x44 | Sub-Type | Reserved=0 | | Type=0x06 | Sub-Type=0x00 | Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.8 Default Gateway Extended Community 8.8 Default Gateway Extended Community
The Default Gateway community is an Extended Community of an Opaque The Default Gateway community is an Extended Community of an Opaque
Type (see 3.3 of rfc4360). It is a transitive community, which means Type (see 3.3 of rfc4360). It is a transitive community, which means
that the first octet is 0x03. The value of the second octet (Sub- that the first octet is 0x03. The value of the second octet (Sub-
Type) is 0x030d (Default Gateway) as defined by IANA. The Value field Type) is 0x030d (Default Gateway) as defined by IANA. The Value field
of this community is reserved (set to 0 by the senders, ignored by of this community is reserved (set to 0 by the senders, ignored by
the receivers). the receivers).
9. Multi-homing Functions 9. Multi-homing Functions
This section discusses the functions, procedures and associated BGP This section discusses the functions, procedures and associated BGP
skipping to change at page 15, line 32 skipping to change at page 16, line 50
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).
9.2.1 Constructing the Ethernet A-D Route per Ethernet Segment 9.2.1 Constructing the Ethernet A-D Route per Ethernet Segment
This section describes procedures to construct the Ethernet A-D route This section describes procedures to construct the Ethernet A-D route
when a single such route is advertised by an PE for a given Ethernet when a single such route is advertised by an PE for a given Ethernet
Segment. This flavor of the Ethernet A-D route is used for fast Segment. This flavor of the Ethernet A-D route is used for fast
convergence (as discussed above) as well as for advertising the ESI convergence (as discussed above) as well as for advertising the ESI
MPLS label used for split-horizon filtering (as discussed in section label used for split-horizon filtering (as discussed in section 9.3).
9.2). Support of this route flavor is MANDATORY. Support of this route flavor is MANDATORY.
Route-Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The value 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. The reason for such encoding is that the RD address) followed by 0.
cannot be that of a given EVI since the ESI can span across one or
more EVIs.
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". This document does not described in section "Ethernet Segment". This document does not
specify the use of the Ethernet A-D route when the Segment Identifier specify the use of the Ethernet A-D route when the Segment Identifier
is set to 0. is set to 0.
The Ethernet Tag ID MUST be set to 0. The Ethernet Tag ID MUST be set to 0.
The MPLS label in the NLRI MUST be set to 0. The MPLS label in the NLRI MUST be set to 0.
The "ESI MPLS Label Extended Community" MUST be included in the The "ESI Label Extended Community" MUST be included in the route. If
route. If all-active multi-homing is desired, then the "Active- all-Active multi-homing is desired, then the "Active-Standby" bit in
Standby" bit in the flags of the ESI MPLS Label Extended Community the flags of the ESI Label Extended Community MUST be set to 0 and
MUST be set to 0 and the MPLS label in that extended community MUST the MPLS label in that extended community MUST be set to a valid MPLS
be set to a valid MPLS label value. The MPLS label in this Extended label value. The MPLS label in this Extended Community is referred to
Community is referred to as an "ESI label". This label MUST be a as an "ESI label". This label MUST be a downstream assigned MPLS
downstream assigned MPLS label if the advertising PE is using ingress label if the advertising PE is using ingress replication for
replication for receiving multicast, broadcast or unknown unicast receiving multicast, broadcast or unknown unicast traffic from other
traffic from other PEs. If the advertising PE is using P2MP MPLS LSPs PEs. If the advertising PE is using P2MP MPLS LSPs for sending
for sending multicast, broadcast or unknown unicast traffic, then multicast, broadcast or unknown unicast traffic, then this label MUST
this label MUST be an upstream assigned MPLS label. The usage of this be an upstream assigned MPLS label. The usage of this label is
label is described in section 9.2. described in section 9.3.
If the Ethernet Segment is connected to more than one PE and active- If the Ethernet Segment is connected to more than one PE and Single-
standby multi-homing is desired, then the "Active-Standby" bit in the Active multi-homing is desired, then the "Active-Standby" bit in the
flags of the ESI MPLS Label Extended Community MUST be set to 1. flags of the ESI Label Extended Community MUST be set to 1 and ESI
label MUST be set to zero.
9.2.1.1. Ethernet A-D Route Targets 9.2.1.1. Ethernet A-D Route Targets
The Ethernet A-D route MUST carry one or more Route Target (RT) The Ethernet A-D route MUST carry one or more Route Target (RT)
attributes. These RTs MUST be the set of RTs associated with all the attributes. These RTs MUST be the set of RTs associated with all the
EVIs to which the Ethernet Segment, corresponding to the Ethernet A-D EVIs to which the Ethernet Segment, corresponding to the Ethernet A-D
route, belongs. route, belongs.
9.3 Split Horizon 9.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. If the CE sends a multicast, broadcast or unknown segment ES1 operating in All-Active mode. If the CE sends a
unicast packet to a particular PE, say PE1, then PE1 will forward broadcast, unknown unicast, or multicast (BUM) packet to one of the
that packet to all or subset of the other PEs in the EVI. In this non-DF (Designated Forwarder) PEs, say PE1, then PE1 will forward
case the PEs, other than PE1, that the CE is multi-homed to MUST drop that packet to all or subset of the other PEs in the EVI including
the packet and not forward back to the CE. This is referred to as the DF PE for that Ethernet segment. In this case the DF PE that the
"split horizon" filtering in this document. CE is multi-homed to MUST drop the packet and not forward back to the
CE. This filtering is referred to as "split horizon" filtering in
this document.
In order to achieve this split horizon function, every multicast, In order to achieve this split horizon function, every BUM packet
broadcast or unknown unicast packet is encapsulated with an MPLS originating from a non-DF PE is encapsulated with an MPLS label that
label that identifies the Ethernet segment of origin (i.e. the identifies the Ethernet segment of origin (i.e. the segment from
segment from which the frame entered the E-VPN network). This label which the frame entered the E-VPN network). This label is referred to
is referred to as the ESI MPLS label, and is distributed using the as the ESI label, and MUST be distributed by all PEs when operating
"Ethernet A-D route per Ethernet Segment" as per the procedures in in All-Active multi-homing mode using the "Ethernet A-D route per
section 9.1.1 above. This route is imported by the PEs connected to Ethernet Segment" as per the procedures in section 9.2.1 above. This
the Ethernet Segment and also by the PEs that have at least one EVI route is imported by the PEs connected to the Ethernet Segment and
in common with the Ethernet Segment in the route. As described in also by the PEs that have at least one EVI in common with the
section 9.1.1, the route MUST carry an ESI MPLS Label Extended Ethernet Segment in the route. As described in section 9.1.1, the
Community with a valid ESI MPLS label. The disposition PEs rely on route MUST carry an ESI Label Extended Community with a valid ESI
the value of the ESI MPLS label to determine whether or not a flooded label. The disposition DF PE rely on the value of the ESI label to
frame is allowed to egress a specific Ethernet segment. determine whether or not a BUM frame is allowed to egress a specific
Ethernet segment. It should be noted that if the BUM frame is
originated from the DF PE operating in All-Active multi-homing mode,
then the DF PE MAY not encapsulate the frame with the ESI label.
Furthermore, if the multi-homed PEs operate in active/standby mode,
then the packet MUST not be encapsulated with the ESI label and the
label value MUST be set to zero in ESI Label Extended Community per
section 9.2.1 above.
9.3.1 ESI Label Assignment
9.3.1 ESI MPLS Label Assignment
The following subsections describe the assignment procedures for the The following subsections describe the assignment procedures for the
ESI MPLS label, which differ depending on the type of tunnels being ESI label, which differ depending on the type of tunnels being used
used to deliver multi-destination packets in the E-VPN network. to deliver multi-destination packets in the E-VPN network.
9.3.1.1 Ingress Replication 9.3.1.1 Ingress Replication
An PE that is using ingress replication for sending broadcast, All PEs operating in an All-Active multi-homing mode that rely on
multicast or unknown unicast traffic, distributes to other PEs, that ingress replication for the reception of BUM traffic, distribute to
belong to the Ethernet segment, a downstream assigned "ESI MPLS other PEs, that belong to the Ethernet segment, a downstream assigned
label" in the Ethernet A-D route. This label MUST be programmed in "ESI label" in the Ethernet A-D route per ESI. This label MUST be
the platform label space by the advertising PE. Further the programmed in the platform label space by the advertising PE. Further
forwarding entry for this label must result in NOT forwarding packets the forwarding entry for this label must result in NOT forwarding
received with this label onto the Ethernet segment that the label was packets received with this label onto the Ethernet segment that the
distributed for. label was distributed for.
Consider PE1 and PE2 that are multi-homed to CE1 on ES1. Further Consider PE1 and PE2 that are multi-homed to CE1 on ES1 and operating
consider that PE1 is using P2P or MP2P LSPs to send packets to PE2. in All-Active multi-homing mode. Further consider that PE1 is using
Consider that PE1 receives a multicast, broadcast or unknown unicast P2P or MP2P LSPs to send packets to PE2. Consider that PE1 is the
packet from CE1 on VLAN1 on ESI1. In this scenario, PE2 distributes non-DF for VLAN1 and PE2 is the DF for VLAN1, and PE1 receives a BUM
an Inclusive Multicast Ethernet Tag route for VLAN1 in the associated packet from CE1 on VLAN1 on ES1. In this scenario, PE2 distributes an
EVI. So, when PE1 sends a multicast, broadcast or unknown unicast Inclusive Multicast Ethernet Tag route for VLAN1 in the associated
packet, that it receives from CE1, it MUST first push onto the MPLS EVI. So, when PE1 sends a BUM packet, that it receives from CE1, it
label stack the ESI label that PE2 has distributed for ESI1. It MUST MUST first push onto the MPLS label stack the ESI label that PE2 has
then push on the MPLS label distributed by PE2 in the Inclusive distributed for ES1. It MUST then push on the MPLS label distributed
Multicast Ethernet Tag route for VLAN1. The resulting packet is by PE2 in the Inclusive Multicast Ethernet Tag route for VLAN1. The
further encapsulated in the P2P or MP2P LSP label stack required to resulting packet is further encapsulated in the P2P or MP2P LSP label
transmit the packet to PE2. When PE2 receives this packet it stack required to transmit the packet to PE2. When PE2 receives this
determines the set of ESIs to replicate the packet to from the top packet, it determines the set of ESIs to replicate the packet to from
MPLS label, after any P2P or MP2P LSP labels have been removed. If the top MPLS label, after any P2P or MP2P LSP labels have been
the next label is the ESI label assigned by PE2 for ESI1, then PE2 removed. If the next label is the ESI label assigned by PE2 for ES1,
MUST NOT forward the packet onto ESI1. then PE2 MUST NOT forward the packet onto ES1. If the next label is
an ESI label which has not been assigned by PE2, then PE2 MUST drop
the packet. It should be noted that in this scenario, if PE2 receives
a BUM traffic for VLAN1 from CE1, then it doesn't need to encapsulate
the packet with an ESI label when sending it to the PE1 since PE1 can
use its DF logic to filter the BUM packets and thus doesn't need to
use split-horizon filtering for ES1.
9.3.1.2. P2MP MPLS LSPs 9.3.1.2. P2MP MPLS LSPs
An PE that is using P2MP LSPs for sending broadcast, multicast or The non-DF PEs operating in an All-Active multi-homing mode that is
unknown unicast traffic, distributes to other PEs, that belong to the using P2MP LSPs for sending BUM traffic, distribute to other PEs,
Ethernet segment or have an E-VPN in common with the Ethernet that belong to the Ethernet segment or have an E-VPN in common with
Segment, an upstream assigned "ESI MPLS label" in the Ethernet A-D the Ethernet Segment, an upstream assigned "ESI label" in the
route. This label is upstream assigned by the PE that advertises the Ethernet A-D route. This label is upstream assigned by the PE that
route. This label MUST be programmed by the other PEs, that are advertises the route. This label MUST be programmed by the other PEs,
connected to the ESI advertised in the route, in the context label that are connected to the ESI advertised in the route, in the context
space for the advertising PE. Further the forwarding entry for this label space for the advertising PE. Further the forwarding entry for
label must result in NOT forwarding packets received with this label this label must result in NOT forwarding packets received with this
onto the Ethernet segment that the label was distributed for. This label onto the Ethernet segment that the label was distributed for.
label MUST also be programmed by the other PEs, that import the route This label MUST also be programmed by the other PEs, that import the
but are not connected to the ESI advertised in the route, in the route but are not connected to the ESI advertised in the route, in
context label space for the advertising PE. Further the forwarding the context label space for the advertising PE. Further the
entry for this label must be a POP with no other associated action. forwarding entry for this label must be a POP with no other
associated action.
Consider PE1 and PE2 that are multi-homed to CE1 on ES1. Also Consider PE1 and PE2 that are multi-homed to CE1 on ES1 and operating
consider PE3 that is in the same EVI as one of the EVIs to which ES1 in All-Active multi-homing mode. Also consider PE3 that is in the
belongs. Further, assume that PE1 is using P2MP MPLS LSPs to send same EVI as one of the EVIs to which ES1 belongs. Further, assume
broadcast, multicast or uknown unicast packets. When PE1 sends a that PE1 which is the non-DF, using P2MP MPLS LSPs to send BUM
multicast, broadcast or unknown unicast packet, that it receives from packets. When PE1 sends a BUM packet, that it receives from CE1, it
CE1, it MUST first push onto the MPLS label stack the ESI label that MUST first push onto the MPLS label stack the ESI label that it has
it has assigned for the ESI that the packet was received on. The assigned for the ESI that the packet was received on. The resulting
resulting packet is further encapsulated in the P2MP MPLS label stack packet is further encapsulated in the P2MP MPLS label stack necessary
necessary to transmit the packet to the other PEs. Penultimate hop to transmit the packet to the other PEs. Penultimate hop popping MUST
popping MUST be disabled on the P2MP LSPs used in the MPLS transport be disabled on the P2MP LSPs used in the MPLS transport
infrastructure for E-VPN. When PE2 receives this packet, it de- infrastructure for E-VPN. When PE2 receives this packet, it de-
capsulates the top MPLS label and forwards the packet using the capsulates the top MPLS label and forwards the packet using the
context label space determined by the top label. If the next label is context label space determined by the top label. If the next label is
the ESI label assigned by PE1 to ESI1, then PE2 MUST NOT forward the the ESI label assigned by PE1 to ES1, then PE2 MUST NOT forward the
packet onto ESI1. When PE3 receives this packet, it de-capsulates the packet onto ES1. When PE3 receives this packet, it de-capsulates the
top MPLS label and forwards the packet using the context label space top MPLS label and forwards the packet using the context label space
determined by the top label. If the next label is the ESI label determined by the top label. If the next label is the ESI label
assigned by PE1 to ESI1 and PE3 is not connected to ESI1, then PE3 assigned by PE1 to ES1 and PE3 is not connected to ES1, then PE3 MUST
MUST pop the label and flood the packet over all local ESIs in the pop the label and flood the packet over all local ESIs in the EVI. It
EVI. should be noted that when PE2 sends a BUM frame over a P2MP LSP, it
does not need to encapsulate the frame with an ESI label because it
is the DF for that VLAN.
9.3.1.3. MP2MP LSPs 9.3.1.3. MP2MP LSPs
The procedures for ESI MPLS Label assignment and usage for MP2MP LSPs The procedures for ESI Label assignment and usage for MP2MP LSPs will
will be described in a future version. be described in a future version.
9.4 Aliasing 9.4 Aliasing and Backup-Path
In the case where a CE is multi-homed to multiple PE nodes, using a In the case where a CE is multi-homed to multiple PE nodes, using a
LAG with all-active redundancy, it is possible that only a single PE LAG with All-Active redundancy, it is possible that only a single PE
learns a set of the MAC addresses associated with traffic transmitted learns a set of the MAC addresses associated with traffic transmitted
by the CE. This leads to a situation where remote PE nodes receive by the CE. This leads to a situation where remote PE nodes receive
MAC advertisement routes, for these addresses, from a single PE even MAC advertisement routes, for these addresses, from a single PE even
though multiple PEs are connected to the multi-homed segment. As a though multiple PEs are connected to the multi-homed segment. As a
result, the remote PEs are not able to effectively load-balance result, the remote PEs are not able to effectively load-balance
traffic among the PE nodes connected to the multi-homed Ethernet traffic among the PE nodes connected to the multi-homed Ethernet
segment. This could be the case, for e.g. when the PEs perform data- segment. This could be the case, for e.g. when the PEs perform data-
path learning on the access, and the load-balancing function on the path learning on the access, and the load-balancing function on the
CE hashes traffic from a given source MAC address to a single PE. CE hashes traffic from a given source MAC address to a single PE.
Another scenario where this occurs is when the PEs rely on control Another scenario where this occurs is when the PEs rely on control
plane learning on the access (e.g. using ARP), since ARP traffic will plane learning on the access (e.g. using ARP), since ARP traffic will
be hashed to a single link in the LAG. be hashed to a single link in the LAG.
To alleviate this issue, E-VPN introduces the concept of 'Aliasing'. To alleviate this issue, E-VPN introduces the concept of 'Aliasing'.
Aliasing refers to the ability of an PE to signal that it has Aliasing refers to the ability of a PE to signal that it has
reachability to a given locally attached Ethernet segment, even when reachability to a given locally attached Ethernet segment, even when
it has learnt no MAC addresses from that segment. The Ethernet A-D it has learnt no MAC addresses from that segment. The Ethernet A-D
route per EVI is used to that end. Remote PEs which receive MAC route per EVI is used to that end. Remote PEs which receive MAC
advertisement routes with non-zero ESI SHOULD consider the advertised advertisement routes with non-reserved ESI SHOULD consider the
MAC address as reachable via all PEs which have advertised advertised MAC address as reachable via all PEs which have advertised
reachability to the relevant Segment using Ethernet A-D routes with reachability to the relevant Segment using: (1) Ethernet A-D routes
the same ESI (and Ethernet Tag if applicable). per EVI with the same ESI (and Ethernet Tag if applicable) AND
(2)Ethernet A-D routes per ESI with the same ESI and with the
Active/Standby bit set to 0 in the ESI Label Extended Community.
This flavor of Ethernet A-D route associated with aliasing can arrive This flavor of Ethernet A-D route per EVI, associated with aliasing,
at target PEs asynchronously relative to the flavor of Ethernet A-D can arrive at target PEs asynchronously relative to the flavor of
route associated with split-horizon and mass-withdraw. Therefore, if Ethernet A-D route associated with split-horizon and mass-withdraw
Ether A-D route associated with aliasing arrives ahead of the route (i.e. per ESI). Therefore, if the Ethernet A-D route per EVI arrives
associated with mass-withdraw, then former must NOT be processed into ahead of the Ethernet A-D route per ESI, then the former must NOT be
the FIB till the latter arrives. This will take care of corner cases used for traffic forwarding till the latter arrives. This will take
and race conditions where the Ether A-D route associated with mass- care of corner cases and race conditions where the Ethernet A-D route
withdraw is withdrawn but a PE still receives the route associated associated with mass-withdraw is withdrawn but a PE still receives
with aliasing routes. the route associated with aliasing.
Backup-Path is a closely related function, albeit it applies to the
case where the redundancy mode is Active/Standby. In this case, the
PE advertises that it has reachability to a given locally attached
Ethernet Segment using the Ethernet A-D route as well. Remote PEs
which receive the MAC advertisement routes, with non-reserved ESI,
MUST consider the MAC address as reachable via the advertising PE.
Furthermore, the remote PEs SHOULD install a Backup-Path, for said
MAC, to the PE which had advertised reachability to the relevant
Segment using (1) an Ethernet A-D routes per EVI with the same ESI
(and Ethernet Tag if applicable) AND (2)Ethernet A-D routes per ESI
with the same ESI and with the Active/Standby bit set to 1 in the ESI
Label Extended Community.
9.4.1 Constructing the Ethernet A-D Route per EVI 9.4.1 Constructing the Ethernet A-D Route per EVI
This section describes procedures to construct the Ethernet A-D route This section describes procedures to construct the Ethernet A-D route
when one or more such routes are advertised by an PE for a given EVI. when one or more such routes are advertised by an PE for a given EVI.
This flavor of the Ethernet A-D route is used for aliasing, and This flavor of the Ethernet A-D route is used for aliasing, and
support of this route flavor is OPTIONAL. support of this route flavor 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. An RD MUST be assigned for a given EVI on an advertising the NLRI. An RD MUST be assigned for a given EVI on an
skipping to change at page 21, line 30 skipping to change at page 23, line 32
allow selecting a DF at the granularity of <ESI, EVI, S, G>. allow selecting a DF at the granularity of <ESI, EVI, S, G>.
Note that a CE always sends packets belonging to a specific flow Note that a CE always sends packets belonging to a specific flow
using a single link towards an PE. For instance, if the CE is a host using a single link towards an PE. For instance, if the CE is a host
then, as mentioned earlier, the host treats the multiple links that then, as mentioned earlier, the host treats the multiple links that
it uses to reach the PEs as a Link Aggregation Group (LAG). The CE it uses to reach the PEs as a Link Aggregation Group (LAG). The CE
employs a local hashing function to map traffic flows onto links in employs a local hashing function to map traffic flows onto links in
the LAG. the LAG.
If a bridged network is multi-homed to more than one PE in an E-VPN If a bridged network is multi-homed to more than one PE in an E-VPN
via switches, then the support of all-active points of attachments, via switches, then the support of All-Active points of attachments,
as described in this specification, requires the bridge network to be as described in this specification, requires the bridge network to be
connected to two or more PEs using a LAG. In this case the reasons connected to two or more PEs using a LAG. In this case the reasons
for doing DF election are the same as those described above when a CE for doing DF election are the same as those described above when a CE
is a host or a router. is a host or a router.
If a bridged network does not connect to the PEs using LAG, then only If a bridged network does not connect to the PEs using LAG, then only
one of the links between the switched bridged network and the PEs one of the links between the switched bridged network and the PEs
must be the active link for a given Ethernet Tag. In this case, the must be the active link for a given Ethernet Tag. In this case, the
Ethernet A-D route per Ethernet segment MUST be advertised with the Ethernet A-D route per Ethernet segment MUST be advertised with the
"Active-Standby" flag set to one. Procedures for supporting all- "Active-Standby" flag set to one. Procedures for supporting All-
active points of attachments, when a bridge network connects to the Active points of attachments, when a bridge network connects to the
PEs using LAG, are for further study. PEs using LAG, are for further study.
The granularity of the DF election MUST be at least the Ethernet The default procedure for DF election at the granularity of <ESI,
segment via which the CE is multi-homed to the PEs. If the DF EVI> is referred to as "service carving". With service carving, it is
election is done at the Ethernet segment granularity then a single PE possible to elect multiple DFs per Ethernet Segment (one per EVI) in
MUST be elected as the DF on the Ethernet segment. order to perform load-balancing of multi-destination traffic destined
to a given Segment. The load-balancing procedures carve up the EVI
If there are one or more EVIs enabled on the Ethernet segment, then space among the PE nodes evenly, in such a way that every PE is the
the granularity of the DF election SHOULD be the combination of the DF for a disjoint set of EVIs. The procedure for service carving is
Ethernet segment and EVI on that Ethernet segment. In this case a as follows:
single PE MUST be elected as the DF for a particular EVI on that
Ethernet segment.
The detailed procedures for DF election are described next.
9.5.1 Default DF Election Procedure
As a PE discovers the other PEs that are connected to the same
Ethernet Segment, using the Ethernet Segment routes, it starts
building an ordered list based on the originating PE IP addresses.
This list is used to select a DF and a backup DF (BDF) on a per
Ethernet Segment basis. By default, the PE with the numerically
highest IP address is considered the DF for that Ethernet Segment and
the next PE in the list is considered the BDF.
If the Ethernet Segment is a multi-homed device, then the elected DF
is the only PE that must forward flooded multi-destination packets
towards the segment. All other PE nodes must not permit multi-
destination packets to egress to the segment. In the case where the
DF fails, the BDF takes over its functionality.
This procedure enables the election of a single DF per Ethernet
Segment, for all EVIs enabled on the segment. It is possible to
achieve more granular load-balancing of traffic among the PE nodes by
employing Service Carving, as discussed in the next section.
9.5.2 DF Election with Service Carving
With service carving, it is possible to elect multiple DFs per
Ethernet Segment (one per EVI) in order to perform load-balancing of
multi-destination traffic destined to a given Segment. The load-
balancing procedures carve up the EVI space among the PE nodes
evenly, in such a way that every PE is the DF for a disjoint set of
EVIs. The procedure for service carving is as follows:
1. When a PE discovers the ESI of the attached Ethernet Segment, it 1. When a PE discovers the ESI of the attached Ethernet Segment, it
advertises an Ethernet Segment route with the associated ES-Import advertises an Ethernet Segment route with the associated ES-Import
extended community attribute. extended community attribute.
2. The PE then starts a timer to allow the reception of Ethernet 2. The PE then starts a timer (default value = 3 seconds) to allow
Segment routes from other PE nodes connected to the same Ethernet the reception of Ethernet Segment routes from other PE nodes
Segment. connected to the same Ethernet Segment. This timer value MUST be same
across all PEs connected to the same Ethernet Segment.
3. When the timer expires, each PE builds an ordered list of the IP 3. When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet Segment addresses of all the PE nodes connected to the Ethernet Segment
(including itself), in increasing numeric value. Every PE is then (including itself), in increasing numeric value. Every PE is then
given an ordinal indicating its position in the ordered list, given an ordinal indicating its position in the ordered list,
starting with 0 as the ordinal for the PE with the numerically lowest starting with 0 as the ordinal for the PE with the numerically lowest
IP address. The ordinals are used to determine which PE node will be IP address. The ordinals are used to determine which PE node will be
the DF for a given EVI on the Ethernet Segment using the following the DF for a given EVI on the Ethernet Segment using the following
rule: Assuming a redundancy group of N PE nodes, the PE with ordinal rule: Assuming a redundancy group of N PE nodes, the PE with ordinal
i is the DF for EVI V when (V mod N) = i. i is the DF for an EVI with an associated Ethernet Tag value V when
(V mod N) = i. In the case where multiple Ethernet Tags are
The above procedure results in the entire EVI range being divided up associated with a single EVI, then the numerically lowest Ethernet
among the PEs in the RG, regardless of whether a given EVI is Tag value in that EVI MUST be used in the modulo function.
configured/enabled on the associated Ethernet Segment or not.
4. The PE that is elected as a DF for a given EVI will unblock 4. The PE that is elected as a DF for a given EVI will unblock
traffic for that EVI only if the EVI is configured/enabled on the traffic for the Ethernet Tags associated with that EVI. Note that the
Segment. Note that the DF PE unblocks multi-destination traffic in DF PE unblocks multi-destination traffic in the egress direction
the egress direction towards the Segment. All non-DF PEs continue to towards the Segment. All non-DF PEs continue to drop multi-
drop multi-destination traffic (for the associated EVIs) in the destination traffic (for the associated EVIs) in the egress direction
egress direction towards the Segment. towards the Segment.
In the case of link or port failure, the affected PE withdraws its In the case of link or port failure, the affected PE withdraws its
Ethernet Segment route. This will re-trigger the service carving Ethernet Segment route. This will re-trigger the service carving
procedures on all the PEs in the RG. For PE node failure, or upon PE procedures on all the PEs in the RG. For PE node failure, or upon PE
commissioning or decommissioning, the PEs re-trigger the service commissioning or decommissioning, the PEs re-trigger the service
carving. When a service moves from one PE in the RG to another PE as carving. In case of a Single-Active multi-homing, when a service
a result of re-carving, the PE, which ends up being the elected DF moves from one PE in the RG to another PE as a result of re-carving,
for the service, must trigger a MAC address flush notification the PE, which ends up being the elected DF for the service, must
towards the associated Ethernet Segment. This can be done, for e.g. trigger a MAC address flush notification towards the associated
using IEEE 802.1ak MVRP 'new' declaration. Ethernet Segment. This can be done, for e.g. using IEEE 802.1ak MVRP
'new' declaration.
10. Determining Reachability to Unicast MAC Addresses 10. Determining Reachability to Unicast MAC Addresses
PEs forward packets that they receive based on the destination MAC PEs forward packets that they receive based on the destination MAC
address. This implies that PEs must be able to learn how to reach a address. This implies that PEs must be able to learn how to reach a
given destination unicast MAC address. given destination unicast MAC address.
There are two components to MAC address learning, "local learning" There are two components to MAC address learning, "local learning"
and "remote learning": and "remote learning":
skipping to change at page 24, line 13 skipping to change at page 25, line 30
- ARP request for its own MAC. - ARP request for its own MAC.
- ARP request for a peer. - ARP request for a peer.
Alternatively PEs MAY learn the MAC addresses of the CEs in the Alternatively PEs MAY learn the MAC addresses of the CEs in the
control plane or via management plane integration between the PEs and control plane or via management plane integration between the PEs and
the CEs. the CEs.
There are applications where a MAC address that is reachable via a There are applications where a MAC address that is reachable via a
given PE on a locally attached Segment (e.g. with ESI X) may move given PE on a locally attached Segment (e.g. with ESI X) may move
such that it becomes reachable via the same PE or another PE on such that it becomes reachable via another PE on another Segment
another Segment (e.g. with ESI Y). This is referred to as a "MAC (e.g. with ESI Y). This is referred to as a "MAC Mobility".
Mobility". Procedures to support this are described in section "MAC Procedures to support this are described in section "MAC Mobility".
Mobility".
10.2. Remote learning 10.2. Remote learning
A particular PE must be able to determine how to send traffic to MAC A particular PE must be able to determine how to send traffic to MAC
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 as "remote" MAC addresses. addresses as "remote" MAC addresses.
This document requires an PE to learn remote MAC addresses in the This document requires an 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
skipping to change at page 25, line 22 skipping to change at page 26, line 38
MUST be the 6-octet MAC address specified by [802.1D-ORIG] [802.1D- MUST be the 6-octet MAC address specified by [802.1D-ORIG] [802.1D-
REV]. If the MAC address is advertised as a prefix then the trailing REV]. If the MAC address is advertised as a prefix then the trailing
bits of the prefix MUST be set to 0 to ensure that the entire prefix bits of the prefix MUST be set to 0 to ensure that the entire prefix
is encoded as 6 octets. is encoded as 6 octets.
The IP Address Length field value is set to the number of octets in The IP Address Length field value is set to the number of octets in
the IP Address field. the IP Address field.
The IP Address field is optional. By default, the IP Address Length The IP Address field is optional. By default, the IP Address Length
field is set to 0 and the IP address field is omitted from the route. field is set to 0 and the IP address field is omitted from the route.
When a valid IP address is included, it is encoded as specified in When a valid IP address needs to be advertised (e.g., for ARP
section 12. suppression purposes or for inter-subnet switching), it is then
encoded in this route.
The MPLS label field carries one or more labels (that corresponds to The MPLS label field carries one or more labels (that corresponds to
the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3 the stack of labels [MPLS-ENCAPS]). Each label is encoded as 3
octets, where the high-order 20 bits contain the label value, and the octets, where the high-order 20 bits contain the label value, and the
low order bit contains "Bottom of Stack" (as defined in [MPLS- low order bit contains "Bottom of Stack" (as defined in [MPLS-
ENCAPS]). The MPLS label stack MUST be the downstream assigned E-VPN ENCAPS]). The MPLS label stack MUST be the downstream assigned E-VPN
MPLS label stack that is used by the PE to forward MPLS-encapsulated MPLS label stack that is used by the PE to forward MPLS-encapsulated
Ethernet frames received from remote PEs, where the destination MAC Ethernet frames received from remote PEs, where the destination MAC
address in the Ethernet frame is the MAC address advertised in the address in the Ethernet frame is the MAC address advertised in the
above NLRI. The forwarding procedures are specified in section above NLRI. The forwarding procedures are specified in section
skipping to change at page 26, line 20 skipping to change at page 27, line 37
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 "Ethernet A-D ID, in the Unique VLAN case, as described in section "Ethernet A-D
Route per E-VPN". Route per E-VPN".
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.
10.2.2 Route Resolution
If the Ethernet Segment Identifier field in a received MAC
Advertisement route is set to the reserved ESI value of 0 or MAX-ESI,
then the receiving PE MUST install forwarding state for the
associated MAC Address based on the MAC Advertisement route alone.
If the Ethernet Segment Identifier field in a received MAC
Advertisement route is set to a non-reserved ESI, and the receiving
PE is locally attached to the same ESI, then the PE does not alter
its forwarding state based on the received route. This ensures that
local routes are preferred to remote routes.
If the Ethernet Segment Identifier field in a received MAC
Advertisement route is set to a non-reserved ESI, then the receiving
PE MUST install forwarding state for a given MAC address only when
both the MAC Advertisement route AND the associated Ethernet A-D
route per ESI have been received.
To illustrate this with an example, consider two PEs (PE1 and PE2)
connected to a multi-homed Ethernet Segment ES1. All-Active
redundancy mode is assumed. A given MAC address M1 is learnt by PE1
but not PE2. On PE3, the following states may arise:
T1- When the MAC Advertisement Route from PE1 and the Ethernet A-D
routes per ESI from PE1 and PE2 are received, PE3 can forward traffic
destined to M1 to both PE1 and PE2.
T2- If after T1, PE1 withdraws its Ethernet A-D route per ESI, then
PE3 forwards traffic destined to M1 to PE2 only.
T3- If after T1, PE2 withdraws its Ethernet A-D route per ESI, then
PE3 forwards traffic destined to M1 to PE1 only.
T4- If after T1, PE1 withdraws its MAC Advertisement route, then PE3
treats traffic to M1 as unknown unicast. Note, here, that had PE2
also advertised a MAC route for M1 before PE1 withdraws its MAC
route, then PE3 would have continued forwarding traffic destined to
M1 to PE2.
11. ARP and ND 11. 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
remote CEs. This option also minimizes ARP (or ND) message processing remote CEs. This option also minimizes ARP (or ND) message processing
on end-stations/hosts connected to the E-VPN network. An PE may learn on end-stations/hosts connected to the E-VPN network. An PE may learn
the IP address associated with a MAC address in the control or the IP address associated with a MAC address in the control or
management plane between the CE and the PE. Or, it may learn this management plane between the CE and the PE. Or, it may learn this
skipping to change at page 32, line 41 skipping to change at page 34, line 49
This section specifies the load balancing procedures for sending This section specifies the load balancing procedures for sending
known unicast frames to a multi-homed CE. known unicast frames to a multi-homed CE.
15.1. Load balancing of traffic from an PE to remote CEs 15.1. Load balancing of traffic from an PE to remote CEs
Whenever a remote PE imports a MAC advertisement for a given <ESI, Whenever a remote PE imports a MAC advertisement for a given <ESI,
Ethernet Tag> in an EVI, it MUST examine all imported Ethernet A-D Ethernet Tag> in an EVI, it MUST examine all imported Ethernet A-D
routes for that ESI in order to determine the load-balancing routes for that ESI in order to determine the load-balancing
characteristics of the Ethernet segment. characteristics of the Ethernet segment.
15.1.1 Active-Standby Redundancy Mode 15.1.1 Single-Active Redundancy Mode
For a given ESI, if the remote PE has imported an Ethernet A-D route For a given ESI, if the remote PE has imported an Ethernet A-D route
per Ethernet Segment from at least one PE, where the "Active-Standby" per Ethernet Segment from at least one PE, where the "Active-Standby"
flag in the ESI MPLS Label Extended Community is set, then the remote flag in the ESI Label Extended Community is set, then the remote PE
PE MUST deduce that the Ethernet segment is operating in Active- MUST deduce that the Ethernet segment is operating in Single-Active
Standby redundancy mode. As such, the MAC address will be reachable redundancy mode. As such, the MAC address will be reachable only via
only via the PE announcing the associated MAC Advertisement route - the PE announcing the associated MAC Advertisement route - this is
this is referred to as the primary PE. The set of other PE nodes referred to as the primary PE. The set of other PE nodes advertising
advertising Ethernet A-D routes per Ethernet Segment for the same ESI Ethernet A-D routes per Ethernet Segment for the same ESI serve as
serve as backup paths, in case the active PE encounters a failure. backup paths, in case the active PE encounters a failure. These are
referred to as the backup PEs. It should be noted that the primary PE
These are referred to as the backup PEs. for a given <ESI, EVI> is the DF for that <ESI, EVI>.
If the primary PE encounters a failure, it MAY withdraw its Ethernet If the primary PE encounters a failure, it MAY withdraw its Ethernet
A-D route for the affected segment prior to withdrawing the entire A-D route for the affected segment prior to withdrawing the entire
set of MAC Advertisement routes. In the case where only a single set of MAC Advertisement routes.
other backup PE in the network had advertised an Ethernet A-D route
for the same ESI, the remote PE can then use the Ethernet A-D route In the case where only a single other backup PE in the network had
withdrawal as a trigger to update its forwarding entries, for the advertised an Ethernet A-D route for the same ESI, the remote PE can
associated MAC addresses, to point towards the backup PE. As the then use the Ethernet A-D route withdrawal as a trigger to update its
backup PE starts learning the MAC addresses over its attached forwarding entries, for the associated MAC addresses, to point
Ethernet segment, it will start sending MAC Advertisement routes towards the backup PE. As the backup PE starts learning the MAC
while the failed PE withdraws its own. This mechanism minimizes the addresses over its attached Ethernet segment, it will start sending
flooding of traffic during fail-over events. MAC Advertisement routes while the failed PE withdraws its own. This
mechanism minimizes the flooding of traffic during fail-over events.
In the case where multiple other backup PE in the network had
advertised an Ethernet A-D route for the same ESI, the remote PE MUST
then use the Ethernet A-D route withdrawal as a trigger to start
flooding traffic destined to the associated MAC addresses (as long as
flooding of unknown unicast is administratively allowed). It is not
possible to select a single backup path in this case.
15.1.2 All-Active Redundancy Mode 15.1.2 All-Active Redundancy Mode
If for the given ESI, none of the Ethernet A-D routes per Ethernet If for the given ESI, none of the Ethernet A-D routes per Ethernet
Segment imported by the remote PE have the "Active-Standby" flag set Segment imported by the remote PE have the "Active-Standby" flag set
in the ESI MPLS Label Extended Community, then the remote PE MUST in the ESI Label Extended Community, then the remote PE MUST treat
treat the Ethernet segment as operating in all-active redundancy the Ethernet segment as operating in All-Active redundancy mode. The
mode. The remote PE would then treat the MAC address as reachable via remote PE would then treat the MAC address as reachable via all of
all of the PE nodes from which it has received both an Ethernet A-D the PE nodes from which it has received both an Ethernet A-D route
route per Ethernet Segment as well as an Ethernet A-D route per EVI per Ethernet Segment as well as an Ethernet A-D route per EVI for the
for the ESI in question. The remote PE MUST use the MAC advertisement ESI in question. The remote PE MUST use the MAC advertisement and
and eligible Ethernet A-D routes to construct the set of next-hops eligible Ethernet A-D routes to construct the set of next-hops that
that it can use to send the packet to the destination MAC. Each next- it can use to send the packet to the destination MAC. Each next-hop
hop comprises an MPLS label stack that is to be used by the egress PE comprises an MPLS label stack that is to be used by the egress PE to
to forward the packet. This label stack is determined as follows: forward the packet. This label stack is determined as follows:
-If the next-hop is constructed as a result of a MAC route then this -If the next-hop is constructed as a result of a MAC route then this
label stack MUST be used. However, if the MAC route doesn't exist, label stack MUST be used. However, if the MAC route doesn't exist,
then the next-hop and MPLS label stack is constructed as a result of then the next-hop and MPLS label stack is constructed as a result of
the Ethernet A-D routes. Note that the following description applies the Ethernet A-D routes. Note that the following description applies
to determining the label stack for a particular next-hop to reach a to determining the label stack for a particular next-hop to reach a
given PE, from which the remote PE has received and imported Ethernet given PE, from which the remote PE has received and imported Ethernet
A-D routes that have the matching ESI and Ethernet Tag as the one A-D routes that have the matching ESI and Ethernet Tag as the one
present in the MAC advertisement. The Ethernet A-D routes mentioned present in the MAC advertisement. The Ethernet A-D routes mentioned
in the following description refer to the ones imported from this in the following description refer to the ones imported from this
skipping to change at page 34, line 9 skipping to change at page 36, line 25
The following example explains the above. The following example explains the above.
Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a Consider a CE (CE1) that is dual-homed to two PEs (PE1 and PE2) on a
LAG interface (ES1), and is sending packets with MAC address MAC1 on LAG interface (ES1), and is sending packets with MAC address MAC1 on
VLAN1. A remote PE, say PE3, is able to learn that MAC1 is reachable VLAN1. A remote PE, say PE3, is able to learn that MAC1 is reachable
via PE1 and PE2. Both PE1 and PE2 may advertise MAC1 in BGP if they via PE1 and PE2. Both PE1 and PE2 may advertise MAC1 in BGP if they
receive packets with MAC1 from CE1. If this is not the case, and if receive packets with MAC1 from CE1. If this is not the case, and if
MAC1 is advertised only by PE1, PE3 still considers MAC1 as reachable MAC1 is advertised only by PE1, PE3 still considers MAC1 as reachable
via both PE1 and PE2 as both PE1 and PE2 advertise a Ethernet A-D via both PE1 and PE2 as both PE1 and PE2 advertise a Ethernet A-D
route per ESI for ESI1 as well as an Ethernet A-D route per EVI for route per ESI for ES1 as well as an Ethernet A-D route per EVI for
<ESI1, VLAN1>. <ES1, VLAN1>.
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 E-VPN label advertised by PE1 for CE1's MAC. to get to PE1 and the E-VPN 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 and the MPLS label in the Ethernet A-D route advertised by
PE2 for <ES1, VLAN1>, if PE2 has not advertised MAC1 in BGP. 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.
skipping to change at page 36, line 48 skipping to change at page 39, line 16
MAC Mobility attribute, the value of the sequence number in the MAC Mobility attribute, the value of the sequence number in the
received route is assumed to be 0 for purpose of this processing. received route is assumed to be 0 for purpose of this processing.
- A PE detecting a locally attached MAC address for which it had - A PE detecting a locally attached MAC address for which it had
previously received a MAC Advertisement route with the same Ethernet previously received a MAC Advertisement route with the same Ethernet
segment identifier advertises it with: segment identifier advertises it with:
i. no MAC Mobility extended community attribute, if the received i. no MAC Mobility extended community attribute, if the received
route did not carry said attribute. route did not carry said attribute.
ii. a MAC Mobility extended community attribute with the sequence ii. a MAC Mobility extended community attribute with the sequence
number equal to the sequence number in the received MAC number equal to the highest of the sequence number(s) in the
Advertisement route, if the received route is tagged with a MAC received MAC Advertisement route(s), if the received route(s) is
Mobility extended community attribute. (are) tagged with a MAC Mobility extended community attribute.
A PE receiving a MAC Advertisement route for a MAC address with a A PE receiving a MAC Advertisement route for a MAC address with a
different Ethernet segment identifier and a higher sequence number different Ethernet segment identifier and a higher sequence number
than that which it had previously advertised, withdraws its MAC than that which it had previously advertised, withdraws its MAC
Advertisement route. If two (or more) PEs advertise the same MAC Advertisement route. If two (or more) PEs advertise the same MAC
address with same sequence number but different Ethernet segment address with same sequence number but different Ethernet segment
identifiers, a PE that receives these routes selects the route identifiers, a PE that receives these routes selects the route
advertised by the PE with lowest IP address as the best route. advertised by the PE with lowest IP address as the best route.
16.1. MAC Duplication Issue
A situation may arise where the same MAC address is learned by
different PEs in the same VLAN because of two (or more hosts) being
mis-configured with the same (duplicate) MAC address. In such
situation, the traffic originating from these hosts would trigger
continuous MAC moves among the PEs attached to these hosts. It is
important to recognize such situation and avoid incrementing the
sequence number (in the MAC Mobility attribute) to infinity. In order
to remedy such situation, a PE that detects a MAC mobility event by
way of local learning starts an M-second timer (default value of M =
5) and if it detects N MAC moves before the timer expires (default
value for N = 3), it concludes that a duplicate MAC situation has
occurred. The PE MUST alert the operator and stop sending and
processing any BGP MAC Advertisement routes for that MAC address till
a corrective action is taken by the operator. The values of M and N
MUST be configurable to allow for flexibility in operator control.
17. Multicast 17. Multicast
The PEs in a particular E-VPN may use ingress replication or P2MP The PEs in a particular E-VPN may use ingress replication or P2MP
LSPs to send multicast traffic to other PEs. LSPs to send multicast traffic to other PEs.
17.1. Ingress Replication 17.1. Ingress Replication
The PEs may use ingress replication for flooding unknown unicast, The PEs may use ingress replication for flooding unknown unicast,
multicast or broadcast traffic as described in section "Handling of multicast or broadcast traffic as described in section "Handling of
Multi-Destination Traffic". A given unknown unicast or broadcast Multi-Destination Traffic". A given unknown unicast or broadcast
skipping to change at page 41, line 50 skipping to change at page 44, line 36
and consequent service disruption. The protocol details for and consequent service disruption. The protocol details for
synchronizing the LACP state will be described in the following synchronizing the LACP state will be described in the following
version. version.
20. Acknowledgements 20. Acknowledgements
We would like to thank Yakov Rekhter, Pedro Marques, Kaushik Ghosh, We would like to thank Yakov Rekhter, 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 for his review. also like to thank Steve Kensil and Reshad Rahman for their reviews.
Last but not least, many thanks to Jakob Heitz for his help to
improve several sections of this draft.
21. Security Considerations 21. Security Considerations
22. IANA Considerations 22. IANA Considerations
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
 End of changes. 69 change blocks. 
332 lines changed or deleted 445 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/