rfc7432v2.txt   rfc7432.txt 
skipping to change at page 1, line 17 skipping to change at page 1, line 17
N. Bitar N. Bitar
Verizon Verizon
A. Isaac A. Isaac
Bloomberg Bloomberg
J. Uttaro J. Uttaro
AT&T AT&T
J. Drake J. Drake
Juniper Networks Juniper Networks
W. Henderickx W. Henderickx
Alcatel-Lucent Alcatel-Lucent
January 2015 February 2015
BGP MPLS-Based Ethernet VPN BGP MPLS-Based Ethernet VPN
Abstract Abstract
This document describes procedures for BGP MPLS-based Ethernet VPNs This document describes procedures for BGP MPLS-based Ethernet VPNs
(EVPN). The procedures described here meet the requirements (EVPN). The procedures described here meet the requirements
specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)". specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".
Status of This Memo Status of This Memo
skipping to change at page 2, line 33 skipping to change at page 2, line 33
2. Specification of Requirements ...................................4 2. Specification of Requirements ...................................4
3. Terminology .....................................................4 3. Terminology .....................................................4
4. BGP MPLS-Based EVPN Overview ....................................6 4. BGP MPLS-Based EVPN Overview ....................................6
5. Ethernet Segment ................................................7 5. Ethernet Segment ................................................7
6. Ethernet Tag ID ................................................10 6. Ethernet Tag ID ................................................10
6.1. VLAN-Based Service Interface ..............................11 6.1. VLAN-Based Service Interface ..............................11
6.2. VLAN Bundle Service Interface .............................11 6.2. VLAN Bundle Service Interface .............................11
6.2.1. Port-Based Service Interface .......................11 6.2.1. Port-Based Service Interface .......................11
6.3. VLAN-Aware Bundle Service Interface .......................11 6.3. VLAN-Aware Bundle Service Interface .......................11
6.3.1. Port-Based VLAN-Aware Service Interface ............12 6.3.1. Port-Based VLAN-Aware Service Interface ............12
7. BGP EVPN Routes ................................................12 7. BGP EVPN Routes ................................................13
7.1. Ethernet Auto-discovery Route .............................13 7.1. Ethernet Auto-discovery Route .............................14
7.2. MAC/IP Advertisement Route ................................14 7.2. MAC/IP Advertisement Route ................................14
7.3. Inclusive Multicast Ethernet Tag Route ....................15 7.3. Inclusive Multicast Ethernet Tag Route ....................15
7.4. Ethernet Segment Route ....................................15 7.4. Ethernet Segment Route ....................................16
7.5. ESI Label Extended Community ..............................16 7.5. ESI Label Extended Community ..............................16
7.6. ES-Import Route Target ....................................16 7.6. ES-Import Route Target ....................................17
7.7. MAC Mobility Extended Community ...........................17 7.7. MAC Mobility Extended Community ...........................18
7.8. Default Gateway Extended Community ........................17 7.8. Default Gateway Extended Community ........................18
7.9. Route Distinguisher Assignment per EVI ....................18 7.9. Route Distinguisher Assignment per EVI ....................18
7.10. Route Targets ............................................18 7.10. Route Targets ............................................19
7.10.1. Auto-derivation from the Ethernet Tag ID ..........18 7.10.1. Auto-derivation from the Ethernet Tag ID ..........19
8. Multihoming Functions ..........................................18 8. Multihoming Functions ..........................................19
8.1. Multihomed Ethernet Segment Auto-discovery ................18 8.1. Multihomed Ethernet Segment Auto-discovery ................19
8.1.1. Constructing the Ethernet Segment Route ............19 8.1.1. Constructing the Ethernet Segment Route ............19
8.2. Fast Convergence ..........................................19 8.2. Fast Convergence ..........................................20
8.2.1. Constructing Ethernet A-D per Ethernet 8.2.1. Constructing Ethernet A-D per Ethernet
Segment Route ......................................20 Segment Route ......................................21
8.2.1.1. Ethernet A-D Route Targets ................21 8.2.1.1. Ethernet A-D Route Targets ................21
8.3. Split Horizon .............................................21 8.3. Split Horizon .............................................22
8.3.1. ESI Label Assignment ...............................21 8.3.1. ESI Label Assignment ...............................22
8.3.1.1. Ingress Replication .......................22 8.3.1.1. Ingress Replication .......................22
8.3.1.2. P2MP MPLS LSPs ............................23 8.3.1.2. P2MP MPLS LSPs ............................24
8.4. Aliasing and Backup Path ..................................24 8.4. Aliasing and Backup Path ..................................25
8.4.1. Constructing Ethernet A-D per EVPN Instance Route ..25 8.4.1. Constructing Ethernet A-D per EVPN Instance Route ..26
8.5. Designated Forwarder Election .............................26 8.5. Designated Forwarder Election .............................27
8.6. Interoperability with Single-Homing PEs ...................28 8.6. Interoperability with Single-Homing PEs ...................29
9. Determining Reachability to Unicast MAC Addresses ..............28 9. Determining Reachability to Unicast MAC Addresses ..............30
9.1. Local Learning ............................................28 9.1. Local Learning ............................................30
9.2. Remote Learning ...........................................29 9.2. Remote Learning ...........................................30
9.2.1. Constructing MAC/IP Address Advertisement ..........29 9.2.1. Constructing MAC/IP Address Advertisement ..........31
9.2.2. Route Resolution ...................................31 9.2.2. Route Resolution ...................................32
10. ARP and ND ....................................................32 10. ARP and ND ....................................................33
10.1. Default Gateway ..........................................33 10.1. Default Gateway ..........................................34
11. Handling of Multi-destination Traffic .........................35 11. Handling of Multi-destination Traffic .........................36
11.1. Constructing Inclusive Multicast Ethernet Tag Route ......35 11.1. Constructing Inclusive Multicast Ethernet Tag Route ......36
11.2. P-Tunnel Identification ..................................35 11.2. P-Tunnel Identification ..................................37
12. Processing of Unknown Unicast Packets .........................36 12. Processing of Unknown Unicast Packets .........................38
12.1. Ingress Replication ......................................37 12.1. Ingress Replication ......................................38
12.2. P2MP MPLS LSPs ...........................................37 12.2. P2MP MPLS LSPs ...........................................39
13. Forwarding Unicast Packets ....................................38 13. Forwarding Unicast Packets ....................................39
13.1. Forwarding Packets Received from a CE ....................38 13.1. Forwarding Packets Received from a CE ....................39
13.2. Forwarding Packets Received from a Remote PE .............39 13.2. Forwarding Packets Received from a Remote PE .............41
13.2.1. Unknown Unicast Forwarding ........................39 13.2.1. Unknown Unicast Forwarding ........................41
13.2.2. Known Unicast Forwarding ..........................40 13.2.2. Known Unicast Forwarding ..........................41
14. Load Balancing of Unicast Packets .............................40 14. Load Balancing of Unicast Packets .............................41
14.1. Load Balancing of Traffic from a PE to Remote CEs ........40 14.1. Load Balancing of Traffic from a PE to Remote CEs ........41
14.1.1. Single-Active Redundancy Mode .....................40 14.1.1. Single-Active Redundancy Mode .....................42
14.1.2. All-Active Redundancy Mode ........................41 14.1.2. All-Active Redundancy Mode ........................42
14.2. Load Balancing of Traffic between a PE and a Local CE ....42 14.2. Load Balancing of Traffic between a PE and a Local CE ....44
14.2.1. Data-Plane Learning ...............................43 14.2.1. Data-Plane Learning ...............................44
14.2.2. Control-Plane Learning ............................43 14.2.2. Control-Plane Learning ............................44
15. MAC Mobility ..................................................43 15. MAC Mobility ..................................................45
15.1. MAC Duplication Issue ....................................45 15.1. MAC Duplication Issue ....................................47
15.2. Sticky MAC Addresses .....................................45 15.2. Sticky MAC Addresses .....................................47
16. Multicast and Broadcast .......................................46 16. Multicast and Broadcast .......................................47
16.1. Ingress Replication ......................................46 16.1. Ingress Replication ......................................47
16.2. P2MP LSPs ................................................46 16.2. P2MP LSPs ................................................48
16.2.1. Inclusive Trees ...................................46 16.2.1. Inclusive Trees ...................................48
17. Convergence ...................................................47 17. Convergence ...................................................49
17.1. Transit Link and Node Failures between PEs ...............47 17.1. Transit Link and Node Failures between PEs ...............49
17.2. PE Failures ..............................................47 17.2. PE Failures ..............................................49
17.3. PE-to-CE Network Failures ................................47 17.3. PE-to-CE Network Failures ................................49
18. Frame Ordering ................................................48 18. Frame Ordering ................................................50
19. Security Considerations .......................................48 19. Security Considerations .......................................50
20. IANA Considerations ...........................................50 20. IANA Considerations ...........................................52
21. References ....................................................50 21. References ....................................................52
21.1. Normative References .....................................50 21.1. Normative References .....................................52
21.2. Informative References ...................................51 21.2. Informative References ...................................53
Acknowledgements ..................................................52 Acknowledgements ..................................................54
Contributors ......................................................53 Contributors ......................................................55
Authors' Addresses ................................................53 Authors' Addresses ................................................55
1. Introduction 1. Introduction
Virtual Private LAN Service (VPLS), as defined in [RFC4664], Virtual Private LAN Service (VPLS), as defined in [RFC4664],
[RFC4761], and [RFC4762], is a proven and widely deployed technology. [RFC4761], and [RFC4762], is a proven and widely deployed technology.
However, the existing solution has a number of limitations when it However, the existing solution has a number of limitations when it
comes to multihoming and redundancy, multicast optimization, comes to multihoming and redundancy, multicast optimization,
provisioning simplicity, flow-based load balancing, and multipathing; provisioning simplicity, flow-based load balancing, and multipathing;
these limitations are important considerations for Data Center (DC) these limitations are important considerations for Data Center (DC)
deployments. [RFC7209] describes the motivation for a new solution deployments. [RFC7209] describes the motivation for a new solution
skipping to change at page 4, line 47 skipping to change at page 4, line 47
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Terminology 3. Terminology
Broadcast Domain: In a bridged network, the broadcast domain Broadcast Domain: In a bridged network, the broadcast domain
corresponds to a Virtual LAN (VLAN), where a VLAN is typically corresponds to a Virtual LAN (VLAN), where a VLAN is typically
represented by a single VLAN ID (VID) but can be represented represented by a single VLAN ID (VID) but can be represented
by several VIDs where Shared VLAN Learning (SVL) is used by several VIDs where Shared VLAN Learning (SVL) is used
per [802.1Q]. per [802.1Q].
Bridge Domain: An instantiation of a broadcast domain on a Bridge Table: An instantiation of a broadcast domain on a MAC-VRF.
bridge node.
CE: Customer Edge device, e.g., a host, router, or switch. CE: Customer Edge device, e.g., a host, router, or switch.
EVI: An EVPN instance spanning the Provider Edge (PE) devices EVI: An EVPN instance spanning the Provider Edge (PE) devices
participating in that EVPN. participating in that EVPN.
MAC-VRF: A Virtual Routing and Forwarding table for Media Access MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE for an EVI. Control (MAC) addresses on a PE.
Ethernet Segment (ES): When a customer site (device or network) is Ethernet Segment (ES): When a customer site (device or network) is
connected to one or more PEs via a set of Ethernet links, then connected to one or more PEs via a set of Ethernet links, then
that set of links is referred to as an 'Ethernet segment'. that set of links is referred to as an 'Ethernet segment'.
Ethernet Segment Identifier (ESI): A unique non-zero identifier that Ethernet Segment Identifier (ESI): A unique non-zero identifier that
identifies an Ethernet segment is called an 'Ethernet Segment identifies an Ethernet segment is called an 'Ethernet Segment
Identifier'. Identifier'.
Ethernet Tag: An Ethernet tag identifies a particular broadcast Ethernet Tag: An Ethernet tag identifies a particular broadcast
skipping to change at page 7, line 7 skipping to change at page 7, line 7
(ARP), management plane, or other protocols. (ARP), management plane, or other protocols.
It is a local decision as to whether the Layer 2 forwarding table on It is a local decision as to whether the Layer 2 forwarding table on
a PE is populated with all the MAC destination addresses known to the a PE is populated with all the MAC destination addresses known to the
control plane, or whether the PE implements a cache-based scheme. control plane, or whether the PE implements a cache-based scheme.
For instance, the MAC forwarding table may be populated only with the For instance, the MAC forwarding table may be populated only with the
MAC destinations of the active flows transiting a specific PE. MAC destinations of the active flows transiting a specific PE.
The policy attributes of EVPN are very similar to those of IP-VPN. The policy attributes of EVPN are very similar to those of IP-VPN.
An EVPN instance requires a Route Distinguisher (RD) that is unique An EVPN instance requires a Route Distinguisher (RD) that is unique
per PE and one or more globally unique Route Targets (RTs). A CE per MAC-VRF and one or more globally unique Route Targets (RTs). A
attaches to a MAC-VRF on a PE, on an Ethernet interface that may be CE attaches to a MAC-VRF on a PE, on an Ethernet interface that may
configured for one or more Ethernet tags, e.g., VLAN IDs. Some be 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
As indicated in [RFC7209], each Ethernet segment needs a unique As indicated in [RFC7209], each Ethernet segment needs a unique
identifier in an EVPN. This section defines how such identifiers are identifier in an EVPN. This section defines how such identifiers are
skipping to change at page 11, line 15 skipping to change at page 11, line 15
The following Ethernet Tag ID value is reserved: The following Ethernet Tag ID value is reserved:
- Ethernet Tag ID {0xFFFFFFFF} is known as MAX-ET. - Ethernet Tag ID {0xFFFFFFFF} is known as MAX-ET.
6.1. VLAN-Based Service Interface 6.1. VLAN-Based Service Interface
With this service interface, an EVPN instance consists of only a With this service interface, an EVPN instance consists of only a
single broadcast domain (e.g., a single VLAN). Therefore, there is a single broadcast domain (e.g., a single VLAN). Therefore, there is a
one-to-one mapping between a VID on this interface and a MAC-VRF. one-to-one mapping between a VID on this interface and a MAC-VRF.
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 table corresponding to that VLAN. If the VLAN is represented
by multiple VIDs (e.g., a different VID per Ethernet segment per PE), by multiple VIDs (e.g., a different VID per Ethernet segment per PE),
then each PE needs to perform VID translation for frames destined to then each PE needs to perform VID translation for frames destined to
its Ethernet segment(s). In such scenarios, the Ethernet frames its Ethernet segment(s). In such scenarios, the Ethernet frames
transported over an MPLS/IP network SHOULD remain tagged with the transported over an MPLS/IP network SHOULD remain tagged with the
originating VID, and a VID translation MUST be supported in the data originating VID, and a VID translation MUST be supported in the data
path and MUST be performed on the disposition PE. The Ethernet Tag path and MUST be performed on the disposition PE. The Ethernet Tag
ID in all EVPN routes MUST be set to 0. ID in all EVPN routes MUST be set to 0.
6.2. VLAN Bundle Service Interface 6.2. VLAN Bundle Service Interface
With this service interface, an EVPN instance corresponds to several With this service interface, an EVPN instance corresponds to multiple
broadcast domains (e.g., several VLANs); however, only a single broadcast domains (e.g., multiple VLANs); however, only a single
bridge domain is maintained per MAC-VRF, which means multiple VLANs bridge table is maintained per MAC-VRF, which means multiple VLANs
share the same bridge domain. This implies that MAC addresses MUST share the same bridge table. This implies that MAC addresses MUST be
be unique across different VLANs for this service to work. In other unique across all VLANs for that EVI in order for this service to
words, there is a many-to-one mapping between VLANs and a MAC-VRF, work. In other words, there is a many-to-one mapping between VLANs
and the MAC-VRF consists of a single bridge domain. Furthermore, a and a MAC-VRF, and the MAC-VRF consists of a single bridge table.
single VLAN must be represented by a single VID -- e.g., no VID Furthermore, a single VLAN must be represented by a single VID --
translation is allowed for this service interface type. The MPLS e.g., no VID translation is allowed for this service interface type.
encapsulated frames MUST remain tagged with the originating VID. Tag The MPLS-encapsulated frames MUST remain tagged with the originating
translation is NOT permitted. The Ethernet Tag ID in all EVPN routes VID. Tag translation is NOT permitted. The Ethernet Tag ID in all
MUST be set to 0. EVPN routes MUST be set to 0.
6.2.1. Port-Based Service Interface 6.2.1. Port-Based Service Interface
This service interface is a special case of the VLAN bundle service This service interface is a special case of the VLAN bundle service
interface, where all of the VLANs on the port are part of the same interface, where all of the VLANs on the port are part of the same
service and map to the same bundle. The procedures are identical to service and map to the same bundle. The procedures are identical to
those described in Section 6.2. those described in Section 6.2.
6.3. VLAN-Aware Bundle Service Interface 6.3. VLAN-Aware Bundle Service Interface
With this service interface, an EVPN instance consists of several With this service interface, an EVPN instance consists of multiple
broadcast domains (e.g., several VLANs) with each VLAN having its own broadcast domains (e.g., multiple VLANs) with each VLAN having its
bridge domain -- i.e., multiple bridge domains (one per VLAN) are own bridge table -- i.e., multiple bridge tables (one per VLAN) are
maintained by a single MAC-VRF corresponding to the EVPN instance. maintained by a single MAC-VRF corresponding to the EVPN instance.
Broadcast, unknown unicast, or multicast (BUM) traffic is sent only
to the CEs in a given broadcast domain; however, the broadcast
domains within an EVI either MAY each have their own P-Tunnel or MAY
share P-Tunnels -- e.g., all of the broadcast domains in an EVI MAY
share a single P-Tunnel.
In the case where a single VLAN is represented by a single VID and
thus no VID translation is required, an MPLS-encapsulated packet MUST
carry that VID. The Ethernet Tag ID in all EVPN routes MUST be set
to that VID. The advertising PE MAY advertise the MPLS Label1 in the
MAC/IP Advertisement route representing ONLY the EVI or representing
both the Ethernet Tag ID and the EVI. This decision is only a local
matter by the advertising PE (which is also the disposition PE) and
doesn't affect any other PEs.
In the case where a single VLAN is represented by different VIDs on In the case where a single VLAN is represented by different VIDs on
different CEs and thus VID translation is required, a normalized different CEs and thus VID translation is required, a normalized
Ethernet Tag ID (VID) MUST be carried in the MPLS-encapsulated Ethernet Tag ID (VID) MUST be carried in the EVPN BGP routes.
frames, and an Ethernet Tag ID translation function MUST be supported Furthermore, the advertising PE advertises the MPLS Label1 in the
in the data path. This translation MUST be performed in the data MAC/IP Advertisement route representing both the Ethernet Tag ID and
path on both the imposition and disposition PEs (translating to a the EVI, so that upon receiving an MPLS-encapsulated packet, it can
normalized Ethernet Tag ID on the imposition PE and translating to a identify the corresponding bridge table from the MPLS EVPN label and
local Ethernet Tag ID on the disposition PE). The Ethernet Tag ID in perform Ethernet Tag ID translation ONLY at the disposition PE --
all EVPN routes MUST be set to the normalized value assigned by the i.e., the Ethernet frames transported over the MPLS/IP network MUST
remain tagged with the originating VID, and VID translation is
performed on the disposition PE. The Ethernet Tag ID in all EVPN
routes MUST be set to the normalized Ethernet Tag ID assigned by the
EVPN provider. EVPN provider.
6.3.1. Port-Based VLAN-Aware Service Interface 6.3.1. Port-Based VLAN-Aware Service Interface
This service interface is a special case of the VLAN-aware bundle This service interface is a special case of the VLAN-aware bundle
service interface, where all of the VLANs on the port are part of the service interface, where all of the VLANs on the port are part of the
same service and are mapped to a single bundle but without any VID same service and are mapped to a single bundle but without any VID
translation. The procedures are a subset of those described in translation. The procedures are a subset of those described in
Section 6.3. Section 6.3.
skipping to change at page 14, line 35 skipping to change at page 15, line 10
| 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 fields are considered to be part of the prefix in the NLRI. Address fields are considered to be part of the prefix in the NLRI.
The Ethernet Segment Identifier, MPLS Label1, and MPLS Label2 fields The Ethernet Segment Identifier, MPLS Label1, and MPLS Label2 fields
are to be treated as route attributes as opposed to being part of the are to be treated as route attributes as opposed to being part of the
"route". The IP address length is in bits. "route". Both the IP and MAC address lengths are in bits.
For procedures and usage of this route, please see Sections 9 For procedures and usage of this route, please see Sections 9
("Determining Reachability to Unicast MAC Addresses") and 14 ("Load ("Determining Reachability to Unicast MAC Addresses") and 14 ("Load
Balancing of Unicast Packets"). 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 16, line 36 skipping to change at page 17, line 10
"Single-Active" bit. A value of 0 means that the multihomed site "Single-Active" bit. A value of 0 means that the multihomed site
is operating in All-Active redundancy mode, and a value of 1 means is operating in All-Active redundancy mode, and a value of 1 means
that the multihomed site is operating in Single-Active redundancy that the multihomed site is operating in Single-Active redundancy
mode. mode.
7.6. ES-Import Route Target 7.6. ES-Import Route Target
This is a new transitive Route Target extended community carried with This is a new transitive Route Target extended community carried with
the Ethernet Segment route. When used, it enables all the PEs the Ethernet Segment route. When used, it enables all the PEs
connected to the same multihomed site to import the Ethernet Segment connected to the same multihomed site to import the Ethernet Segment
routes. The value is derived automatically from the ESI by encoding routes. The value is derived automatically for the ESI Types 1, 2,
the high-order 6-octet portion of the 9-octet ESI Value in the and 3, by encoding the high-order 6-octet portion of the 9-octet ESI
ES-Import Route Target. The high-order 6-octet portion of the ESI Value, which corresponds to a MAC address, in the ES-Import Route
incorporates the MAC address of the ESI (for Types 1, 2, and 3); when Target. The format of this Extended Community is as follows:
encoded in this RT and used in the RT Constraint feature, it enables
proper route-target filtering. The format of this Extended Community
is as follows:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 the high-order octet (Type field) to community to allow the value of the high-order octet (Type field) to
skipping to change at page 17, line 48 skipping to change at page 18, line 36
used to ensure that PEs retain the correct MAC/IP Advertisement route used to ensure that PEs retain the correct MAC/IP Advertisement route
when multiple updates occur for the same MAC address. 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 Section 3.3 of [RFC4360]). It is a transitive community, Type (see Section 3.3 of [RFC4360]). It is a transitive community,
which means that the first octet is 0x03. The value of the second which means that the first octet is 0x03. The value of the second
octet (Sub-Type) is 0x0d (Default Gateway) as assigned by IANA. The octet (Sub-Type) is 0x0d (Default Gateway) as assigned by IANA. The
Value field of this community is reserved (set to 0 by the senders, Value field of this community is reserved (set to 0 by the senders,
ignored by the receivers). ignored by the receivers). For procedures and usage of this
attribute, please see Section 10.1 ("Default Gateway").
7.9. Route Distinguisher Assignment per EVI 7.9. Route Distinguisher Assignment per MAC-VRF
The Route Distinguisher (RD) MUST be set to the RD of the EVI that is The Route Distinguisher (RD) MUST be set to the RD of the MAC-VRF
advertising the NLRI. An RD MUST be assigned for a given EVI on a that is advertising the NLRI. An RD MUST be assigned for a given
PE. This RD MUST be unique across all EVIs on a PE. It is MAC-VRF on a PE. This RD MUST be unique across all MAC-VRFs on a PE.
RECOMMENDED to use the Type 1 RD [RFC4364]. The value field It is RECOMMENDED to use the Type 1 RD [RFC4364]. The value field
comprises an IP address of the PE (typically, the loopback address) comprises an IP address of the PE (typically, the loopback address)
followed by a number unique to the PE. This number may be generated 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 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 may be the 12-bit VLAN ID, with the remaining high-order 4 bits set
to 0. to 0.
7.10. Route Targets 7.10. Route Targets
The EVPN route MAY carry one or more Route Target (RT) attributes. The EVPN route MAY carry one or more Route Target (RT) attributes.
RTs may be configured (as in IP VPNs) or may be derived RTs may be configured (as in IP VPNs) or may be derived
automatically. automatically.
If a PE uses RT Constraint, the PE advertises all such RTs using RT If a PE uses RT Constraint, the PE advertises all such RTs using RT
Constraints per [RFC4684]. The use of RT Constraints allows each Constraints per [RFC4684]. The use of RT Constraints allows each
Ethernet A-D route to reach only those PEs that are configured to EVPN route to reach only those PEs that are configured to import at
import at least one RT from the set of RTs carried in the EVPN route. least one RT from the set of RTs carried in the EVPN route.
7.10.1. Auto-derivation from the Ethernet Tag ID 7.10.1. Auto-derivation from the Ethernet Tag ID
For the "Unique VLAN EVPN" scenario, it is highly desirable to 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 auto-derive the RT from the Ethernet Tag ID (VLAN ID) for that EVPN
instance. The procedure for performing such auto-derivation is as instance. The procedure for performing such auto-derivation is as
follows: follows:
+ The Global Administrator field of the RT MUST be set to the + The Global Administrator field of the RT MUST be set to the
Autonomous System (AS) number with which the PE is associated. Autonomous System (AS) number with which the PE is associated.
+ The 12-bit VLAN ID MUST be encoded in the lowest 12 bits of the + The 12-bit VLAN ID MUST be encoded in the lowest 12 bits of the
Local Administrator field. Local Administrator field, with the remaining bits set to zero.
8. Multihoming Functions 8. Multihoming Functions
This section discusses the functions, procedures, and associated BGP This section discusses the functions, procedures, and associated BGP
routes used to support multihoming in EVPN. This covers both routes used to support multihoming in EVPN. This covers both
multihomed device (MHD) and multihomed network (MHN) scenarios. multihomed device (MHD) and multihomed network (MHN) scenarios.
8.1. Multihomed Ethernet Segment Auto-discovery 8.1. Multihomed 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 The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The
value field comprises an IP address of the PE (typically, the value field comprises an IP address of the PE (typically, the
loopback address) followed by zeroes. loopback address) followed by a number unique to the PE.
The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet
value described in Section 5. value described in Section 5.
The BGP advertisement that advertises the Ethernet Segment route MUST The BGP advertisement that advertises the Ethernet Segment route MUST
also carry an ES-Import route target, as defined in Section 7.6. also carry an ES-Import Route Target, as defined in Section 7.6.
The Ethernet Segment route filtering MUST be done such that the The Ethernet Segment route filtering MUST be done such that the
Ethernet Segment route is imported only by the PEs that are Ethernet Segment route is imported only by the PEs that are
multihomed to the same Ethernet segment. To that end, each PE that multihomed to the same Ethernet segment. To that end, each PE that
is connected to a particular Ethernet segment constructs an import is connected to a particular Ethernet segment constructs an import
filtering rule to import a route that carries the ES-Import extended filtering rule to import a route that carries the ES-Import Route
community, constructed from the ESI. Target, constructed from the ESI.
8.2. Fast Convergence 8.2. Fast Convergence
In EVPN, MAC address reachability is learned via the BGP control In EVPN, MAC address reachability is learned via the BGP control
plane over the MPLS network. As such, in the absence of any fast plane over the MPLS network. As such, in the absence of any fast
protection mechanism, the network convergence time is a function of protection mechanism, the network convergence time is a function of
the number of MAC/IP Advertisement routes that must be withdrawn by the number of MAC/IP Advertisement routes that must be withdrawn by
the PE encountering a failure. For highly scaled environments, this the PE encountering a failure. For highly scaled environments, this
scheme yields slow convergence. scheme yields slow convergence.
skipping to change at page 20, line 6 skipping to change at page 20, line 42
of RTs. Each Ethernet A-D per ES route is differentiated from the of RTs. Each Ethernet A-D per ES route is differentiated from the
other routes in the set by a different Route Distinguisher (RD). other routes in the set by a different Route Distinguisher (RD).
Upon a failure in connectivity to the attached segment, the PE Upon a failure in connectivity to the attached segment, the PE
withdraws the corresponding set of Ethernet A-D per ES routes. This withdraws the corresponding set of Ethernet A-D per ES routes. This
triggers all PEs that receive the withdrawal to update their next-hop triggers all PEs that receive the withdrawal to update their next-hop
adjacencies for all MAC addresses associated with the Ethernet adjacencies for all MAC addresses associated with the Ethernet
segment in question. If no other PE had advertised an Ethernet A-D segment in question. If no other PE had advertised an Ethernet A-D
route for the same segment, then the PE that received the withdrawal route for the same segment, then the PE that received the withdrawal
simply invalidates the MAC entries for that segment. Otherwise, the simply invalidates the MAC entries for that segment. Otherwise, the
PE updates the next-hop adjacencies to point to the backup PE(s). PE updates its next-hop adjacencies accordingly.
8.2.1. Constructing Ethernet A-D per Ethernet Segment Route 8.2.1. Constructing Ethernet A-D per Ethernet Segment Route
This section describes the procedures used to construct the Ethernet This section describes the procedures used to construct the Ethernet
A-D per ES route, which is used for fast convergence (as discussed A-D per ES route, which is used for fast convergence (as discussed
above) and for advertising the ESI label used for split-horizon above) and for advertising the ESI label used for split-horizon
filtering (as discussed in Section 8.3). Support of this route is filtering (as discussed in Section 8.3). Support of this route is
REQUIRED. REQUIRED.
The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The The Route Distinguisher (RD) MUST be a Type 1 RD [RFC4364]. The
skipping to change at page 24, line 51 skipping to change at page 25, line 45
Note that the Ethernet A-D per EVI route may be received by a remote Note that the Ethernet A-D per EVI route may be received by a remote
PE before it receives the set of Ethernet A-D per ES routes. PE before it receives the set of Ethernet A-D per ES routes.
Therefore, in order to handle corner cases and race conditions, the Therefore, in order to handle corner cases and race conditions, the
Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by Ethernet A-D per EVI route MUST NOT be used for traffic forwarding by
a remote PE until it also receives the associated set of Ethernet A-D a remote PE until it also receives the associated set of Ethernet A-D
per ES routes. per ES routes.
The backup path is a closely related function, but it is used in The backup path is a closely related function, but it is used in
Single-Active redundancy mode. In this case, a PE also advertises Single-Active redundancy mode. In this case, a PE also advertises
that it has reachability to a give EVI/ES using the same combination that it has reachability to a given EVI/ES using the same combination
of Ethernet A-D per EVI route and Ethernet A-D per ES route as of Ethernet A-D per EVI route and Ethernet A-D per ES route as
discussed above, but with the "Single-Active" bit in the flags of the discussed above, but with the "Single-Active" bit in the flags of the
ESI Label extended community set to 1. A remote PE that receives a ESI Label extended community set to 1. A remote PE that receives a
MAC/IP Advertisement route with a non-reserved ESI SHOULD consider MAC/IP Advertisement route with a non-reserved ESI SHOULD consider
the advertised MAC address to be reachable via any PE that has the advertised MAC address to be reachable via any PE that has
advertised this combination of Ethernet A-D routes, and it SHOULD advertised this combination of Ethernet A-D routes, and it SHOULD
install a backup path for that MAC address. install a backup path for that MAC address.
8.4.1. Constructing Ethernet A-D per EVPN Instance Route 8.4.1. Constructing Ethernet A-D per EVPN Instance Route
This section describes the procedures used to construct the Ethernet This section describes the procedures used to construct the Ethernet
A-D per EVPN instance (EVI) route, which is used for aliasing (as A-D per EVPN instance (EVI) route, which is used for aliasing (as
discussed above). Support of this route is OPTIONAL. discussed above). Support of this route is OPTIONAL.
The Route Distinguisher (RD) MUST be set to the RD of the EVI that is The Route Distinguisher (RD) MUST be set per Section 7.9.
advertising the NLRI, per Section 7.9.
The Ethernet Segment Identifier MUST be a 10-octet entity as The Ethernet Segment Identifier MUST be a 10-octet entity as
described in Section 5 ("Ethernet Segment"). The Ethernet A-D route described in Section 5 ("Ethernet Segment"). The Ethernet A-D route
is not needed when the Segment Identifier is set to 0. is not needed when the Segment 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 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 20 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:
+ One Ethernet A-D route for a given <ESI, Ethernet Tag ID> tuple per + One Ethernet A-D route per <ESI, Ethernet Tag ID> tuple per MAC-
EVI. This is applicable when the PE uses MPLS-based disposition. VRF. This is applicable when the PE uses MPLS-based disposition
with VID translation or may be applicable when the PE uses MAC-
based disposition with VID translation.
+ One Ethernet A-D route per <ESI, EVI> (where the Ethernet Tag ID is + One Ethernet A-D route for each <ESI> per MAC-VRF (where the
set to 0). This is applicable when the PE uses MAC-based Ethernet Tag ID is set to 0). This is applicable when the PE uses
disposition, or when the PE uses MPLS-based disposition when no MAC-based disposition or MPLS-based disposition without VID
VLAN translation is required. translation.
The usage of the MPLS label is described in Section 14 ("Load The usage of the MPLS label is described in Section 14 ("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.
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, per Section 7.10. attributes, per Section 7.10.
skipping to change at page 26, line 22 skipping to change at page 27, line 22
- Sending multicast and broadcast traffic, on a given Ethernet tag on - Sending multicast and broadcast traffic, on a given Ethernet tag on
a particular Ethernet segment, to the CE. a particular Ethernet segment, to the CE.
- Flooding unknown unicast traffic (i.e., traffic for which a PE does - Flooding unknown unicast traffic (i.e., traffic for which a PE does
not know the destination MAC address), on a given Ethernet tag on a not know the destination MAC address), on a given Ethernet tag on a
particular Ethernet segment to the CE, if the environment requires particular Ethernet segment to the CE, if the environment requires
flooding of unknown unicast traffic. flooding of 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 <ES, VLAN> or <ES, VLAN bundle> for multicast,
unicast traffic, is the default behavior in this specification. broadcast, and unknown 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 a 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 multihomed to more than one PE in an EVPN If a bridged network is multihomed 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 bridged 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 a LAG, then If a bridged network does not connect to the PEs using a LAG, then
only one of the links between the switched bridged network and the only one of the links between the bridged network and the PEs must be
PEs must be the active link for a given EVPN instance. In this case, the active link for a given <ES, VLAN> or <ES, VLAN bundle>. In this
the set of Ethernet A-D per ES routes advertised by each PE MUST have case, the set of Ethernet A-D per ES routes advertised by each PE
the "Single-Active" bit in the flags of the ESI Label extended MUST have the "Single-Active" bit in the flags of the ESI Label
community set to 1. extended community set to 1.
The default procedure for DF election at the granularity of <ESI, The default procedure for DF election at the granularity of <ES,
EVI> is referred to as "service carving". With service carving, it VLAN> for VLAN-based service or <ES, VLAN bundle> for VLAN-(aware)
is possible to elect multiple DFs per Ethernet segment (one per EVI) bundle service is referred to as "service carving". With service
in order to perform load balancing of multi-destination traffic carving, it is possible to elect multiple DFs per Ethernet segment
destined to a given segment. The load-balancing procedures carve up (one per VLAN or VLAN bundle) in order to perform load balancing of
the EVI space among the PE nodes evenly, in such a way that every PE multi-destination traffic destined to a given segment. The load-
is the DF for a disjoint set of EVIs. The procedure for service balancing procedures carve up the VLAN space per ES among the PE
nodes evenly, in such a way that every PE is the DF for a disjoint
set of VLANs or VLAN bundles for that ES. The procedure for service
carving is as follows: carving is as follows:
1. When a PE discovers the ESI of the attached Ethernet segment, it 1. When a PE discovers the ESI of the attached Ethernet segment, it
advertises an Ethernet Segment route with the associated ES-Import advertises an Ethernet Segment route with the associated ES-Import
extended community attribute. extended community attribute.
2. The PE then starts a timer (default value = 3 seconds) to allow 2. The PE then starts a timer (default value = 3 seconds) to allow
the reception of Ethernet Segment routes from other PE nodes the reception of Ethernet Segment routes from other PE nodes
connected to the same Ethernet segment. This timer value should connected to the same Ethernet segment. This timer value should
be the same across all PEs connected to the same Ethernet segment. be the same across all PEs connected to the same Ethernet segment.
3. When the timer expires, each PE builds an ordered list of the IP 3. When the timer expires, each PE builds an ordered list of the IP
addresses of all the PE nodes connected to the Ethernet segment addresses of all the PE nodes connected to the Ethernet segment
(including itself), in increasing numeric value. Each IP address (including itself), in increasing numeric value. Each IP address
in this list is extracted from the "Originator Router's IP in this list is extracted from the "Originating Router's IP
address" field of the advertised Ethernet Segment route. Every PE address" field of the advertised Ethernet Segment route. Every PE
is then given an ordinal indicating its position in the ordered is then given an ordinal indicating its position in the ordered
list, starting with 0 as the ordinal for the PE with the list, starting with 0 as the ordinal for the PE with the
numerically lowest IP address. The ordinals are used to determine numerically lowest IP address. The ordinals are used to determine
which PE node will be the DF for a given EVPN instance on the which PE node will be the DF for a given EVPN instance on the
Ethernet segment, using the following rule: Ethernet segment, using the following rule:
Assuming a redundancy group of N PE nodes, the PE with ordinal i Assuming a redundancy group of N PE nodes, for VLAN-based service,
is the DF for an EVPN instance with an associated Ethernet tag the PE with ordinal i is the DF for an <ES, VLAN V> when (V mod N)
value V when (V mod N) = i. In the case where multiple Ethernet = i. In the case of VLAN-(aware) bundle service, then the
tags are associated with a single EVPN instance, then the numerically lowest VLAN value in that bundle on that ES MUST be
numerically lowest Ethernet tag value in that EVPN instance on used in the modulo function.
that ES MUST be used in the modulo function.
It should be noted that using the "Originator Router's IP address" It should be noted that using the "Originating Router's IP
field in the Ethernet Segment route to get the PE IP address address" field in the Ethernet Segment route to get the PE IP
needed for the ordered list allows for a CE to be multihomed address needed for the ordered list allows for a CE to be
across different ASes if such a need ever arises. multihomed across different ASes if such a 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 <ES, VLAN> or <ES, VLAN
unblock traffic for the Ethernet tags associated with that EVPN bundle> will unblock multi-destination traffic for that VLAN or
instance. Note that the DF PE unblocks multi-destination traffic VLAN bundle on the corresponding ES. Note that the DF PE unblocks
in the egress direction towards the segment. All non-DF PEs multi-destination traffic in the egress direction towards the
continue to drop multi-destination traffic (for the associated segment. All non-DF PEs continue to drop multi-destination
EVPN instances) in the egress direction towards the segment. traffic in the egress direction towards that <ES, VLAN> or <ES,
VLAN bundle>.
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 redundancy group. For PE node procedures on all the PEs in the redundancy group. For PE node
failure, or upon PE commissioning or decommissioning, the PEs failure, or upon PE commissioning or decommissioning, the PEs
re-trigger the service carving. In the case of Single-Active re-trigger the service carving. In the case of Single-Active
multihoming, when a service moves from one PE in the redundancy multihoming, when a service moves from one PE in the redundancy
group to another PE as a result of re-carving, the PE, which ends group to another PE as a result of re-carving, the PE, which ends
up being the elected DF for the service, SHOULD trigger a MAC up being the elected DF for the service, SHOULD trigger a MAC
address flush notification towards the associated Ethernet address flush notification towards the associated Ethernet
skipping to change at page 29, line 45 skipping to change at page 31, line 10
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/IP Advertisement route. specifically, the MAC/IP Advertisement route.
9.2.1. Constructing MAC/IP Address Advertisement 9.2.1. Constructing MAC/IP Address Advertisement
BGP is extended to advertise these MAC addresses using the MAC/IP BGP is extended to advertise these MAC addresses using the MAC/IP
Advertisement route type in the EVPN NLRI. Advertisement route type in the EVPN NLRI.
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be set per Section 7.9.
procedures for setting the RD for a given EVI are described in
Section 7.9.
The Ethernet Segment Identifier is set to the 10-octet ESI described The Ethernet Segment Identifier is set to the 10-octet ESI described
in Section 5 ("Ethernet Segment"). in Section 5 ("Ethernet Segment").
The Ethernet Tag ID may be zero or may represent a valid Ethernet 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 Tag ID. This field may be non-zero when there are multiple bridge
domains in the MAC-VRF (i.e., the PE needs to perform qualified tables in the MAC-VRF (i.e., the PE needs to support VLAN-aware
learning for the VLANs in that MAC-VRF). bundle service for that EVI).
When the Ethernet Tag ID in the NLRI is set to a non-zero value for a When the Ethernet Tag ID in the NLRI is set to a non-zero value for a
particular bridge domain, then this Ethernet Tag ID may be either the particular broadcast domain, then this Ethernet Tag ID may be either
CE's Ethernet tag value (e.g., CE VLAN ID) or the EVPN provider's the CE's Ethernet tag value (e.g., CE VLAN ID) or the EVPN provider's
Ethernet tag value (e.g., provider VLAN ID). The latter would be the Ethernet tag value (e.g., provider VLAN ID). The latter would be the
case if the CE Ethernet tags (e.g., CE VLAN ID) for a particular case if the CE Ethernet tags (e.g., CE VLAN ID) for a particular
bridge domain are different on different CEs. broadcast domain are different on different CEs.
The MAC Address Length field is in bits, and it is set to 48. MAC The MAC Address Length field is in bits, and it is set to 48. MAC
address length values other than 48 bits are outside the scope of address length values other than 48 bits are outside the scope of
this document. The encoding of a MAC address MUST be the 6-octet MAC this document. The encoding of a MAC address MUST be the 6-octet MAC
address specified by [802.1Q] and [802.1D-REV]. address specified by [802.1Q] and [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 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 route. 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 encoded in this route. When an IP address is present, the IP Address
skipping to change at page 30, line 43 skipping to change at page 32, line 6
The MPLS Label1 field is encoded as 3 octets, where the high-order 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 20 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 toward the CE. The forwarding procedures the destination MAC address toward the CE. The forwarding procedures
are specified in Sections 13 and 14. are specified in Sections 13 and 14.
A 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 is referred to as a per EVI in a given MAC-VRF. This label assignment is referred to as a per
label assignment. Alternatively, a PE may advertise a unique EVPN MAC-VRF label assignment. Alternatively, a PE may advertise a unique
EVPN label per <MAC-VRF, Ethernet tag> combination. This label
assignment is referred to as a per <MAC-VRF, Ethernet tag> label
assignment. As a third option, a PE may advertise a unique EVPN
label per <ESI, Ethernet tag> combination. This label assignment is label per <ESI, Ethernet tag> combination. This label assignment is
referred to as a per <ESI, Ethernet tag> label assignment. As a referred to as a per <ESI, Ethernet tag> label assignment. As a
third option, a PE may advertise a unique EVPN label per MAC address. fourth option, a PE may advertise a unique EVPN label per MAC
This label assignment is referred to as a per MAC label assignment. address. This label assignment is referred to as a per MAC label
All of these label assignment methods have their trade-offs. The assignment. All of these label assignment methods have their trade-
choice of a particular label assignment methodology is purely local offs. The choice of a particular label assignment methodology is
to the PE that originates the route. purely local to the PE that originates the route.
An assignment per EVI label requires the least number of EVPN labels An assignment per MAC-VRF label requires the least number of EVPN
but requires a MAC lookup in addition to an MPLS lookup on an egress labels but requires a MAC lookup in addition to an MPLS lookup on an
PE for forwarding. On the other hand, a unique label per <ESI, egress PE for forwarding. On the other hand, a unique label per
Ethernet tag> or a unique label per MAC allows an egress PE to <ESI, 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. If it is present, then The MPLS Label2 field is an optional field. If it is present, then
it is encoded as 3 octets, where the high-order 20 bits contain the it is encoded as 3 octets, where the high-order 20 bits contain the
label value. label value.
The Next Hop field of the MP_REACH_NLRI attribute of the route MUST The Next Hop field of the MP_REACH_NLRI attribute of the route MUST
skipping to change at page 35, line 25 skipping to change at page 36, line 31
P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or P2MP LSPs, or MP2MP LSPs to send unknown unicast, broadcast, or
multicast traffic to other PEs. multicast traffic to other PEs.
Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to Each PE MUST advertise an "Inclusive Multicast Ethernet Tag route" to
enable the above. The following subsection provides the procedures enable the above. The following subsection provides the procedures
to construct the Inclusive Multicast Ethernet Tag route. Subsequent to construct the Inclusive Multicast Ethernet Tag route. Subsequent
subsections describe its usage in further detail. subsections describe its usage in further detail.
11.1. Constructing Inclusive Multicast Ethernet Tag Route 11.1. Constructing Inclusive Multicast Ethernet Tag Route
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be set per Section 7.9.
procedures for setting the RD for a given EVPN instance on a PE are
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 field value MUST be set to an IP The Originating Router's IP Address field value MUST be set to an IP
address of the PE that should be common for all the EVIs on the PE address of the PE that should be common for all the EVIs on the PE
(e.g., this address may be the PE's loopback address). The IP (e.g., this address may be the PE's loopback address). The IP
Address Length field is in bits. Address 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 IPv4 or IPv6 address of the advertising PE.
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 as described in Section 7.10 MUST be followed. assignment of RTs as described in Section 7.10 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 Provider Multicast Service Interface (PMSI) Tunnel route MUST carry a Provider Multicast Service Interface (PMSI) Tunnel
skipping to change at page 38, line 51 skipping to change at page 40, line 20
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 encapsulate the packet in the ESI MPLS label as described in
Section 8.3. If ingress replication is used, the packet MUST be Section 8.3. If ingress replication is used, the packet MUST be
replicated to each remote PE, with the VPN label being an MPLS replicated to each remote PE, with the VPN label being an MPLS
label determined as follows: This is the MPLS label advertised by label determined as follows: This is the MPLS label advertised by
the remote PE in a PMSI Tunnel attribute in the Inclusive Multicast the remote PE in a PMSI Tunnel attribute in the Inclusive Multicast
Ethernet Tag route for an <EVPN instance, Ethernet tag> Ethernet Tag route for a <MAC-VRF> or <MAC-VRF, Ethernet tag>
combination. The Ethernet tag in the route may be the same as the combination.
Ethernet tag associated with the interface on which the ingress PE
receives the packet. If P2MP LSPs are being used, the packet MUST The Ethernet tag in the route may be the same as the Ethernet tag
be sent on the P2MP LSP of which the PE is the root, for the associated with the interface on which the ingress PE receives the
Ethernet tag in the EVPN instance. If the same P2MP LSP is used packet. If P2MP LSPs are being used, the packet MUST be sent on
for all Ethernet tags, then all the PEs in the EVPN instance MUST the P2MP LSP of which the PE is the root, for the Ethernet tag in
be the leaves of the P2MP LSP. If a distinct P2MP LSP is used for the EVPN instance. If the same P2MP LSP is used for all Ethernet
a given Ethernet tag in the EVPN instance, then only the PEs in the tags, then all the PEs in the EVPN instance MUST be the leaves of
Ethernet tag MUST be the leaves of the P2MP LSP. The packet MUST the P2MP LSP. If a distinct P2MP LSP is used for a given Ethernet
be encapsulated in the P2MP LSP label stack. tag in the EVPN instance, then only the PEs in the Ethernet tag
MUST be the leaves of the P2MP LSP. The packet MUST be
encapsulated in the P2MP 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 describes the procedures for forwarding known and This section describes the procedures for forwarding known and
unknown unicast packets received from a remote PE. unknown unicast packets received from a remote PE.
skipping to change at page 40, line 20 skipping to change at page 41, line 49
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 Packets 14. Load Balancing of Unicast Packets
This section specifies the load-balancing procedures for sending This section specifies the load-balancing procedures for sending
known unicast packets to a multihomed CE. known unicast packets to a multihomed CE.
14.1. Load Balancing of Traffic from a 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/IP Advertisement route for a given
Ethernet tag> in an EVI, it MUST examine all imported Ethernet A-D <ESI, Ethernet tag> in a MAC-VRF, it MUST examine all imported
routes for that ESI in order to determine the load-balancing Ethernet A-D routes for that ESI in order to determine the load-
characteristics of the Ethernet segment. balancing 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
the ESI Label extended community is set, then the remote PE MUST the ESI Label extended community is set, then the remote PE MUST
deduce that the ES is operating in Single-Active redundancy mode. As deduce that the ES is operating in Single-Active redundancy mode. As
such, the MAC address will be reachable only via the PE announcing such, the MAC address will be reachable only via the PE announcing
the associated MAC/IP Advertisement route -- this is referred to as the associated MAC/IP Advertisement route -- this is referred to as
the primary PE. The other PEs advertising the set of Ethernet A-D the primary PE. The other PEs advertising the set of Ethernet A-D
per ES routes for the same ES provide backup paths for that ES, in per ES routes for the same ES provide backup paths for that ES, in
case the primary PE encounters a failure, and are referred to as case the primary PE encounters a failure, and are referred to as
backup PEs. It should be noted that the primary PE for a given <ES, backup PEs. It should be noted that the primary PE for a given <ES,
EVI> is the DF for that <ES, EVI>. VLAN> (or <ES, VLAN bundle>) is the DF for that <ES, VLAN> (or <ES,
VLAN bundle>).
If the primary PE encounters a failure, it MAY withdraw its set of If the primary PE encounters a failure, it MAY withdraw its set of
Ethernet A-D per ES routes for the affected ES prior to withdrawing Ethernet A-D per ES routes for the affected ES prior to withdrawing
its set of MAC/IP Advertisement routes. its set of MAC/IP Advertisement routes.
If there is only one backup PE for a given ES, the remote PE MAY use If there is only one backup PE for a given ES, the remote PE MAY use
the primary PE's withdrawal of its set of Ethernet A-D per ES routes the primary PE's withdrawal of its set of Ethernet A-D per ES routes
as a trigger to update its forwarding entries, for the associated MAC as a trigger to update its forwarding entries, for the associated MAC
addresses, to point towards the backup PE. As the backup PE starts addresses, to point towards the backup PE. As the backup PE starts
learning the MAC addresses over its attached ES, it will start learning the MAC addresses over its attached ES, it will start
skipping to change at page 46, line 19 skipping to change at page 47, line 50
16.1. Ingress Replication 16.1. Ingress Replication
The PEs may use ingress replication for flooding BUM traffic as The PEs may use ingress replication for flooding BUM traffic as
described in Section 11 ("Handling of Multi-destination Traffic"). A described in Section 11 ("Handling of Multi-destination Traffic"). A
given broadcast packet must be sent to all the remote PEs. However, 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 a given multicast packet for a multicast flow may be sent to only a
subset of the PEs. Specifically, a given multicast flow may be sent subset of the PEs. Specifically, a given multicast flow may be sent
to only those PEs that have receivers that are interested in the to only those PEs that have receivers that are interested in the
multicast flow. Determining which of the PEs have receivers for a multicast flow. Determining which of the PEs have receivers for a
given multicast flow is done using explicit tracking, as described given multicast flow is done using explicit tracking per [RFC7117].
below.
16.2. P2MP LSPs 16.2. P2MP LSPs
A PE may use an "Inclusive" tree for sending a BUM packet. This A PE may use an "Inclusive" tree for sending a BUM packet. This
terminology is borrowed from [RFC7117]. terminology is borrowed from [RFC7117].
A variety of transport technologies may be used in the service A variety of transport technologies may be used in the service
provider (SP) network. For Inclusive P-multicast trees, these provider (SP) network. For Inclusive P-multicast trees, these
transport technologies include point-to-multipoint LSPs created by transport technologies include point-to-multipoint LSPs created by
RSVP-TE or Multipoint LDP (mLDP). RSVP-TE or Multipoint LDP (mLDP).
skipping to change at page 47, line 41 skipping to change at page 49, line 30
session. This failure detection can be in the sub-second range if session. This failure detection can be in the sub-second range if
Bidirectional Forwarding Detection (BFD) is used to detect BGP Bidirectional Forwarding Detection (BFD) is used to detect BGP
session failures. PE3 can update its forwarding state to start session failures. PE3 can update its forwarding state to start
sending all traffic for CE1 to only PE2. sending all traffic for CE1 to only PE2.
17.3. PE-to-CE Network Failures 17.3. PE-to-CE Network Failures
If the connectivity between the multihomed CE and one of the PEs to If the connectivity between the multihomed CE and one of the PEs to
which it is attached fails, the PE MUST withdraw the set of Ethernet which it is attached fails, the PE MUST withdraw the set of Ethernet
A-D per ES routes that had been previously advertised for that ES. 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 This enables the remote PEs to remove the MPLS next hop to this
address from BGP. Note that to aid convergence, the Ethernet A-D per particular PE from the set of MPLS next hops that can be used to
EVI routes MAY be withdrawn before the MAC routes. This enables the forward traffic to the CE. When the MAC entry on the PE ages out,
remote PEs to remove the MPLS next hop to this particular PE from the the PE MUST withdraw the MAC address from BGP.
set of MPLS next hops that can be used to forward traffic to the CE.
When an Ethernet tag is decommissioned on an Ethernet segment, then When an Ethernet tag is decommissioned on an Ethernet segment, then
the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for the PE MUST withdraw the Ethernet A-D per EVI route(s) announced for
the <ESI, Ethernet tags> that are impacted by the decommissioning. the <ESI, Ethernet tags> that are impacted by the decommissioning.
In addition, the PE MUST also withdraw the MAC/IP Advertisement In addition, the PE MUST also withdraw the MAC/IP Advertisement
routes that are impacted by the decommissioning. routes that are impacted by the decommissioning.
The Ethernet A-D per ES 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/IP Advertisement routes. When a PE optimize the withdrawal of MAC/IP Advertisement routes. When a PE
receives a withdrawal of a particular Ethernet A-D route from an receives a withdrawal of a particular Ethernet A-D route from an
skipping to change at page 48, line 34 skipping to change at page 50, line 25
the destination out of order. This out-of-order delivery can happen the destination out of order. This out-of-order delivery can happen
during steady state in the absence of any failures, resulting in during steady state in the absence of any failures, resulting in
significant impact on network operations. significant impact on network operations.
In order to avoid any such misordering, the following rules are In order to avoid any such misordering, 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
"Preferred PW MPLS Control Word" [RFC4385] SHOULD be used with the "Preferred PW MPLS Control Word" [RFC4385] SHOULD be used with the
value 0 (e.g., a 4-octet field with a value of zero) when sending value 0 (e.g., a 4-octet field with a value of zero) when sending
EVPN encapsulated packets over an MP2P LSP. EVPN-encapsulated packets over an MP2P LSP.
- If a network uses entropy labels [RFC6790], then the control word - If a network uses entropy labels [RFC6790], then the control word
SHOULD NOT be used when sending EVPN encapsulated packets over an SHOULD NOT be used when sending EVPN-encapsulated packets over an
MP2P LSP. MP2P LSP.
- When sending EVPN encapsulated packets over a P2MP LSP or P2P LSP, - When sending EVPN-encapsulated packets over a P2MP LSP or P2P LSP,
then the control word SHOULD NOT be used. then the control word SHOULD NOT be used.
19. Security Considerations 19. 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 the data plane over an Attachment this document for MAC learning in the 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 over the MPLS/IP core. Security considerations discussed in
[RFC4364] apply to this document for MAC learning in the control [RFC4364] apply to this document for MAC learning in the control
plane over the MPLS/IP core. This section describes additional plane over the MPLS/IP core. This section describes additional
skipping to change at page 50, line 20 skipping to change at page 52, line 16
This document defines a new NLRI, called "EVPN", to be carried in BGP This document defines a new NLRI, called "EVPN", to be carried in BGP
using multiprotocol extensions. This NLRI uses the existing AFI of using multiprotocol extensions. This NLRI uses the existing AFI of
25 (L2VPN). IANA has assigned BGP EVPNs a SAFI value of 70. 25 (L2VPN). IANA has assigned BGP EVPNs a SAFI value of 70.
IANA has allocated the following EVPN Extended Community sub-types in IANA has allocated the following EVPN Extended Community sub-types in
[RFC7153], and this document is the only reference for them. [RFC7153], and this document is the only reference for them.
0x00 MAC Mobility [RFC7432] 0x00 MAC Mobility [RFC7432]
0x01 ESI Label [RFC7432] 0x01 ESI Label [RFC7432]
0x02 ES-Import Route Targe [RFC7432] 0x02 ES-Import Route Target [RFC7432]
This document creates a registry called "EVPN Route Types". New This document creates a registry called "EVPN Route Types". New
registrations will be made through the "RFC Required" procedure registrations will be made through the "RFC Required" procedure
defined in [RFC5226]. The registry has a maximum value of 255. defined in [RFC5226]. The registry has a maximum value of 255.
Initial registrations are as follows: Initial registrations are as follows:
0 Reserved [RFC7432] 0 Reserved [RFC7432]
1 Ethernet Auto-discovery [RFC7432] 1 Ethernet Auto-discovery [RFC7432]
2 MAC/IP Advertisement [RFC7432] 2 MAC/IP Advertisement [RFC7432]
3 Inclusive Multicast Ethernet Tag [RFC7432] 3 Inclusive Multicast Ethernet Tag [RFC7432]
skipping to change at page 54, line 8 skipping to change at page 55, line 16
Vohra, Kireeti Kompella, and Apurva Mehta for their contributions to Vohra, Kireeti Kompella, and Apurva Mehta for their contributions to
this document. this document.
Last but not least, special thanks to Giles Heron (our WG chair) for Last but not least, special thanks to Giles Heron (our WG chair) for
his detailed review of this document in preparation for WG Last Call his detailed review of this document in preparation for WG Last Call
and for making many valuable suggestions. and for making many valuable suggestions.
Contributors Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
individuals have also helped to shape this document: co-authors have also contributed to this document:
Keyur Patel Keyur Patel
Samer Salam Samer Salam
Sami Boutros Sami Boutros
Cisco Cisco
Yakov Rekhter Yakov Rekhter
Ravi Shekhar Ravi Shekhar
Juniper Networks Juniper Networks
 End of changes. 58 change blocks. 
208 lines changed or deleted 227 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/