draft-ietf-l2vpn-evpn-06.txt   draft-ietf-l2vpn-evpn-07.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: September 12, 2014 March 12, 2014 Expires: November 7, 2014 May 7, 2014
BGP MPLS Based Ethernet VPN BGP MPLS Based Ethernet VPN
draft-ietf-l2vpn-evpn-06 draft-ietf-l2vpn-evpn-07
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 27 skipping to change at page 2, line 27
This document describes procedures for BGP MPLS based Ethernet VPNs This document describes procedures for BGP MPLS based Ethernet VPNs
(EVPN). (EVPN).
Table of Contents Table of Contents
1. Specification of requirements . . . . . . . . . . . . . . . . . 5 1. Specification of requirements . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Ethernet Tag ID . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 10 6.1 VLAN Based Service Interface . . . . . . . . . . . . . . . . 10
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 . . . . . . . . 11 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 . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . 14 7.4 Ethernet Segment Route . . . . . . . . . . . . . . . . . . . 15
7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 15 7.5 ESI Label Extended Community . . . . . . . . . . . . . . . . 15
7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 15 7.6 ES-Import Route Target . . . . . . . . . . . . . . . . . . . 16
7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 16 7.7 MAC Mobility Extended Community . . . . . . . . . . . . . . 16
7.8 Default Gateway Extended Community . . . . . . . . . . . . . 16 7.8 Default Gateway Extended Community . . . . . . . . . . . . . 17
8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 16 7.9 Route Distinguisher Assignment per EVI . . . . . . . . . . . 17
8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 17 7.10 Route Targets . . . . . . . . . . . . . . . . . . . . . . . 17
8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 17 7.10.1 Auto-Derivation from the Ethernet Tag ID . . . . . . . 17
8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 17 8. Multi-homing Functions . . . . . . . . . . . . . . . . . . . . 18
8.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . . . 18
8.1.1 Constructing the Ethernet Segment Route . . . . . . . . 18
8.2 Fast Convergence . . . . . . . . . . . . . . . . . . . . . . 18
8.2.1 Constructing the Ethernet A-D per Ethernet Segment 8.2.1 Constructing the Ethernet A-D per Ethernet Segment
(ES) Route . . . . . . . . . . . . . . . . . . . . . . . 18 (ES) Route . . . . . . . . . . . . . . . . . . . . . . . 19
8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 18 8.2.1.1. Ethernet A-D Route Targets . . . . . . . . . . . . 20
8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 19 8.3 Split Horizon . . . . . . . . . . . . . . . . . . . . . . . 20
8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 19 8.3.1 ESI Label Assignment . . . . . . . . . . . . . . . . . . 21
8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 19 8.3.1.1 Ingress Replication . . . . . . . . . . . . . . . . 21
8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 20 8.3.1.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . 22
8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 23
8.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . . . 21
8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) 8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI)
Route . . . . . . . . . . . . . . . . . . . . . . . . . 22 Route . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.4.1.1 Ethernet A-D Route Targets . . . . . . . . . . . . . 23 8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 25
8.5 Designated Forwarder Election . . . . . . . . . . . . . . . 24 8.6. Interoperability with Single-homing PEs . . . . . . . . . . 27
8.6. Interoperability with Single-homing PEs . . . . . . . . . . 26 9. Determining Reachability to Unicast MAC Addresses . . . . . . . 27
9. Determining Reachability to Unicast MAC Addresses . . . . . . . 26
9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 27 9.1. Local Learning . . . . . . . . . . . . . . . . . . . . . . 27
9.2. Remote learning . . . . . . . . . . . . . . . . . . . . . . 27 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 . . . . . . . . . . . . . . . . . . . . . 27 Advertisement . . . . . . . . . . . . . . . . . . . . . 28
9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 29 9.2.2 Route Resolution . . . . . . . . . . . . . . . . . . . . 30
10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10. ARP and ND . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 31 10.1 Default Gateway . . . . . . . . . . . . . . . . . . . . . . 32
11. Handling of Multi-Destination Traffic . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 32 Route . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 33 11.2. P-Tunnel Identification . . . . . . . . . . . . . . . . . 34
12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 34 12. Processing of Unknown Unicast Packets . . . . . . . . . . . . 35
12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 34 12.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 35
12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 35 12.2. P2MP MPLS LSPs . . . . . . . . . . . . . . . . . . . . . . 36
13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 35 13. Forwarding Unicast Packets . . . . . . . . . . . . . . . . . . 36
13.1. Forwarding packets received from a CE . . . . . . . . . . 35 13.1. Forwarding packets received from a CE . . . . . . . . . . 36
13.2. Forwarding packets received from a remote PE . . . . . . . 36 13.2. Forwarding packets received from a remote PE . . . . . . . 37
13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 36 13.2.1. Unknown Unicast Forwarding . . . . . . . . . . . . . . 37
13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 37 13.2.2. Known Unicast Forwarding . . . . . . . . . . . . . . . 38
14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 37 14. Load Balancing of Unicast Frames . . . . . . . . . . . . . . . 38
14.1. Load balancing of traffic from an PE to remote CEs . . . . 37 14.1. Load balancing of traffic from a PE to remote CEs . . . . 38
14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 37 14.1.1 Single-Active Redundancy Mode . . . . . . . . . . . . . 38
14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 38 14.1.2 All-Active Redundancy Mode . . . . . . . . . . . . . . 39
14.2. Load balancing of traffic between an PE and a local CE . . 40 14.2. Load balancing of traffic between a PE and a local CE . . 41
14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 40 14.2.1. Data plane learning . . . . . . . . . . . . . . . . . 41
14.2.2. Control plane learning . . . . . . . . . . . . . . . . 40 14.2.2. Control plane learning . . . . . . . . . . . . . . . . 41
15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 40 15. MAC Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 41
15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 42 15.1. MAC Duplication Issue . . . . . . . . . . . . . . . . . . 43
15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 43 15.2. Sticky MAC addresses . . . . . . . . . . . . . . . . . . . 43
16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 43 16. Multicast & Broadcast . . . . . . . . . . . . . . . . . . . . 44
16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 43 16.1. Ingress Replication . . . . . . . . . . . . . . . . . . . 44
16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 43 16.2. P2MP LSPs . . . . . . . . . . . . . . . . . . . . . . . . 44
16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 43 16.2.1. Inclusive Trees . . . . . . . . . . . . . . . . . . . 44
17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 44 17. Convergence . . . . . . . . . . . . . . . . . . . . . . . . . 45
17.1. Transit Link and Node Failures between PEs . . . . . . . . 44 17.1. Transit Link and Node Failures between PEs . . . . . . . . 45
17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 44 17.2. PE Failures . . . . . . . . . . . . . . . . . . . . . . . 45
17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 44 17.3. PE to CE Network Failures . . . . . . . . . . . . . . . . 45
18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 45 18. Frame Ordering . . . . . . . . . . . . . . . . . . . . . . . . 46
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
20. Security Considerations . . . . . . . . . . . . . . . . . . . 46 20. Security Considerations . . . . . . . . . . . . . . . . . . . 47
21. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 47 21. Co-authors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 22. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49
23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 23. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
23.1 Normative References . . . . . . . . . . . . . . . . . . . 48 23.1 Normative References . . . . . . . . . . . . . . . . . . . 49
23.2 Informative References . . . . . . . . . . . . . . . . . . 48 23.2 Informative References . . . . . . . . . . . . . . . . . . 49
24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 49 24. Author's Address . . . . . . . . . . . . . . . . . . . . . . . 50
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. Terminology 2. Terminology
Bridge Domain: Broadcast Domain: in a bridged network, it corresponds to a Virtual
LAN (VLAN); where a VLAN is typically represented by a single VLAN ID
(VID), but can be represented by several VIDs.
Broadcast Domain: Bridge Domain: An instantiation of a broadcast domain on a bridge
node
CE: Customer Edge device e.g., host or router or switch CE: Customer Edge device e.g., host or router or switch
EVI: An EVPN instance spanning across the PEs participating in that EVI: An EVPN instance spanning across the PEs participating in that
VPN EVPN
MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on MAC-VRF: A Virtual Routing and Forwarding table for MAC addresses on
a PE for an EVI a PE for an EVI
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'.
Ethernet Tag: An Ethernet Tag identifies a particular broadcast Ethernet Tag: An Ethernet Tag identifies a particular broadcast
skipping to change at page 6, line 33 skipping to change at page 6, line 36
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,
etc. The PEs may also be connected by an IP infrastructure in which etc. The PEs may also be connected by an IP infrastructure in which
case IP/GRE tunneling or other IP tunneling can be used between the case IP/GRE tunneling or other IP tunneling can be used between the
PEs. The detailed procedures in this version of this document are PEs. The detailed procedures in this version of this document are
specified only for MPLS LSPs as the tunneling technology. However specified only for MPLS LSPs as the tunneling technology. However
these procedures are designed to be extensible to IP tunneling as the these procedures are designed to be extensible to IP tunneling as the
PSN tunneling technology. Packet Switched Network (PSN) tunneling technology.
In an EVPN, MAC learning between PEs occurs not in the data plane (as In an EVPN, MAC learning between PEs occurs not in the data plane (as
happens with traditional bridging) but in the control plane. Control happens with traditional bridging in VPLS [RFC4761] or [RFC4762]) but
plane learning offers greater control over the MAC learning process, in the control plane. Control plane learning offers greater control
such as restricting who learns what, and the ability to apply over the MAC learning process, such as restricting who learns what,
policies. Furthermore, the control plane chosen for advertising MAC and the ability to apply policies. Furthermore, the control plane
reachability information is multi-protocol (MP) BGP (similar to IP chosen for advertising MAC reachability information is multi-protocol
VPNs (RFC 4364)). This provides greater scalability and the ability (MP) BGP (similar to IP VPNs (RFC 4364)). This provides flexibility
to preserve the "virtualization" or isolation of groups of and the ability to preserve the "virtualization" or isolation of
interacting agents (hosts, servers, virtual machines) from each groups of interacting agents (hosts, servers, virtual machines) from
other. In EVPN, PEs advertise the MAC addresses learned from the CEs each other. In EVPN, PEs advertise the MAC addresses learned from the
that are connected to them, along with an MPLS label, to other PEs in CEs that are connected to them, along with an MPLS label, to other
the control plane using MP-BGP. Control plane learning enables load PEs in the control plane using MP-BGP. Control plane learning enables
balancing of traffic to and from CEs that are multi-homed to multiple load balancing of traffic to and from CEs that are multi-homed to
PEs. This is in addition to load balancing across the MPLS core via multiple PEs. This is in addition to load balancing across the MPLS
multiple LSPs between the same pair of PEs. In other words it allows core via multiple LSPs between the same pair of PEs. In other words
CEs to connect to multiple active points of attachment. It also it allows CEs to connect to multiple active points of attachment. It
improves convergence times in the event of certain network failures. also improves convergence times in the event of certain network
failures.
However, learning between PEs and CEs is done by the method best However, learning between PEs and CEs is done by the method best
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
an PE is populated with all the MAC destination addresses known to a PE is populated with all the MAC destination addresses known to the
the control plane, or whether the PE implements a cache based scheme. control plane, or whether the PE implements a cache based scheme. For
For instance the MAC forwarding table may be populated only with the instance the MAC forwarding table may be populated only with the MAC
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 an 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
skipping to change at page 7, line 43 skipping to change at page 7, line 47
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. 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 MUST have a non-reserved ESI that is
unique network wide (e.g., across all EVPN instances on all the PEs). unique network wide (i.e., across all EVPN instances on all the PEs).
If the CE(s) constituting an Ethernet Segment is (are) managed by the If the CE(s) constituting an Ethernet Segment is (are) managed by the
network operator, then ESI uniqueness should be guaranteed; however, network operator, then ESI uniqueness should be guaranteed; however,
if the CE(s) is (are) not managed, then the operator MUST configure a 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 network-wide unique ESI for that Ethernet Segment. This is required
to enable auto-discovery of Ethernet Segments and DF election. 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:
+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+
skipping to change at page 9, line 6 skipping to change at page 9, line 10
the value of the ESI is derived by listening to BPDUs on the Ethernet the value of the ESI is derived by listening to BPDUs on the Ethernet
segment. To achieve this the PE is not required to run MST. However segment. To achieve this the PE is not required to run MST. However
the PE must learn the Root Bridge MAC address and Bridge Priority of the PE must learn the Root Bridge MAC address and Bridge Priority of
the root of the Internal Spanning Tree (IST) by listening to the the root of the Internal Spanning Tree (IST) by listening to the
BPDUs. The ESI Value is constructed as follows: BPDUs. The ESI Value is constructed as follows:
+ Root Bridge six octets MAC address. The Root Bridge MAC + Root Bridge six octets MAC address. The Root Bridge MAC
address MUST be encoded in the high order six octets of the address MUST be encoded in the high order six octets of the
ESI Value field. ESI Value field.
+ Root Bridge two octets Priority. The CE LACP port key MUST be + Root Bridge two octets Priority. The CE Root Bridge Priority
encoded in the two octets next to the Root Bridge MAC address. MUST be encoded in the two octets next to the Root Bridge
MAC address.
+ The remaining octet will be set to 0x00. + The remaining octet will be set to 0x00.
This mechanism could be used only if it produces ESIs that satisfy This mechanism could be used only if it produces ESIs that
the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 3 (T=0x03) - This type indicates a MAC-based ESI Value that - Type 3 (T=0x03) - This type indicates a MAC-based ESI Value that
can be auto-generated or configured by the operator. The ESI Value is can be auto-generated or configured by the operator. The ESI Value is
constructed as follows: constructed as follows:
+ System MAC address (six octets). The System MAC address MUST + System MAC address (six octets). The PE MAC address MUST
be encoded in the high order six octets of the ESI Value field. be encoded in the high order six octets of the ESI Value field.
+ Local Discriminator value (three octets). The Local + Local Discriminator value (three octets). The Local
Discriminator MUST be encoded in the low order three octets Discriminator MUST be encoded in the low order three octets
of the ESI Value. of the ESI Value.
This mechanism could be used only if it produces ESIs that satisfy This mechanism could be used only if it produces ESIs that
the uniqueness requirement specified above. satisfy the uniqueness requirement specified above.
- Type 4 (T=0x04) - This type indicates an IP-based ESI Value that - Type 4 (T=0x04) - This type indicates a router-ID ESI Value that
can be auto-generated or configured by the operator. The ESI Value is can be auto-generated or configured by the operator. The ESI Value is
constructed as follows: constructed as follows:
+ IP address (four octets). This is an IPv4 address owned by + Router ID (four octets). The system router ID MUST be encoded in
the system and MUST be encoded in the high order four octets the high order four octets of the ESI Value field.
of the ESI Value field.
+ Local Discriminator value (four octets). The Local Discriminator + Local Discriminator value (four octets). The Local
MUST be encoded in the four octets next to the IP address. Discriminator MUST be encoded in the four octets next to the
IP address.
+ The low order octet of the ESI Value will be set to 0x00. + The low order octet of the ESI Value will be set to 0x00.
This mechanism could be used only if it produces ESIs that satisfy This mechanism could be used only if it produces ESIs that
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 bytes 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 6. Ethernet Tag ID
An Ethernet Tag identifies a particular broadcast domain, e.g. a An Ethernet Tag ID is a 32-bit field containing either a 12-bit or a
VLAN, in an EVPN Instance. An EVPN Instance consists of one or more 24-bit identifier that identifies a particular broadcast domain
broadcast domains (one or more VLANs). VLANs are assigned to a given (e.g., a VLAN) in an EVPN Instance. The 12-bit identifier is called
EVPN Instance by the provider of the EVPN service. A given VLAN can VLAN ID (VID). An EVPN Instance consists of one or more broadcast
itself be represented by multiple VLAN IDs (VIDs). In such cases, the domains (one or more VLANs). VLANs are assigned to a given EVPN
PEs participating in that VLAN for a given EVPN instance are Instance by the provider of the EVPN service. A given VLAN can itself
responsible for performing VLAN ID translation to/from locally be represented by multiple VLAN IDs (VIDs). In such cases, the PEs
attached CE devices. participating in that VLAN for a given EVPN instance are responsible
for performing VLAN ID translation to/from locally attached CE
devices.
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 8.4.1.1.1 "Auto-Derivation from the VID, as described in section 7.10.1.
Ethernet Tag ID".
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 Tags (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 Identifier, in the various
EVPN BGP routes (defined in section 8), for the different types of EVPN BGP routes (defined in section 8), for the different types of
service interfaces described in [EVPN-REQ]. service interfaces described in [EVPN-REQ].
The following Ethernet Tag value is reserved: The following value of Ethernet Tag is reserved:
- Ethernet Tag {0xFFFFFFFF} is known as MAX-ET - Ethernet Tag {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 different VIDs on different PEs, then each PE needs to perform VID
translation for frames destined to its attached CEs. In such translation for frames destined to its attached CEs. In such
scenarios, the Ethernet frames transported over MPLS/IP network scenarios, the Ethernet frames transported over MPLS/IP network
SHOULD remain tagged with the originating VID and a VID translation SHOULD remain tagged with the originating VID and a VID translation
MUST be supported in the data path and MUST be performed on the MUST be supported in the data path and MUST be performed on the
skipping to change at page 11, line 37 skipping to change at page 11, line 43
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 - e.g., 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 tag (VID) translation is required, a
normalized Ethernet Tag (VID) MUST be carried in the MPLS normalized Ethernet Tag (VID) MUST be carried in the MPLS
encapsulated frames and a tag translation function MUST be supported encapsulated frames and a tag translation function MUST be supported
in the data path. This translation MUST be performed in data path on in the data path. This translation MUST be performed in data path on
both the imposition as well as the disposition PEs (translating to both the imposition as well as the disposition PEs (translating to
normalized tag on imposition PE and translating to local tag on normalized tag on imposition PE and translating to local tag on
disposition PE). The Ethernet Tag Identifier in all EVPN routes MUST disposition PE). The Ethernet Tag Identifier in all EVPN routes MUST
be set to the normalized Ethernet Tag assigned by the EVPN provider. be set to the normalized Ethernet Tag 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 map to the same bundle. The procedures are identical same service and are mapped to a single bundle but without any VID
to those described in section 6.3. translation. The procedures are subset of those described in section
6.3.
7. BGP EVPN NLRI 7. BGP EVPN NLRI
This document defines a new BGP NLRI, called the EVPN NLRI. This document defines a new BGP NLRI, called the EVPN NLRI.
Following is the format of the EVPN NLRI: Following is the format of the EVPN NLRI:
+-----------------------------------+ +-----------------------------------+
| Route Type (1 octet) | | Route Type (1 octet) |
+-----------------------------------+ +-----------------------------------+
skipping to change at page 12, line 31 skipping to change at page 12, line 38
The Route Type field defines encoding of the rest of the EVPN NLRI The Route Type field defines encoding of the rest of the EVPN NLRI
(Route Type specific EVPN NLRI). (Route Type specific EVPN NLRI).
The Length field indicates the length in octets of the Route Type The Length field indicates the length in octets of the Route Type
specific field of EVPN NLRI. specific field of EVPN NLRI.
This document defines the following Route Types: This document defines the following Route Types:
+ 1 - Ethernet Auto-Discovery (A-D) route + 1 - Ethernet Auto-Discovery (A-D) route
+ 2 - MAC advertisement route + 2 - MAC/IP advertisement route
+ 3 - Inclusive Multicast Route + 3 - Inclusive Multicast Ethernet Tag 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 EVPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol The EVPN NLRI is carried in BGP [RFC4271] using BGP Multiprotocol
Extensions [RFC4760] with an AFI of 25 (L2VPN) and a SAFI of 70 Extensions [RFC4760] with an AFI of 25 (L2VPN) and a SAFI of 70
(EVPN). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute (EVPN). The NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute
contains the EVPN NLRI (encoded as specified above). contains the EVPN NLRI (encoded as specified above).
skipping to change at page 13, line 17 skipping to change at page 13, line 24
| RD (8 octets) | | 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 ID and the Ethernet Tag ID are considered to be part of the Segment Identifier and the Ethernet Tag ID are considered to be part
prefix in the NLRI. The MPLS Label field is to be treated as a of the prefix in the NLRI. The MPLS Label field is to be treated as
route attribute as opposed to being part of the route. a route attribute as opposed to being part of the route.
For procedures and usage of this route please see section 8.2 "Fast For procedures and usage of this route please see section 8.2 "Fast
Convergence" and section 8.4 "Aliasing". Convergence" and section 8.4 "Aliasing".
7.2. MAC/IP Advertisement Route 7.2. MAC/IP Advertisement Route
A MAC advertisement route type specific EVPN NLRI consists of the A MAC/IP advertisement route type specific EVPN NLRI consists of the
following: following:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| MAC Address Length (1 octet) | | MAC Address Length (1 octet) |
skipping to change at page 14, line 7 skipping to change at page 14, line 30
| 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 Label fields are to be
treated as route attributes as opposed to being part of the "route". treated as route attributes as opposed to being part 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 14, line 30 skipping to change at page 15, line 7
| Ethernet Tag ID (4 octets) | | Ethernet Tag ID (4 octets) |
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Addr | | Originating Router's IP Addr |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
For procedures and usage of this route please see section 11 For procedures and usage of this route please see section 11
"Handling of Multi-Destination Traffic", section 13 "Processing of "Handling of Multi-Destination Traffic", section 13 "Processing of
Unknown Unicast Traffic" and section 16 "Multicast". Unknown Unicast Traffic" and section 16 "Multicast". The IP address
length is in bits. For the purpose of BGP route key processing, only
the Ethernet Tag ID, IP Address Length, and Originating Router's IP
Address fields are considered to be part of the prefix in the NLRI.
7.4 Ethernet Segment Route 7.4 Ethernet Segment Route
The Ethernet Segment Route is encoded in the EVPN NLRI using the An Ethernet Segment route type specific EVPN NLRI consists of the
Route Type value of 4. The Route Type Specific field of the NLRI is following:
formatted as follows:
+---------------------------------------+ +---------------------------------------+
| RD (8 octets) | | RD (8 octets) |
+---------------------------------------+ +---------------------------------------+
|Ethernet Segment Identifier (10 octets)| |Ethernet Segment Identifier (10 octets)|
+---------------------------------------+ +---------------------------------------+
| IP Address Length (1 octet) | | IP Address Length (1 octet) |
+---------------------------------------+ +---------------------------------------+
| Originating Router's IP Addr | | Originating Router's IP Addr |
| (4 or 16 octets) | | (4 or 16 octets) |
+---------------------------------------+ +---------------------------------------+
For procedures and usage of this route please see section 8.5 For procedures and usage of this route please see section 8.5
"Designated Forwarder Election". The IP address length is in bits. "Designated Forwarder Election". The IP address length is in bits.
For the purpose of BGP route key processing, only the Ethernet
Segment ID, IP Address Length, and Originating Router's IP Address
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".
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 (One Octet) |Reserved=0 | | Type=0x06 | Sub-Type=0x01 | Flags(1 Octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved = 0| ESI Label | | Reserved = 0 | ESI Label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low order bit of the flags octet is defined as the "Single- The low order bit of the flags octet is defined as the "Single-
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.
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
site; whereas, a value of 1 means that this label is associate with a
Leaf site. The other bits must be set to 0.
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-byte portion of the 9-byte ESI Value in the ES-
Import Route Target. The format of this extended community is as Import Route Target. The high order 6-byte of the ESI incorporates
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-
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 bytes 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-Constrain 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
"MH 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
the Type field of 0x06 and the Sub-Type of 0x00. It may be advertised the Type field of 0x06 and the Sub-Type of 0x00. It may be advertised
along with MAC Advertisement routes. The procedures for using this along with MAC Advertisement routes. The procedures for using this
Extended Community are described in section 16 "MAC Mobility". Extended Community are described in section 15 "MAC Mobility".
The MAC Mobility Extended Community is encoded as a 8-octet value as The MAC Mobility Extended Community is encoded as an 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=0x00 |Flags(1 octet)| Reserved=0 | | Type=0x06 | Sub-Type=0x00 |Flags(1 octet)| Reserved=0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The low order bit of the flags octet is defined as the The low order bit of the flags octet is defined as the
"Sticky/static" flag and may be set to 1. A value of 1 means that the "Sticky/static" flag and may be set to 1. A value of 1 means that the
MAC address is static and cannot move. MAC address is static and cannot move. The sequence number is used to
ensure that PEs retain the correct MAC advertisement route when
multiple updates occur for the same MAC address.
7.8 Default Gateway Extended Community 7.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 0x0d (Default Gateway) as assigned 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).
7.9 Route Distinguisher Assignment per EVI
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 a PE.
This RD MUST be unique across all EVIs on a PE. It is RECOMMENDED to
use the Type 1 RD [RFC4364]. The value field comprises an IP address
of the PE (typically, the loopback address) followed by a number
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
ID, with the remaining high order 4 bits set to 0.
7.10 Route Targets
The EVPN route MAY carry one or more Route Target (RT) attributes.
RTs may be configured (as in IP VPNs), or may be derived
automatically.
If a PE uses RT-Constrain, the PE SHOULD advertise all such RTs using
RT Constraints. The use of RT Constrains allows each Ethernet A-D
route to reach only those PEs that are configured to 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
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
instance. The following is the procedure for performing such auto-
derivation.
+ The Global Administrator field of the RT MUST be set
to the Autonomous System (AS) number that the PE is
associated with.
+ The 12-bit VLAN ID MUST be encoded in the lowest 12 bits of
the Local Administrator field.
8. Multi-homing Functions 8. Multi-homing Functions
This section discusses the functions, procedures and associated BGP This section discusses the functions, procedures and associated BGP
routes used to support multi-homing in EVPN. This covers both multi- routes used to support multi-homing in EVPN. This covers both multi-
homed device (MHD) as well as multi-homed network (MHN) scenarios. homed device (MHD) as well as multi-homed network (MHN) scenarios.
8.1 Multi-homed Ethernet Segment Auto-Discovery 8.1 Multi-homed Ethernet Segment Auto-Discovery
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 MES (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 MUST be set to the ten octet ESI
identifier described in section 5. identifier 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-
skipping to change at page 18, line 19 skipping to change at page 19, line 37
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. MANDATORY.
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". This document does not described in section "Ethernet Segment". The Ethernet A-D route is
specify the use of the Ethernet A-D route when the Segment Identifier not needed when the Segment Identifier is set to 0 (e.g., single-
is set to 0. homed scenarios).
The Ethernet Tag ID MUST be set to MAX-ET. The Ethernet Tag ID MUST be set to MAX-ET.
The MPLS label in the NLRI MUST be set to 0. The MPLS label in the NLRI MUST be set to 0.
The "ESI Label Extended Community" MUST be included in the route. If The "ESI Label Extended Community" MUST be included in the route. If
All-Active redundancy mode is desired, then the "Single-Active" bit All-Active redundancy mode is desired, then the "Single-Active" bit
in the flags of the ESI Label Extended Community MUST be set to 0 and in the flags of the ESI Label Extended Community MUST be set to 0 and
the MPLS label in that extended community MUST be set to a valid MPLS the MPLS label in that extended community MUST be set to a valid MPLS
label value. The MPLS label in this Extended Community is referred to label value. The MPLS label in this Extended Community is referred to
skipping to change at page 20, line 45 skipping to change at page 22, line 15
stack the ESI label that PE2 has distributed for ES1. It MUST then stack the ESI label that PE2 has distributed for ES1. It MUST then
push on the MPLS label distributed by PE2 in the Inclusive Multicast push on the MPLS label distributed by PE2 in the Inclusive Multicast
Ethernet Tag route for VLAN1. The resulting packet is further Ethernet Tag route for VLAN1. The resulting packet is further
encapsulated in the P2P or MP2P LSP label stack required to transmit encapsulated in the P2P or MP2P LSP label stack required to transmit
the packet to PE2. When PE2 receives this packet, it determines the the packet to PE2. When PE2 receives this packet, it determines the
set of ESIs to replicate the packet to from the top MPLS label, after set of ESIs to replicate the packet to from the top MPLS label, after
any P2P or MP2P LSP labels have been removed. If the next label is any P2P or MP2P LSP labels have been removed. If the next label is
the ESI label assigned by PE2 for ES1, then PE2 MUST NOT forward the the ESI label assigned by PE2 for ES1, then PE2 MUST NOT forward the
packet onto ES1. If the next label is an ESI label which has not been 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 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 that in this scenario, if PE2 receives a BUM packet for VLAN1 from
CE1, then it should encapsulate the packet with an ESI label received CE1, then it SHOULD encapsulate the packet with an ESI label received
from PE1 when sending it to the PE1 in order to avoid any transient from PE1 when sending it to PE1 in order to avoid any transient loop
loop during a failure scenario impacting ES1 (e.g., port or link during a failure scenario impacting ES1 (e.g., port or link failure).
failure).
8.3.1.2. P2MP MPLS LSPs 8.3.1.2. P2MP MPLS LSPs
The non-DF PEs attached to a given ES that is operating in All-Active The non-DF PEs attached to a given ES that is operating in All-Active
redundancy mode and that use P2MP LSPs to send BUM traffic advertise redundancy mode and that use P2MP LSPs to send BUM traffic advertise
an upstream assigned ESI label in the set of Ethernet A-D per ES an upstream assigned ESI label in the set of Ethernet A-D per ES
routes for that ES. This label is upstream assigned by the PE that routes for that ES. This label is upstream assigned by the PE that
advertises the route. This label MUST be programmed by the other PEs, advertises the route. This label MUST be programmed by the other PEs,
that are connected to the ESI advertised in the route, in the context that are connected to the ESI advertised in the route, in the context
label space for the advertising PE. Further the forwarding entry for label space for the advertising PE. Further the forwarding entry for
this label must result in NOT forwarding packets received with this this label must result in NOT forwarding packets received with this
label onto the Ethernet segment that the label was distributed for. label onto the Ethernet segment that the label was distributed for.
This label MUST also be programmed by the other PEs, that import the This label MUST also be programmed by the other PEs, that import the
skipping to change at page 22, line 4 skipping to change at page 23, line 21
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 ES1 and PE3 is not connected to ES1, then PE3 MUST assigned by PE1 to ES1 and PE3 is not connected to ES1, then PE3 MUST
pop the label and flood the packet over all local ESIs in that EVPN pop the label and flood the packet over all local ESIs in that EVPN
instance. It should be noted that when PE2 sends a BUM frame over a instance. It should be noted that when PE2 sends a BUM frame over a
P2MP LSP, it should encapsulate the frame with an ESI label even P2MP LSP, it should encapsulate the frame with an ESI label even
though it is the DF for that VLAN in order to avoid any transient though it is the DF for that VLAN in order to avoid any transient
loop during a failure scenario impacting ES1 (e.g., port or link loop during a failure scenario impacting ES1 (e.g., port or link
failure). failure).
8.4 Aliasing and Backup-Path 8.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 plane 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 address this issue, EVPN introduces the concept of 'Aliasing' To address this issue, EVPN introduces the concept of 'Aliasing'
which is the ability of a PE to signal that it has reachability to an which is the ability of a PE to signal that it has reachability to an
EVPN instance on a given ES even when it has learnt no MAC addresses EVPN instance on a given ES even when it has learnt no MAC addresses
from that EVI/ES. The Ethernet A-D per EVI route is used for this from that EVI/ES. The Ethernet A-D per EVI route is used for this
purpose. A remote PE that receives a MAC advertisement route with purpose. A remote PE that receives a MAC advertisement route with
skipping to change at page 23, line 8 skipping to change at page 24, line 28
combination of Ethernet A-D routes and it SHOULD install a backup- combination of Ethernet A-D routes and it SHOULD install a backup-
path for that MAC address. path for that MAC address.
8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route 8.4.1 Constructing the Ethernet A-D per EVPN Instance (EVI) Route
This section describes the procedures used to construct the Ethernet This section describes the procedures used to construct the Ethernet
A-D per EVPN Instance (EVI) route, which is used for aliasing (as A-D per EVPN Instance (EVI) route, which is used for aliasing (as
discussed above). Support of this route is OPTIONAL. discussed above). Support of this route is OPTIONAL.
Route-Distinguisher (RD) MUST be set to the RD of the EVI that is Route-Distinguisher (RD) MUST be set to the RD of the EVI that is
advertising the NLRI. An RD MUST be assigned for a given EVI on an advertising the NLRI per section 7.9.
PE. This RD MUST be unique across all EVIs on an PE. It is
RECOMMENDED to use the Type 1 RD [RFC4364]. The value field comprises
an IP address of the PE (typically, the loopback address) followed by
a number 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 ID, with the remaining high order 4 bits set to 0.
The Ethernet Segment Identifier MUST be a ten octet entity as The Ethernet Segment Identifier MUST be a ten octet entity as
described in section "Ethernet Segment Identifier". This document described in section "Ethernet Segment Identifier". The Ethernet A-D
does not specify the use of the Ethernet A-D route when the Segment route is not needed when the Segment Identifier is set to 0.
Identifier is set to 0.
The Ethernet Tag ID is the identifier of an Ethernet Tag on the The Ethernet Tag ID is the identifier of an Ethernet Tag on the
Ethernet segment. This value may be a 12 bit VLAN ID, in which case Ethernet segment. This value may be a 12 bit VLAN ID, in which case
the low order 12 bits are set to the VLAN ID and the high order 20 the low order 12 bits are set to the VLAN ID and the high order 20
bits are set to 0. Or it may be another Ethernet Tag used by the bits are set to 0. Or it may be another Ethernet Tag used by the
EVPN. It MAY be set to the default Ethernet Tag on the Ethernet EVPN. It MAY be set to the default Ethernet Tag on the Ethernet
segment or to the value 0. segment or to the value 0.
Note that the above allows the Ethernet A-D route to be advertised Note that the above allows the Ethernet A-D route to be advertised
with one of the following granularities: with one of the following granularities:
skipping to change at page 23, line 46 skipping to change at page 25, line 11
Tag ID is set to 0). This is applicable when the PE uses Tag ID is set to 0). This is applicable when the PE uses
MAC-based disposition, or when the PE uses MPLS-based MAC-based disposition, or when the PE uses MPLS-based
disposition when no VLAN translation is required. disposition when no VLAN translation is required.
The usage of the MPLS label is described in the section on "Load The usage of the MPLS label is described in the section on "Load
Balancing of Unicast Packets". Balancing of Unicast Packets".
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.
8.4.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. RTs may be configured (as in IP VPNs), or may be derived attributes per section 7.10.
automatically.
If an PE uses Route Target Constrain [RT-CONSTRAIN], the PE SHOULD
advertise all such RTs using Route Target Constrains. The use of RT
Constrains allows each Ethernet A-D route to reach only those PEs
that are configured to import at least one RT from the set of RTs
carried in the Ethernet A-D route.
8.4.1.1.1 Auto-Derivation from the Ethernet Tag ID
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
instance. The following is the procedure for performing such auto-
derivation.
+ The Global Administrator field of the RT MUST be set to
the Autonomous System (AS) number that the PE associated
with.
+ The two octet VLAN ID MUST be encoded in the lower two
octets of the Local Administrator field.
8.5 Designated Forwarder Election 8.5 Designated Forwarder Election
Consider a CE that is a host or a router that is multi-homed directly Consider a CE that is a host or a router that is multi-homed directly
to more than one PE in an EVPN instance on a given Ethernet segment. to more than one PE in an EVPN instance on a given Ethernet segment.
One or more Ethernet Tags may be configured on the Ethernet segment. One or more Ethernet Tags may be configured on the Ethernet segment.
In this scenario only one of the PEs, referred to as the Designated In this scenario only one of the PEs, referred to as the Designated
Forwarder (DF), is responsible for certain actions: Forwarder (DF), is responsible for certain actions:
- Sending multicast and broadcast traffic, on a given Ethernet - Sending multicast and broadcast traffic, on a given Ethernet
Tag on a particular Ethernet segment, to the CE. Tag on a particular Ethernet segment, to the CE.
- Flooding unknown unicast traffic (i.e. traffic for - Flooding unknown unicast traffic (i.e. traffic for
which an PE does not know the destination MAC address), which a PE does not know the destination MAC address),
on a given Ethernet Tag on a particular Ethernet segment on a given Ethernet Tag on a particular Ethernet segment
to the CE, if the environment requires flooding of to the CE, if the environment requires flooding of
unknown unicast traffic. unknown unicast traffic.
Note that this behavior, which allows selecting a DF at the Note that this behavior, which allows selecting a DF at the
granularity of <ESI, EVI> for multicast, broadcast and unknown granularity of <ESI, EVI> for multicast, broadcast and unknown
unicast traffic, is the default behavior in this specification. unicast traffic, is the default behavior in this specification.
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 a 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 EVPN If a bridged network is multi-homed to more than one PE in an EVPN
network via switches, then the support of All-Active redundancy mode network via switches, then the support of All-Active redundancy mode
requires the bridge network to be connected to two or more PEs using requires the bridged network to be connected to two or more PEs using
a LAG. a LAG.
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 EVPN instance. In this case, the must be the active link for a given EVPN instance. In this case, the
set of Ethernet A-D per ES routes advertised by each PE MUST have the set of Ethernet A-D per ES routes advertised by each PE MUST have the
'Single-Active' bit in the flags of the ESI Label Extended Community 'Single-Active' bit in the flags of the ESI Label Extended Community
set to 1. set to 1.
The default procedure for DF election at the granularity of <ESI, The default procedure for DF election at the granularity of <ESI,
skipping to change at page 26, line 5 skipping to change at page 26, line 44
following rule: Assuming a redundancy group of N PE nodes, the PE following rule: Assuming a redundancy group of N PE nodes, the PE
with ordinal i is the DF for an EVPN instance with an associated with ordinal i is the DF for an EVPN instance with an associated
Ethernet Tag value V when (V mod N) = i. In the case where multiple Ethernet Tag value V when (V mod N) = i. In the case where multiple
Ethernet Tags are associated with a single EVPN instance, then the Ethernet Tags are associated with a single EVPN instance, then the
numerically lowest Ethernet Tag value in that EVPN instance MUST be numerically lowest Ethernet Tag value in that EVPN instance MUST be
used in the modulo function. used in the modulo function.
It should be noted that using "Originator Router's IP address" field It should be noted that using "Originator Router's IP address" field
in the Ethernet Segment route to get the PE IP address needed for the in the Ethernet Segment route to get the PE IP address needed for the
ordered list, allows for a CE to be multi-homed across different ASes ordered list, allows for a CE to be multi-homed across different ASes
if such need every arises. if such need ever arises.
4. The PE that is elected as a DF for a given EVPN instance will 4. The PE that is elected as a DF for a given EVPN instance will
unblock traffic for the Ethernet Tags associated with that EVPN unblock traffic for the Ethernet Tags associated with that EVPN
instance. Note that the DF PE unblocks multi-destination traffic in instance. Note that the DF PE unblocks multi-destination traffic in
the egress direction towards the Segment. All non-DF PEs continue to the egress direction towards the Segment. All non-DF PEs continue to
drop multi-destination traffic (for the associated EVPN instances) in drop multi-destination traffic (for the associated EVPN instances) in
the egress direction towards the Segment. the egress direction 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. In case of a Single-Active multi-homing, when a service carving. In case of a Single-Active multi-homing, when a service
moves from one PE in the RG to another PE as a result of re-carving, moves from one PE in the RG to another PE as a result of re-carving,
the PE, which ends up being the elected DF for the service, must the PE, which ends up being the elected DF for the service, SHOULD
trigger a MAC address flush notification towards the associated trigger a MAC address flush notification towards the associated
Ethernet Segment. This can be done, for e.g. using IEEE 802.1ak MVRP Ethernet Segment. This can be done, for e.g. using IEEE 802.1ak MVRP
'new' declaration. 'new' declaration.
8.6. Interoperability with Single-homing PEs 8.6. Interoperability with Single-homing PEs
Let's refer to PEs that only support single-homed CE devices as Let's refer to PEs that only support single-homed CE devices as
single-homing PEs. For single-homing PEs, all the above multi-homing single-homing PEs. For single-homing PEs, all the above multi-homing
procedures can be omitted; however, to allow for single-homing PEs to procedures can be omitted; however, to allow for single-homing PEs to
fully inter-operate with multi-homing PEs, some of the multi-homing fully inter-operate with multi-homing PEs, some of the multi-homing
procedures described above SHOULD be supported even by single-homing procedures described above SHOULD be supported even by single-homing
PEs: PEs:
- procedures related to processing Ethernet A-D route for the purpose - procedures related to processing Ethernet A-D route for the purpose
of Fast Convergence (9.2 Fast Convergence), to let single-homing PEs of Fast Convergence (8.2 Fast Convergence), to let single-homing PEs
benefit from fast convergence benefit from fast convergence
- procedures related to processing Ethernet A-D route for the purpose - procedures related to processing Ethernet A-D route for the purpose
of Aliasing (9.4 Aliasing and Backup-path), to let single-homing PEs of Aliasing (8.4 Aliasing and Backup-path), to let single-homing PEs
benefit from load balancing benefit from load balancing
- procedures related to processing Ethernet A-D route for the purpose - procedures related to processing Ethernet A-D route for the purpose
of Backup-path (9.4 Aliasing and Backup-path), to let single-homing of Backup-path (8.4 Aliasing and Backup-path), to let single-homing
PEs to benefit from the corresponding convergence improvement PEs to benefit from the corresponding convergence improvement
9. Determining Reachability to Unicast MAC Addresses 9. 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":
9.1. Local Learning 9.1. Local Learning
A particular PE must be able to learn the MAC addresses from the CEs A particular PE must be able to learn the MAC addresses from the CEs
that are connected to it. This is referred to as local learning. that are connected to it. This is referred to as local learning.
The PEs in a particular EVPN instance MUST support local data plane The PEs in a particular EVPN instance MUST support local data plane
learning using standard IEEE Ethernet learning procedures. An PE must learning using standard IEEE Ethernet learning procedures. A PE must
be capable of learning MAC addresses in the data plane when it be capable of learning MAC addresses in the data plane when it
receives packets such as the following from the CE network: receives packets such as the following from the CE network:
- DHCP requests - DHCP requests
- 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
skipping to change at page 27, line 40 skipping to change at page 28, line 31
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 another PE on another Segment such that it becomes reachable via another PE on another Segment
(e.g. with ESI Y). This is referred to as a "MAC Mobility". (e.g. with ESI Y). This is referred to as a "MAC Mobility".
Procedures to support this are described in section "MAC Mobility". Procedures to support this are described in section "MAC Mobility".
9.2. Remote learning 9.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 "remote" MAC addresses.
This document requires an PE to learn remote MAC addresses in the This document requires a PE to learn remote MAC addresses in the
control plane. In order to achieve this, each PE advertises the MAC control plane. In order to achieve this, each PE advertises the MAC
addresses it learns from its locally attached CEs in the control addresses it learns from its locally attached CEs in the control
plane, to all the other PEs in that EVPN instance, using MP-BGP and plane, to all the other PEs in that EVPN instance, using MP-BGP and
specifically the MAC Advertisement route. specifically the MAC Advertisement route.
9.2.1. Constructing the BGP EVPN MAC/IP Address Advertisement 9.2.1. Constructing the BGP EVPN MAC/IP Address Advertisement
BGP is extended to advertise these MAC addresses using the MAC/IP BGP is extended to advertise these MAC addresses using the MAC/IP
Advertisement route type in the EVPN NLRI. Advertisement route type in the EVPN NLRI.
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be the RD of the EVI that is advertising the NLRI. The
procedures for setting the RD for a given EVI are described in procedures for setting the RD for a given EVI are described in
section 8.4.1. section 7.9.
The Ethernet Segment Identifier is set to the ten octet ESI described The Ethernet Segment Identifier is set to the ten octet ESI described
in section "Ethernet Segment". in section "Ethernet Segment".
The Ethernet Tag ID may be zero or may represent a valid Ethernet Tag The Ethernet Tag ID may be zero or may represent a valid Ethernet Tag
ID. This field may be non-zero when there are multiple bridge ID. This field may be non-zero when there are multiple bridge
domains in the MAC-VRF (e.g., the PE needs to perform qualified domains in the MAC-VRF (i.e., the PE needs to perform qualified
learning for the VLANs in that MAC-VRF). learning for the VLANs in that MAC-VRF).
When the the Ethernet Tag ID in the NLRI is set to a non-zero value, When the the Ethernet Tag ID in the NLRI is set to a non-zero value,
for a particular bridge domain, then this Ethernet Tag may either be for a particular bridge domain, then this Ethernet Tag ID may either
the Ethernet tag value associated with the CE, e.g., VLAN ID, or it be the CE's Ethernet tag value (e.g., CE VLAN ID) or the EVPN
may be the Ethernet Tag Identifier, e.g., VLAN ID assigned by the provider's Ethernet tag value (e.g., provider VLAN ID). The latter
EVPN provider and mapped to the CE's Ethernet tag. The latter would would be the case if the CE Ethernet tags (e.g., CE VLAN ID) for a
be the case if the CE Ethernet tags, e.g., VLAN ID, for a particular particular bridge domain are different on different CEs.
bridge domain are different on different CEs.
The MAC address length field is in bits and it is set to 48. The The MAC address length field is in bits and it is set to 48. The MAC
encoding of a MAC address MUST be the 6-octet MAC address specified address length values other than 48 bits, are outside the scope of
by [802.1D-ORIG] [802.1D-REV]. this document. The encoding of a MAC address MUST be the 6-octet MAC
address specified by [802.1D-ORIG] [802.1D-REV].
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 needs to be advertised, it is then encoded in When a valid IP address needs to be advertised, it is then encoded in
this route. When an IP address is present, the IP Address Length this route. When an IP address is present, the IP Address Length
field is in bits and it is set to 32 or 128 bits. Other IP Address field is in bits and it is set to 32 or 128 bits. Other IP Address
Length values are outside the scope of this document. The encoding of Length values are outside the scope of this document. The encoding of
an IP address MUST be either 4 octets for IPv4 or 16 octets for IPv6. an IP address MUST be either 4 octets for IPv4 or 16 octets for IPv6.
The length field of EVPN NLRI (which is in octets and is described in The length field of EVPN NLRI (which is in octets and is described in
section 7) is sufficient to determine whether an IP address is section 7) is sufficient to determine whether an IP address is
encoded in this route and if so, whether the encoded IP address is encoded in this route and if so, whether the encoded IP address is
IPV4 or IPv6. IPV4 or IPv6.
The MPLS label1 field is encoded as 3 octets, where the high-order 20 The MPLS label1 field is encoded as 3 octets, where the high-order 20
bits contain the label value. The MPLS label1 MUST be downstream bits contain the label value. The MPLS label1 MUST be downstream
assigned and it is associated with the MAC address being advertised assigned and it is associated with the MAC address being advertised
by the advertising PE. The advertising PE uses this label when it by the advertising PE. The advertising PE uses this label when it
receives an MPLS-encapsulated packet to perform forwarding based on receives an MPLS-encapsulated packet to perform forwarding based on
the destination MAC address. The forwarding procedures are specified the destination MAC address toward the CE. The forwarding procedures
in section "Forwarding Unicast Packets" and "Load Balancing of are specified in sections 13 and 14.
Unicast Packets".
An PE may advertise the same single EVPN label for all MAC addresses A PE may advertise the same single EVPN label for all MAC addresses
in a given EVI. This label assignment methodology is referred to as a in a given EVI. This label assignment is referred to as a per EVI
per EVI label assignment. Alternatively, an PE may advertise a unique label assignment. Alternatively, a PE may advertise a unique EVPN
EVPN label per <ESI, Ethernet Tag> combination. This label assignment label per <ESI, Ethernet Tag> combination. This label assignment is
methodology is referred to as a per <ESI, Ethernet Tag> label referred to as a per <ESI, Ethernet Tag> label assignment. As a third
assignment. As a third option, an PE may advertise a unique EVPN option, a PE may advertise a unique EVPN label per MAC address. This
label per MAC address. All of these methodologies have their label assignment is referred to as a per MAC label assignment. All of
tradeoffs. The choice of a particular label assignment methodology is these label assignment methods have their tradeoffs. The choice of a
purely local to the PE that originates the route. particular label assignment methodology is purely local to the PE
that originates the route.
Per EVI label assignment requires the least number of EVPN labels, Per EVI label assignment requires the least number of EVPN labels,
but requires a MAC lookup in addition to an MPLS lookup on an egress but requires a MAC lookup in addition to an MPLS lookup on an egress
PE for forwarding. On the other hand, a unique label per <ESI, PE for forwarding. On the other hand, a unique label per <ESI,
Ethernet Tag> or a unique label per MAC allows an egress PE to Ethernet Tag> or a unique label per MAC allows an egress PE to
forward a packet that it receives from another PE, to the connected forward a packet that it receives from another PE, to the connected
CE, after looking up only the MPLS labels without having to perform a CE, after looking up only the MPLS labels without having to perform a
MAC lookup. This includes the capability to perform appropriate VLAN MAC lookup. This includes the capability to perform appropriate VLAN
ID translation on egress to the CE. ID translation on egress to the CE.
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. The use of MPLS label2 is for further study. 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 "Ethernet A-D ID, in the Unique VLAN case, as described in section 8.4.1.1.1.
Route per EVPN".
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,
then the receiving PE MUST install forwarding state for the then if the receiving PE decides to install forwarding state for the
associated MAC Address based on the MAC Advertisement route alone. associated MAC address, it MUST be based on the MAC Advertisement
route alone.
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 a non-reserved ESI, and the receiving 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 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 its forwarding state based on the received route. This ensures that
local routes are preferred to remote routes. local routes are preferred to remote routes.
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 a non-reserved ESI, then the receiving Advertisement route is set to a non-reserved ESI, then if the
PE MUST install forwarding state for a given MAC address only when receiving PE decides to install forwarding state for the associated
both the MAC Advertisement route AND the associated set of Ethernet MAC address, it MUST be when both the MAC Advertisement route AND the
A-D per ES routes have been received. associated set of Ethernet A-D per ES routes have been received. The
dependency of MAC routes installation on Ethernet A-D per ES routes,
is to ensure that MAC routes don't get accidentally installed during
mass withdraw period.
To illustrate this with an example, consider two PEs (PE1 and PE2) To illustrate this with an example, consider two PEs (PE1 and PE2)
connected to a multi-homed Ethernet Segment ES1. All-Active connected to a multi-homed Ethernet Segment ES1. All-Active
redundancy mode is assumed. A given MAC address M1 is learnt by PE1 redundancy mode is assumed. A given MAC address M1 is learnt by PE1
but not PE2. On PE3, the following states may arise: but not PE2. On PE3, the following states may arise:
T1- When the MAC Advertisement Route from PE1 and the set of Ethernet T1- When the MAC Advertisement Route from PE1 and the set of Ethernet
A-D per ES routes from PE1 and PE2 are received, PE3 can forward A-D per ES routes and Ethernet A-D per EVI routes from PE1 and PE2
traffic destined to M1 to both PE1 and PE2. are received, PE3 can forward traffic destined to M1 to both PE1 and
PE2.
T2- If after T1, PE1 withdraws its set of Ethernet A-D per ES routes, T2- If after T1, PE1 withdraws its set of Ethernet A-D per ES routes,
then PE3 forwards traffic destined to M1 to PE2 only. then PE3 forwards traffic destined to M1 to PE2 only.
T3- If after T1, PE2 withdraws its set of Ethernet A-D per ES routes, T2'- If after T1, PE2 withdraws its set of Ethernet A-D per ES
then PE3 forwards traffic destined to M1 to PE1 only. routes, then PE3 forwards traffic destined to M1 to PE1 only.
T4- If after T1, PE1 withdraws its MAC Advertisement route, then PE3 T2''- If after T1, PE1 withdraws its MAC Advertisement route, then
treats traffic to M1 as unknown unicast. Note, here, that had PE2 PE3 treats traffic to M1 as unknown unicast.
also advertised a MAC route for M1 before PE1 withdraws its MAC
route, then PE3 would have continued forwarding traffic destined to T3- PE2 also advertises a MAC route for M1 and then PE1 withdraws its
M1 to PE2. MAC route for M1. PE3 continues forwarding traffic destined to M1
to both PE1 and PE2. In other words, despite M1 withdrawal by PE1,
PE3 forwards the traffic destined to M1 to both PE1 and PE2. This is
because a flow from the CE, resulting in M1 traffic getting hashed to
PE1, can get terminated resulting in M1 to aged out in PE1; however,
M1 can be reachable by both PE1 and PE2.
10. ARP and ND 10. ARP and ND
The IP address field in the MAC advertisement route may optionally The IP address field in the MAC advertisement route may optionally
carry one of the IP addresses associated with the MAC address. This carry one of the IP addresses associated with the MAC address. This
provides an option which can be used to minimize the flooding of ARP provides an option which can be used to minimize the flooding of ARP
or Neighbor Discovery (ND) messages over the MPLS network and to or Neighbor Discovery (ND) messages over the MPLS network and to
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 EVPN network. An PE may learn on end-stations/hosts connected to the EVPN network. A 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
binding by snooping certain messages to or from a CE. When an PE binding by snooping certain messages to or from a CE. When a PE
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 MAC address.
When the IP address is dissociated with the MAC address, then the MAC When the IP address is dissociated with the MAC address, then the MAC
advertisement route with that particular IP address MUST be advertisement route with that particular IP address MUST be
withdrawn. withdrawn.
When an PE receives an ARP request for an IP address from a CE, and When a PE receives an ARP request for an IP address from a CE, and if
if the PE has the MAC address binding for that IP address, the PE the PE has the MAC address binding for that IP address, the PE SHOULD
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
performs such function is called the default gateway. In this case performs such function is called the default gateway for the EVPN
when the PE receives an ARP Request for the IP address of the default instance. In this case when the PE receives an ARP Request for the IP
gateway, the PE originates an ARP Reply. address configured as the default gateway address, the PE originates
an ARP Reply.
Each PE that acts as a default gateway for a given EVPN instance MAY Each PE that acts as a default gateway for a given EVPN instance MAY
advertise in the EVPN control plane its default gateway MAC address advertise in the EVPN control plane its default gateway MAC address
using the MAC advertisement route, and indicates that such route is using the MAC/IP advertisement route, and indicates that such route
associated with the default gateway. This is accomplished by is associated with the default gateway. This is accomplished by
requiring the route to carry the Default Gateway extended community requiring the route to carry the Default Gateway extended community
defined in [Section 7.8 Default Gateway Extended Community]. The ESI defined in [Section 7.8 Default Gateway Extended Community]. The ESI
field is set to zero when advertising the MAC route with the Default field is set to zero when advertising the MAC route with the Default
Gateway extended community. Gateway extended community.
The IP address field of the MAC/IP advertisement route is set to the
default GW IP address for that subnet (e.g., EVPN instance). For a
given subnet (e.g., VLAN or EVPN instance), the default GW IP address
is the same across all the participant PEs. The inclusion of this IP
address enables the receiving PE to check its configured default GW
IP address against the one received in the MAC/IP advertisement route
for that subnet (or EVPN instance) and if there is a discrepancy,
then the PE SHOULD notify the operator and log an error message.
Unless it is known a priori (by means outside of this document) that Unless it is known a priori (by means outside of this document) that
all PEs of a given EVPN instance act as a default gateway for that all PEs of a given EVPN instance act as a default gateway for that
EVPN instance, the MPLS label MUST be set to a valid downstream EVPN instance, the MPLS label MUST be set to a valid downstream
assigned label. assigned label.
Furthermore, even if all PEs of a given EVPN instance do act as a Furthermore, even if all PEs of a given EVPN instance do act as a
default gateway for that EVPN instance, but only some, but not all, default gateway for that EVPN instance, but only some, but not all,
of these PEs have sufficient (routing) information to provide inter- of these PEs have sufficient (routing) information to provide inter-
subnet routing for all the inter-subnet traffic originated within the subnet routing for all the inter-subnet traffic originated within the
subnet associated with the EVPN instance, then when such PE subnet associated with the EVPN instance, then when such PE
skipping to change at page 32, line 8 skipping to change at page 33, line 18
EVPN instance, and the same default gateway MAC address is used EVPN instance, and the same default gateway MAC address is used
across all gateway devices, then no such advertisement is needed. across all gateway devices, then no such advertisement is needed.
However, if each default gateway uses a different MAC address, then However, if each default gateway uses a different MAC address, then
each default gateway needs to be aware of other gateways' MAC each default gateway needs to be aware of other gateways' MAC
addresses and thus the need for such advertisement. This is called addresses and thus the need for such advertisement. This is called
MAC address aliasing since a single default GW can be represented by MAC address aliasing since a single default GW can be represented by
multiple MAC addresses. multiple MAC addresses.
Each PE that receives this route and imports it as per procedures Each PE that receives this route and imports it as per procedures
specified in this document follows the procedures in this section specified in this document follows the procedures in this section
when replying to ARP Requests that it receives if such Requests are when replying to ARP Requests that it receives.
for the IP address in the received EVPN route.
Each PE that acts as a default gateway for a given EVPN instance that Each PE that acts as a default gateway for a given EVPN instance that
receives this route and imports it as per procedures specified in receives this route and imports it as per procedures specified in
this document MUST create MAC forwarding state that enables it to this document MUST create MAC forwarding state that enables it to
apply IP forwarding to the packets destined to the MAC address apply IP forwarding to the packets destined to the MAC address
carried in the route. carried in the route.
11. Handling of Multi-Destination Traffic 11. Handling of Multi-Destination Traffic
Procedures are required for a given PE to send broadcast or multicast Procedures are required for a given PE to send broadcast or multicast
skipping to change at page 32, line 39 skipping to change at page 33, line 48
Each PE MUST advertise an "Inclusive Multicast Ethernet Tag Route" to Each PE MUST advertise an "Inclusive Multicast Ethernet Tag Route" to
enable the above. The following subsection provides the procedures to enable the above. The following subsection provides the procedures to
construct the Inclusive Multicast Ethernet Tag route. Subsequent construct the Inclusive Multicast Ethernet Tag route. Subsequent
subsections describe in further detail its usage. subsections describe in further detail its usage.
11.1. Construction of the Inclusive Multicast Ethernet Tag Route 11.1. Construction of the Inclusive Multicast Ethernet Tag Route
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be the RD of the EVI that is advertising the NLRI. The
procedures for setting the RD for a given EVPN instance on a PE are procedures for setting the RD for a given EVPN instance on a PE are
described in section 8.4.1. described in section 7.9.
The Ethernet Tag ID is the identifier of the Ethernet Tag. It MAY be The Ethernet Tag ID is the identifier of the Ethernet Tag. It may be
set to 0 or to a valid Ethernet Tag value. set to 0 or to a valid Ethernet Tag value.
The Originating Router's IP address MUST be set to an IP address of The Originating Router's IP address MUST be set to an IP address of
the PE. This address SHOULD be common for all the EVIs on the PE the PE. This address SHOULD be common for all the EVIs on the PE
(e.,g., this address may be PE's loopback address). The IP Address (e.,g., this address may be PE's loopback address). The IP Address
Length field is in bits. Length field is in bits.
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 same IP address as the one carried in the Originating be set to the same IP address as the one carried in the Originating
Router's IP Address field. Router's IP Address field.
The BGP advertisement for the Inclusive Multicast Ethernet Tag route The BGP advertisement for the Inclusive Multicast Ethernet Tag route
MUST also carry one or more Route Target (RT) attributes. The MUST also carry one or more Route Target (RT) attributes. The
assignment of RTs described in the section on "Constructing the BGP assignment of RTs described in the section 7.10 MUST be followed.
EVPN MAC Address Advertisement" MUST be followed.
11.2. P-Tunnel Identification 11.2. P-Tunnel Identification
In order to identify the P-Tunnel used for sending broadcast, unknown In order to identify the P-Tunnel used for sending broadcast, unknown
unicast or multicast traffic, the Inclusive Multicast Ethernet Tag unicast or multicast traffic, the Inclusive Multicast Ethernet Tag
route MUST carry a "PMSI Tunnel Attribute" as specified in [BGP route MUST carry a "PMSI Tunnel Attribute" as specified in [BGP
MVPN]. MVPN].
Depending on the technology used for the P-tunnel for the EVPN Depending on the technology used for the P-tunnel for the EVPN
instance on the PE, the PMSI Tunnel attribute of the Inclusive instance on the PE, the PMSI Tunnel attribute of the Inclusive
Multicast Ethernet Tag route is constructed as follows. Multicast Ethernet Tag route is constructed as follows.
+ If the PE that originates the advertisement uses a + If the PE that originates the advertisement uses a
P-Multicast tree for the P-tunnel for EVPN, the PMSI P-Multicast tree for the P-tunnel for EVPN, the PMSI
Tunnel attribute MUST contain the identity of the tree Tunnel attribute MUST contain the identity of the tree
(note that the PE could create the identity of the (note that the PE could create the identity of the
tree prior to the actual instantiation of the tree). tree prior to the actual instantiation of the tree).
+ An PE that uses a P-Multicast tree for the P-tunnel MAY + A PE that uses a P-Multicast tree for the P-tunnel MAY
aggregate two or more EVPN instances (EVIs) present aggregate two or more EVPN instances (EVIs) present
on the PE onto the same tree. In this case, in addition on the PE onto the same tree. In this case, in addition
to carrying the identity of the tree, the PMSI Tunnel to carrying the identity of the tree, the PMSI Tunnel
attribute MUST carry an MPLS upstream assigned label which attribute MUST carry an MPLS upstream assigned label which
the PE has bound uniquely to the EVI associated with this the PE has bound uniquely to the EVI associated with this
update (as determined by its RTs). update (as determined by its RTs).
If the PE has already advertised Inclusive Multicast If the PE has already advertised Inclusive Multicast
Ethernet Tag routes for two or more EVIs that it now Ethernet Tag routes for two or more EVIs that it now
desires to aggregate, then the PE MUST re-advertise desires to aggregate, then the PE MUST re-advertise
skipping to change at page 34, line 21 skipping to change at page 35, line 28
unknown unicast traffic to other PEs. If PEs learn CE MAC addresses unknown unicast traffic to other PEs. If PEs learn CE MAC addresses
via a control plane protocol, the PEs can then distribute MAC via a control plane protocol, the PEs can then distribute MAC
addresses via BGP, and all unicast MAC addresses will be learnt prior addresses via BGP, and all unicast MAC addresses will be learnt prior
to traffic to those destinations. to traffic to those destinations.
However, if a destination MAC address of a received packet is not However, if a destination MAC address of a received packet is not
known by the PE, the PE may have to flood the packet. When flooding, known by the PE, the PE may have to flood the packet. When flooding,
one must take into account "split horizon forwarding" as follows: The one must take into account "split horizon forwarding" as follows: The
principles behind the following procedures are borrowed from the principles behind the following procedures are borrowed from the
split horizon forwarding rules in VPLS solutions [RFC4761] and split horizon forwarding rules in VPLS solutions [RFC4761] and
[RFC4762]. When an PE capable of flooding (say PEx) receives an [RFC4762]. When a PE capable of flooding (say PEx) receives an
unknown destination MAC address, it floods the frame. If the frame unknown destination MAC address, it floods the frame. If the frame
arrived from an attached CE, PEx must send a copy of the frame to arrived from an attached CE, PEx must send a copy of that frame on
every other attached CE participating in that EVPN instance, on a every Ethernet Segment (belonging to that EVI) for which it is the
different ESI than the one it received the frame on, as long as the DF, other than the Ethernet Segment on which it received the frame.
PE is the DF for the egress ESI. In addition, the PE must flood the In addition, the PE must flood the frame to all other PEs
frame to all other PEs participating in that EVPN instance. If, on participating in that EVPN instance. If, on the other hand, the frame
the other hand, the frame arrived from another PE (say PEy), PEx must arrived from another PE (say PEy), PEx must send a copy of the packet
send a copy of the packet only to attached CEs as long as it is the on each Ethernet Segment (belonging to that EVI) for which it is the
DF for the egress ESI. PEx MUST NOT send the frame to other PEs, DF. PEx MUST NOT send the frame to other PEs, since PEy would have
since PEy would have already done so. Split horizon forwarding rules already done so. Split horizon forwarding rules apply to unknown MAC
apply to unknown MAC addresses. addresses.
Whether or not to flood packets to unknown destination MAC addresses Whether or not to flood packets to unknown destination MAC addresses
should be an administrative choice, depending on how learning happens should be an administrative choice, depending on how learning happens
between CEs and PEs. between CEs and PEs.
The PEs in a particular EVPN instance may use ingress replication The PEs in a particular EVPN instance may use ingress replication
using RSVP-TE P2P LSPs or LDP MP2P LSPs for sending unknown unicast using RSVP-TE P2P LSPs or LDP MP2P LSPs for sending unknown unicast
traffic to other PEs. Or they may use RSVP-TE P2MP or LDP P2MP for traffic to other PEs. Or they may use RSVP-TE P2MP or LDP P2MP for
sending such traffic to other PEs. sending such traffic to other PEs.
skipping to change at page 34, line 44 skipping to change at page 36, line 4
Whether or not to flood packets to unknown destination MAC addresses Whether or not to flood packets to unknown destination MAC addresses
should be an administrative choice, depending on how learning happens should be an administrative choice, depending on how learning happens
between CEs and PEs. between CEs and PEs.
The PEs in a particular EVPN instance may use ingress replication The PEs in a particular EVPN instance may use ingress replication
using RSVP-TE P2P LSPs or LDP MP2P LSPs for sending unknown unicast using RSVP-TE P2P LSPs or LDP MP2P LSPs for sending unknown unicast
traffic to other PEs. Or they may use RSVP-TE P2MP or LDP P2MP for traffic to other PEs. Or they may use RSVP-TE P2MP or LDP P2MP for
sending such traffic to other PEs. sending such traffic to other PEs.
12.1. Ingress Replication 12.1. Ingress Replication
If ingress replication is in use, the P-Tunnel attribute, carried in If ingress replication is in use, the P-Tunnel attribute, carried in
the Inclusive Multicast Ethernet Tag routes for the EVPN instance, the Inclusive Multicast Ethernet Tag routes for the EVPN instance,
specifies the downstream label that the other PEs can use to send specifies the downstream label that the other PEs can use to send
unknown unicast, multicast or broadcast traffic for that EVPN unknown unicast, multicast or broadcast traffic for that EVPN
instance to this particular PE. instance to this particular PE.
The PE that receives a packet with this particular MPLS label MUST The PE that receives a packet with this particular MPLS label MUST
treat the packet as a broadcast, multicast or unknown unicast packet. treat the packet as a broadcast, multicast or unknown unicast packet.
Further if the MAC address is a unicast MAC address, the PE MUST Further if the MAC address is a unicast MAC address, the PE MUST
treat the packet as an unknown unicast packet. treat the packet as an unknown unicast packet.
12.2. P2MP MPLS LSPs 12.2. P2MP MPLS LSPs
The procedures for using P2MP LSPs are very similar to VPLS The procedures for using P2MP LSPs are very similar to VPLS
procedures [VPLS-MCAST]. The P-Tunnel attribute used by an PE for procedures [VPLS-MCAST]. The P-Tunnel attribute used by a PE for
sending unknown unicast, broadcast or multicast traffic for a sending unknown unicast, broadcast or multicast traffic for a
particular EVPN instance is advertised in the Inclusive Ethernet Tag particular EVPN instance is advertised in the Inclusive Ethernet Tag
Multicast route as described in section "Handling of Multi- Multicast route as described in section "Handling of Multi-
Destination Traffic". Destination Traffic".
The P-Tunnel attribute specifies the P2MP LSP identifier. This is the The P-Tunnel attribute specifies the P2MP LSP identifier. This is the
equivalent of an Inclusive tree in [VPLS-MCAST]. Note that multiple equivalent of an Inclusive tree in [VPLS-MCAST]. Note that multiple
Ethernet Tags, which may be in different EVPN instances, may use the Ethernet Tags, which may be in different EVPN instances, may use the
same P2MP LSP, using upstream labels [VPLS-MCAST]. This is the same P2MP LSP, using upstream labels [VPLS-MCAST]. This is the
equivalent of an Aggregate Inclusive tree in [VPLS-MCAST]. When P2MP equivalent of an Aggregate Inclusive tree in [VPLS-MCAST]. When P2MP
skipping to change at page 35, line 38 skipping to change at page 36, line 45
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 an 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, 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 the source MAC address MAY be used to authenticate the
CE and determine that traffic from the host can be allowed into the CE and determine that traffic from the host can be allowed into the
network. Source MAC lookup MAY also be used for local MAC address network. Source MAC lookup MAY also be used for local MAC address
learning. 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
skipping to change at page 36, line 14 skipping to change at page 37, line 23
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
PE, the packet is encapsulated in the EVPN MPLS label advertised by PE, the packet is encapsulated in the EVPN MPLS label advertised by
the remote PE, for that MAC address, and in the MPLS LSP label stack the remote PE, for that MAC address, and in the MPLS LSP label stack
to reach the remote PE. to reach the remote PE.
If the MAC address is unknown and if the administrative policy on the If the MAC address is unknown and if the administrative policy on the
PE requires flooding of unknown unicast traffic then: PE requires flooding of unknown unicast traffic then:
- The PE MUST flood the packet to other PEs. The PE MUST first - The PE MUST flood the packet to other PEs. The PE MUST first
encapsulate the packet in the ESI MPLS label as described in section encapsulate the packet in the ESI MPLS label as described in section
8.3. If ingress replication is used, the packet MUST be replicated 8.3. If ingress replication is used, the packet MUST be replicated to
one or more times to each remote PE with the outermost label being an each remote PE with the VPN label being an MPLS label determined as
MPLS label determined as follows: This is the MPLS label advertised follows: This is the MPLS label advertised by the remote PE in a PMSI
by the remote PE in a PMSI Tunnel Attribute in the Inclusive Tunnel Attribute in the Inclusive Multicast Ethernet Tag route for an
Multicast Ethernet Tag route for an <EVPN instance, Ethernet Tag> <EVPN instance, Ethernet Tag> combination. The Ethernet Tag in the
combination. The Ethernet Tag in the route must be the same as the route may be the same as the Ethernet Tag associated with the
Ethernet Tag associated with the interface on which the ingress PE interface on which the ingress PE receives the packet. If P2MP LSPs
receives the packet. If P2MP LSPs are being used the packet MUST be are being used the packet MUST be sent on the P2MP LSP that the PE is
sent on the P2MP LSP that the PE is the root of for the Ethernet Tag the root of for the Ethernet Tag in the EVPN instance. If the same
in the EVPN instance. If the same P2MP LSP is used for all Ethernet P2MP LSP is used for all Ethernet Tags, then all the PEs in the EVPN
Tags, then all the PEs in the EVPN instance MUST be the leaves of the instance MUST be the leaves of the P2MP LSP. If a distinct P2MP LSP
P2MP LSP. If a distinct P2MP LSP is used for a given Ethernet Tag in is used for a given Ethernet Tag in the EVPN instance, then only the
the EVPN instance, then only the PEs in the Ethernet Tag MUST be the PEs in the Ethernet Tag MUST be the leaves of the P2MP LSP. The
leaves of the P2MP LSP. The packet MUST be encapsulated in the P2MP packet MUST be encapsulated in the P2MP LSP label stack.
LSP label stack.
If the MAC address is unknown then, if the administrative policy on If the MAC address is unknown then, if the administrative policy on
the PE does not allow flooding of unknown unicast traffic: the PE does not allow flooding of unknown unicast traffic:
- The PE MUST drop the packet. - The PE MUST drop the packet.
13.2. Forwarding packets received from a remote PE 13.2. Forwarding packets received from a remote PE
This section described the procedures for forwarding known and This section described the procedures for forwarding known and
unknown unicast packets received from a remote PE. unknown unicast packets received from a remote PE.
13.2.1. Unknown Unicast Forwarding 13.2.1. Unknown Unicast Forwarding
When an PE receives an MPLS packet from a remote PE then, after When a PE receives an MPLS packet from a remote PE then, after
processing the MPLS label stack, if the top MPLS label ends up being processing the MPLS label stack, if the top MPLS label ends up being
a P2MP LSP label associated with an EVPN instance or in case of a P2MP LSP label associated with an EVPN instance or in case of
ingress replication the downstream label advertised in the P-Tunnel ingress replication the downstream label advertised in the P-Tunnel
attribute, and after performing the split horizon procedures attribute, and after performing the split horizon procedures
described in section "Split Horizon": described in section 8.3:
- If the PE is the designated forwarder of BUM traffic on a - If the PE is the designated forwarder of BUM traffic on a
particular set of ESIs for the Ethernet Tag, the default behavior is particular set of ESIs for the Ethernet Tag, the default behavior is
for the PE to flood the packet on these ESIs. In other words, the for the PE to flood the packet on these ESIs. In other words, the
default behavior is for the PE to assume that for BUM traffic, it is default behavior is for the PE to assume that for BUM traffic, it is
not required to perform a destination MAC address lookup. As an not required to perform a destination MAC address lookup. As an
option, the PE may perform a destination MAC lookup to flood the option, the PE may perform a destination MAC lookup to flood the
packet to only a subset of the CE interfaces in the Ethernet Tag. For packet to only a subset of the CE interfaces in the Ethernet Tag. For
instance the PE may decide to not flood an BUM packet on certain instance the PE may decide to not flood an BUM packet on certain
Ethernet segments even if it is the DF on the Ethernet segment, based Ethernet segments even if it is the DF on the Ethernet segment, based
skipping to change at page 37, line 28 skipping to change at page 38, line 35
in the unicast MAC advertisements, then the PE either forwards the in the unicast MAC advertisements, then the PE either forwards the
packet based on CE next-hop forwarding information associated with packet based on CE next-hop forwarding information associated with
the label or does a destination MAC address lookup to forward the the label or does a destination MAC address lookup to forward the
packet to a CE. packet to a CE.
14. Load Balancing of Unicast Frames 14. Load Balancing of Unicast Frames
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.
14.1. Load balancing of traffic from an PE to remote CEs 14.1. Load balancing of traffic from a 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.
14.1.1 Single-Active Redundancy Mode 14.1.1 Single-Active Redundancy Mode
For a given ES, if the remote PE has imported the set of Ethernet A-D For a given ES, if the remote PE has imported the set of Ethernet A-D
per ES routes from at least one PE, where the "Single-Active" flag in per ES routes from at least one PE, where the "Single-Active" flag in
skipping to change at page 38, line 36 skipping to change at page 39, line 43
PE MUST deduce that the ES is operating in All-Active redundancy PE MUST deduce that the ES is operating in All-Active redundancy
mode. A remote PE that receives a MAC advertisement route with non- mode. A remote PE that receives a MAC advertisement route with non-
reserved ESI SHOULD consider the advertised MAC address to be reserved ESI SHOULD consider the advertised MAC address to be
reachable via all PEs that have advertised reachability to that MAC reachable via all PEs that have advertised reachability to that MAC
address' EVI/ES via the combination of an Ethernet A-D per EVI route address' EVI/ES via the combination of an Ethernet A-D per EVI route
for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D for that EVI/ES (and Ethernet Tag if applicable) AND an Ethernet A-D
per ES route for that ES. The remote PE MUST use received MAC per ES route for that ES. The remote PE MUST use received MAC
Advertisement routes and Ethernet A-D per EVI/per ES routes to Advertisement routes and Ethernet A-D per EVI/per ES routes to
construct the set of next-hops for the advertised MAC address. construct the set of next-hops for the advertised MAC address.
The remote PE MUST use the MAC advertisement and eligible Ethernet A- Each next-hop comprises an MPLS label stack that is to be used by the
D routes to construct the set of next-hops that it can use to send egress PE to forward the packet. This label stack is determined as
the packet to the destination MAC. Each next-hop comprises an MPLS follows:
label stack that is to be used by the egress PE to 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 for
then the next-hop and MPLS label stack is constructed as a result of that PE, then the next-hop and MPLS label stack is constructed as a
the Ethernet A-D routes. Note that the following description applies result of the Ethernet A-D routes. Note that the following
to determining the label stack for a particular next-hop to reach a description applies to determining the label stack for a particular
given PE, from which the remote PE has received and imported Ethernet next-hop to reach a given PE, from which the remote PE has received
A-D routes that have the matching ESI and Ethernet Tag as the one and imported Ethernet A-D routes that have the matching ESI and
present in the MAC advertisement. The Ethernet A-D routes mentioned Ethernet Tag as the one present in the MAC advertisement. The
in the following description refer to the ones imported from this Ethernet A-D routes mentioned in the following description refer to
given PE. the ones imported from this given PE.
-If a set of Ethernet A-D per ES routes for that ES AND an Ethernet -If a set of Ethernet A-D per ES routes for that ES AND an Ethernet
A-D route per EVI exist, then the label from that latter route must A-D route per EVI exist, only then the label from that latter route
be used. must be used.
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 source MAC address
VLAN1 (mapped to EVI1). A remote PE, say PE3, is able to learn that MAC1 on VLAN1 (mapped to EVI1). A remote PE, say PE3, is able to
MAC1 is reachable via PE1 and PE2. Both PE1 and PE2 may advertise learn that MAC1 is reachable via PE1 and PE2. Both PE1 and PE2 may
MAC1 in BGP if they receive packets with MAC1 from CE1. If this is advertise MAC1 in BGP if they receive packets with MAC1 from CE1. If
not the case, and if MAC1 is advertised only by PE1, PE3 still this is not the case, and if MAC1 is advertised only by PE1, PE3
considers MAC1 as reachable via both PE1 and PE2 as both PE1 and PE2 still considers MAC1 as reachable via both PE1 and PE2 as both PE1
advertise a set of Ethernet A-D per ES routes for ES1 as well as an and PE2 advertise a set of Ethernet A-D per ES routes for ES1 as well
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 and 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 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 39, line 44 skipping to change at page 40, line 49
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
it can pick one out of multiple possible paths to reach the it can pick one out of multiple possible paths to reach the
particular remote PE using regular MPLS procedures. For instance, if particular remote PE using regular MPLS procedures. For instance, if
the tunneling technology is based on RSVP-TE LSPs, and PE3 decides to the tunneling technology is based on RSVP-TE LSPs, and PE3 decides to
send a particular packet to PE1, then PE3 can choose from multiple send a particular packet to PE1, then PE3 can choose from multiple
RSVP-TE LSPs that have PE1 as their destination. RSVP-TE LSPs that have PE1 as their destination.
When PE1 or PE2 receive the packet destined for CE1 from PE3, if the When PE1 or PE2 receive the packet destined for CE1 from PE3, if the
packet is a unicast MAC packet it is forwarded to CE1. If it is a packet is a known unicast, it is forwarded to CE1. If it is a BUM
multicast or broadcast MAC packet then only one of PE1 or PE2 must packet then only one of PE1 or PE2 must forward the packet to the CE.
forward the packet to the CE. Which of PE1 or PE2 forward this packet Which of PE1 or PE2 forward this packet to the CE is determined based
to the CE is determined based on which of the two is the DF. on which of the two is the DF.
If the connectivity between the multi-homed CE and one of the PEs
that it is attached to, fails, the PE MUST withdraw the set of
Ethernet A-D per ES routes that had been previously advertised for
that ES. When the MAC entry on the PE ages out, the PE MUST withdraw
the MAC address from BGP. Note that to aid convergence, the Ethernet
Tag A-D routes MAY be withdrawn before the MAC routes. This enables
the remote PEs to remove the MPLS next-hop to this particular PE from
the set of MPLS next-hops that can be used to forward traffic to the
CE. For further details and procedures on withdrawal of EVPN route
types in the event of PE to CE failures please section "PE to CE
Network Failures".
14.2. Load balancing of traffic between an PE and a local CE 14.2. Load balancing of traffic between a PE and a local CE
A CE may be configured with more than one interface connected to A CE may be configured with more than one interface connected to
different PEs or the same PE for load balancing, using a technology different PEs or the same PE for load balancing, using a technology
such as LAG. The PE(s) and the CE can load balance traffic onto these such as LAG. The PE(s) and the CE can load balance traffic onto these
interfaces using one of the following mechanisms. interfaces using one of the following mechanisms.
14.2.1. Data plane learning 14.2.1. Data plane learning
Consider that the PEs perform data plane learning for local MAC Consider that the PEs perform data plane learning for local MAC
addresses learned from local CEs. This enables the PE(s) to learn a addresses learned from local CEs. This enables the PE(s) to learn a
skipping to change at page 40, line 34 skipping to change at page 41, line 28
if the technology between the PE and the CE supports multi-pathing. if the technology between the PE and the CE supports multi-pathing.
The PEs can now load balance traffic destined to that MAC address on The PEs can now load balance traffic destined to that MAC address on
the multiple interfaces. the multiple interfaces.
Whether the CE can load balance traffic that it generates on the Whether the CE can load balance traffic that it generates on the
multiple interfaces is dependent on the CE implementation. multiple interfaces is dependent on the CE implementation.
14.2.2. Control plane learning 14.2.2. Control plane learning
The CE can be a host that advertises the same MAC address using a The CE can be a host that advertises the same MAC address using a
control protocol on both interfaces. This enables the PE(s) to learn control protocol on all interfaces. This enables the PE(s) to learn
the host's MAC address and associate it with one or more interfaces. the host's MAC address and associate it with all interfaces. The PEs
The PEs can now load balance traffic destined to the host on the can now load balance traffic destined to the host on all these
multiple interfaces. The host can also load balance the traffic it interfaces. The host can also load balance the traffic it generates
generates onto these interfaces and the PE that receives the traffic onto these interfaces and the PE that receives the traffic employs
employs EVPN forwarding procedures to forward the traffic. EVPN forwarding procedures to forward the traffic.
15. MAC Mobility 15. MAC Mobility
It is possible for a given host or end-station (as defined by its MAC It is possible for a given host or end-station (as defined by its MAC
address) to move from one Ethernet segment to another; this is address) to move from one Ethernet segment to another; this is
referred to as 'MAC Mobility' or 'MAC move' and it is different from referred to as 'MAC Mobility' or 'MAC move' and it is different from
the multi-homing situation in which a given MAC address is reachable the multi-homing situation in which a given MAC address is reachable
via multiple PEs for the same Ethernet segment. In a MAC move, there via multiple PEs for the same Ethernet segment. In a MAC move, there
would be two sets of MAC Advertisement routes, one set with the new would be two sets of MAC Advertisement routes, one set with the new
Ethernet segment and one set with the previous Ethernet segment, and Ethernet segment and one set with the previous Ethernet segment, and
skipping to change at page 43, line 33 skipping to change at page 44, line 29
described in section "Handling of Multi-Destination Traffic". A given described in section "Handling of Multi-Destination Traffic". A given
broadcast packet must be sent to all the remote PEs. However a given broadcast packet must be sent to all the remote PEs. However a given
multicast packet for a multicast flow may be sent to only a subset of multicast packet for a multicast flow may be sent to only a subset of
the PEs. Specifically a given multicast flow may be sent to only the PEs. Specifically a given multicast flow may be sent to only
those PEs that have receivers that are interested in the multicast those PEs that have receivers that are interested in the multicast
flow. Determining which of the PEs have receivers for a given flow. Determining which of the PEs have receivers for a given
multicast flow is done using explicit tracking described below. multicast flow is done using explicit tracking described below.
16.2. P2MP LSPs 16.2. P2MP LSPs
An PE may use an "Inclusive" tree for sending an BUM packet. This A PE may use an "Inclusive" tree for sending an BUM packet. This
terminology is borrowed from [VPLS-MCAST]. terminology is borrowed from [VPLS-MCAST].
A variety of transport technologies may be used in the SP network. A variety of transport technologies may be used in the SP network.
For inclusive P-Multicast trees, these transport technologies include For inclusive P-Multicast trees, these transport technologies include
point-to-multipoint LSPs created by RSVP-TE or mLDP. point-to-multipoint LSPs created by RSVP-TE or mLDP.
16.2.1. Inclusive Trees 16.2.1. Inclusive Trees
An Inclusive Tree allows the use of a single multicast distribution An Inclusive Tree allows the use of a single multicast distribution
tree, referred to as an Inclusive P-Multicast tree, in the SP network tree, referred to as an Inclusive P-Multicast tree, in the SP network
to carry all the multicast traffic from a specified set of EVPN to carry all the multicast traffic from a specified set of EVPN
instances on a given PE. A particular P-Multicast tree can be set up instances on a given PE. A particular P-Multicast tree can be set up
to carry the traffic originated by sites belonging to a single EVPN to carry the traffic originated by sites belonging to a single EVPN
instance, or to carry the traffic originated by sites belonging to instance, or to carry the traffic originated by sites belonging to
several EVPN instances. The ability to carry the traffic of more than several EVPN instances. The ability to carry the traffic of more than
one EVPN instance on the same tree is termed 'Aggregation' and the one EVPN instance on the same tree is termed 'Aggregation' and the
tree is called an Aggregate Inclusive P-Multicast tree or Aggregate tree is called an Aggregate Inclusive P-Multicast tree or Aggregate
Inclusive tree for short. The Aggregate Inclusive tree needs to Inclusive tree for short. The Aggregate Inclusive tree needs to
include every PE that is a member of any of the EVPN instances that include every PE that is a member of any of the EVPN instances that
are using the tree. This implies that an PE may receive multicast are using the tree. This implies that a PE may receive BUM traffic
traffic for a multicast stream even if it doesn't have any receivers even if it doesn't have any receivers that are interested in
that are interested in receiving traffic for that stream. receiving that traffic.
An Inclusive or Aggregate Inclusive tree as defined in this document An Inclusive or Aggregate Inclusive tree as defined in this document
is a P2MP tree. A P2MP tree is used to carry traffic only for EVPN is a P2MP tree. A P2MP tree is used to carry traffic only for EVPN
CEs that are connected to the PE that is the root of the tree. CEs that are connected to the PE that is the root of the tree.
The procedures for signaling an Inclusive tree are the same as those The procedures for signaling an Inclusive tree are the same as those
in [VPLS-MCAST] with the VPLS-AD route replaced with the Inclusive in [VPLS-MCAST] with the VPLS-AD route replaced with the Inclusive
Multicast Ethernet Tag route. The P-Tunnel attribute [VPLS-MCAST] for Multicast Ethernet Tag route. The P-Tunnel attribute [VPLS-MCAST] for
an Inclusive tree is advertised with the Inclusive Multicast Ethernet an Inclusive tree is advertised with the Inclusive Multicast Ethernet
Tag route as described in section "Handling of Multi-Destination Tag route as described in section "Handling of Multi-Destination
Traffic". Note that for an Aggregate Inclusive tree, an PE can Traffic". Note that for an Aggregate Inclusive tree, a PE can
"aggregate" multiple EVPN instances on the same P2MP LSP using "aggregate" multiple EVPN instances on the same P2MP LSP using
upstream labels. The procedures for aggregation are the same as those upstream labels. The procedures for aggregation are the same as those
described in [VPLS-MCAST], with VPLS A-D routes replaced by EVPN described in [VPLS-MCAST], with VPLS A-D routes replaced by EVPN
Inclusive Multicast ET routes. Inclusive Multicast Ethernet Tag routes.
17. Convergence 17. Convergence
This section describes failure recovery from different types of This section describes failure recovery from different types of
network failures. network failures.
17.1. Transit Link and Node Failures between PEs 17.1. Transit Link and Node Failures between PEs
The use of existing MPLS Fast-Reroute mechanisms can provide failure The use of existing MPLS Fast-Reroute mechanisms can provide failure
recovery in the order of 50ms, in the event of transit link and node recovery in the order of 50ms, in the event of transit link and node
failures in the infrastructure that connects the PEs. failures in the infrastructure that connects the PEs.
17.2. PE Failures 17.2. PE Failures
Consider a host host1 that is dual homed to PE1 and PE2. If PE1 Consider a host CE1 that is dual homed to PE1 and PE2. If PE1 fails,
fails, a remote PE, PE3, can discover this based on the failure of a remote PE, PE3, can discover this based on the failure of the BGP
the BGP session. This failure detection can be in the sub-second session. This failure detection can be in the sub-second range if
range if BFD is used to detect BGP session failure. PE3 can update BFD is used to detect BGP session failure. PE3 can update its
its forwarding state to start sending all traffic for host1 to only forwarding state to start sending all traffic for CE1 to only PE2.
PE2. It is to be noted that this failure recovery is potentially
faster than what would be possible if data plane learning were to be
used. As in that case PE3 would have to rely on re-learning of MAC
addresses via PE2.
17.3. PE to CE Network Failures 17.3. PE to CE Network Failures
When an Ethernet segment connected to an PE fails or when a Ethernet If the connectivity between the multi-homed CE and one of the PEs
Tag is decommissioned on an Ethernet segment, then the PE MUST that it is attached to, fails, the PE MUST withdraw the set of
withdraw the Ethernet A-D route(s) announced for the <ESI, Ethernet Ethernet A-D per ES routes that had been previously advertised for
Tags> that are impacted by the failure or decommissioning. In that ES. When the MAC entry on the PE ages out, the PE MUST withdraw
the MAC address from BGP. Note that to aid convergence, the Ethernet
A-D per EVI routes MAY be withdrawn before the MAC routes. This
enables the remote PEs to remove the MPLS next-hop to this particular
PE from the set of MPLS next-hops that can be used to forward traffic
to the CE.
When a Ethernet Tag is decommissioned on an Ethernet segment, then
the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for
the <ESI, Ethernet Tags> that are impacted by the decommissioning. In
addition, the PE MUST also withdraw the MAC advertisement routes that addition, the PE MUST also withdraw the MAC advertisement routes that
are impacted by the failure or decommissioning. are impacted by the decommissioning.
The Ethernet A-D routes should be used by an implementation to The Ethernet A-D per ES routes should be used by an implementation to
optimize the withdrawal of MAC advertisement routes. When an PE optimize the withdrawal of MAC advertisement routes. When a PE
receives a withdrawal of a particular Ethernet A-D route from an PE receives a withdrawal of a particular Ethernet A-D route from a PE it
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, Ethernet Tag> as in the Ethernet A-D route, from from the same ESI as in the Ethernet A-D route, from the advertising
the advertising PE, as having been withdrawn. This optimizes the PE, as having been withdrawn. This optimizes the network convergence
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, bit-1 of the most significant byte is used for In a MAC address, if the value of the 1st nibble (bits 8 thorough 5)
unicast/multicast indication and bit-2 is used for globally unique of the most significant byte of the destination MAC address (which
versus locally administered MAC address. If the value of the 2nd follows the last MPLS label) happens to be 0x4 or 0x6, then the
nibble (bits 4 thorough 8) of the most significant byte of the Ethernet frame can be misinterpreted as an IPv4 or IPv6 packet by
destination MAC address (which follows the last MPLS label) happens intermediate P nodes performing ECMP based on deep packet inspection,
to be 0x4 or 0x6, then the Ethernet frame can be misinterpreted as an thus resulting in load balancing packets belonging to the same flow
IPv4 or IPv6 packet by intermediate P nodes performing ECMP based on on different ECMP paths and subjecting them to different delays.
deep packet inspection, thus resulting in load balancing packets Therefore, packets belonging to the same flow can arrive at the
belonging to the same flow on different ECMP paths and subjecting destination out of order. This out of order delivery can happen
them to different delays. Therefore, packets belonging to the same during steady state in absence of any failures resulting in
flow can arrive at the destination out of order. This out of order significant impact to the network operation.
delivery can happen during steady state in absence of any failures
resulting in 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 control word SHOULD be used when sending EVPN encapsulated packets
over a MP2P LSP. 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 TE P2P - When sending EVPN encapsulated packets over a P2MP LSP or P2P LSP,
LSP, then the control world SHOULD NOT be used. then the control world SHOULD NOT be used.
The control word is defined as follows: The control word is defined as follows:
0 1 2 3 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 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 | |0 0 0 0| Reserved | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the above diagram the first 4 bits MUST be set to 0. The rest of In the above diagram the first 4 bits MUST be set to 0. The rest of
skipping to change at page 46, line 28 skipping to change at page 47, line 28
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.
We would like to thank Jorge Rabadan for his contribution to section We would like to thank Jorge Rabadan for his contribution to section
5 of this draft. We like to thank Thomas Morin for his review of this 5 of this draft. We like to thank Thomas Morin for his review of this
draft and his contribution of section 8.6. Last but not least, many draft and his contribution of section 8.6. Many thanks to Jakob Heitz
thanks to Jakob Heitz for his help to improve several sections of for his help to improve several sections of this draft.
this draft.
We would also like to thank Clarence Filsfils, Dennis Cai, Quaizar We would also like to thank Clarence Filsfils, Dennis Cai, Quaizar
Vohra, Kireeti Kompella, Apurva Mehta for their contributions to this Vohra, Kireeti Kompella, Apurva Mehta for their contributions to this
document. document.
Last but not least, special thanks to Giles Heron (our WG chair) for
his detailed review of this document in preparation for WG LC and
making many valuable suggestions.
20. Security Considerations 20. Security Considerations
Security considerations discussed in [RFC4761] and [RFC4762] apply to Security considerations discussed in [RFC4761] and [RFC4762] apply to
this document for MAC learning in data-plane over an Attachment this document for MAC learning in data-plane over an Attachment
Circuit (AC) and for flooding of unknown unicast and ARP messages Circuit (AC) and for flooding of unknown unicast and ARP messages
over the MPLS/IP core. Security considerations discussed in [RFC4364] over the MPLS/IP core. Security considerations discussed in [RFC4364]
apply to this document for MAC learning in control-plane over the apply to this document for MAC learning in control-plane over the
MPLS/IP core. This section describes additional considerations. MPLS/IP core. This section describes additional considerations.
As mentioned in [RFC4761], there are two aspects to achieving data As mentioned in [RFC4761], there are two aspects to achieving data
skipping to change at page 48, line 42 skipping to change at page 49, line 46
RFC 4271, January 2006 RFC 4271, January 2006
[RFC4760] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC [RFC4760] T. Bates et. al., "Multiprotocol Extensions for BGP-4", RFC
4760, January 2007 4760, January 2007
23.2 Informative References 23.2 Informative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[EVPN-REQ] A. Sajassi, R. Aggarwal et. al., "Requirements for [RFC7209] A. Sajassi, R. Aggarwal et. al., "Requirements for Ethernet
Ethernet VPN", draft-ietf-l2vpn-evpn-req-04.txt, July VPN", draft-ietf-l2vpn-evpn-req-04.txt, July 2013.
2013.
[VPLS-MCAST] "Multicast in VPLS". R. Aggarwal et.al., draft-ietf- [RFC7117] "Multicast in VPLS". R. Aggarwal et.al., draft-ietf-l2vpn-
l2vpn-vpls-mcast-14.txt, July 2013. vpls-mcast-14.txt, July 2013.
[RT-CONSTRAIN] P. Marques et. al., "Constrained Route Distribution [RFC4684] P. Marques et. al., "Constrained Route Distribution for
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.
24. Author's Address 24. Author's Address
Ali Sajassi Ali Sajassi
Cisco Cisco
 End of changes. 132 change blocks. 
396 lines changed or deleted 421 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/