rfc7432v2.txt   rfc7432.txt 
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 ...................................33
10. ARP and ND ....................................................32 10. ARP and ND ....................................................34
10.1. Default Gateway ..........................................33 10.1. Default Gateway ..........................................35
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 ......................................39
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 ....................40
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 for an EVI.
Ethernet Segment (ES): When a customer site (device or network) is Ethernet Segment (ES): When a customer site (device or network) is
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 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 EVI
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 EVI that is
advertising the NLRI. An RD MUST be assigned for a given EVI on a 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 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 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
skipping to change at page 18, line 25 skipping to change at page 19, line 13
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.
skipping to change at page 19, line 9 skipping to change at page 19, line 45
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
skipping to change at page 25, line 35 skipping to change at page 26, line 28
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 EVI.
EVI. This is applicable when the PE uses MPLS-based disposition. 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 EVI (where the Ethernet
set to 0). This is applicable when the PE uses MAC-based Tag ID is set to 0). This is applicable when the PE uses MAC-based
disposition, or when the PE uses MPLS-based disposition when no disposition or MPLS-based disposition without VID translation.
VLAN translation is required.
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 27, line 17 skipping to change at page 28, line 20
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, the PE with ordinal i
is the DF for an EVPN instance with an associated Ethernet tag 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 value V when (V mod N) = i. In the case where multiple Ethernet
tags are associated with a single EVPN instance, then the tags are associated with a single EVPN instance, then the
numerically lowest Ethernet tag value in that EVPN instance on numerically lowest Ethernet tag value in that EVPN instance on
that ES MUST be 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 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 instance. Note that the DF PE unblocks multi-destination traffic
in the egress direction towards the segment. All non-DF PEs in the egress direction towards the segment. All non-DF PEs
continue to drop multi-destination traffic (for the associated continue to drop multi-destination traffic (for the associated
EVPN instances) in the egress direction towards the segment. EVPN instances) in 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
skipping to change at page 30, line 7 skipping to change at page 31, line 19
The RD MUST be the RD of the EVI that is advertising the NLRI. The The RD MUST be the RD of the EVI that is advertising the NLRI. The
procedures for setting the RD for a given EVI are described in procedures for setting the RD for a given EVI are described in
Section 7.9. Section 7.9.
The Ethernet Segment Identifier is set to the 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 bridge table, then this Ethernet Tag ID may be either the
CE's Ethernet tag value (e.g., CE VLAN ID) or the EVPN provider's 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. bridge table 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 45 skipping to change at page 32, line 8
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 EVI. This label assignment is referred to as a per EVI
label assignment. Alternatively, a PE may advertise a unique EVPN label assignment. Alternatively, a PE may advertise a unique EVPN
label per <ESI, Ethernet tag> combination. This label assignment is label per <EVI, Ethernet tag> combination. This label assignment is
referred to as a per <ESI, Ethernet tag> label assignment. As a referred to as a per <EVI, Ethernet tag> label assignment. As a
third option, a PE may advertise a unique EVPN label per MAC address. third option, a PE may advertise a unique EVPN label per <ESI,
This label assignment is referred to as a per MAC label assignment. Ethernet tag> combination. This label assignment is referred to as a
All of these label assignment methods have their trade-offs. The per <ESI, Ethernet tag> label assignment. As a fourth option, a PE
choice of a particular label assignment methodology is purely local may advertise a unique EVPN label per MAC address. This label
to the PE that originates the route. assignment is referred to as a per MAC label assignment. All of
these label assignment methods have their trade-offs. The choice of
a particular label assignment methodology is purely local to the PE
that originates the route.
An assignment per EVI label requires the least number of EVPN labels An assignment per EVI label 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.
skipping to change at page 35, line 38 skipping to change at page 37, line 11
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 36
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 an <EVI> or <EVI, Ethernet tag> combination.
combination. The Ethernet tag in the route may be the same as the
Ethernet tag associated with the interface on which the ingress PE The Ethernet tag in the route may be the same as the Ethernet tag
receives the packet. If P2MP LSPs are being used, the packet MUST associated with the interface on which the ingress PE receives the
be sent on the P2MP LSP of which the PE is the root, for the packet. If P2MP LSPs are being used, the packet MUST be sent on
Ethernet tag in the EVPN instance. If the same P2MP LSP is used the P2MP LSP of which the PE is the root, for the Ethernet tag in
for all Ethernet tags, then all the PEs in the EVPN instance MUST the EVPN instance. If the same P2MP LSP is used for all Ethernet
be the leaves of the P2MP LSP. If a distinct P2MP LSP is used for tags, then all the PEs in the EVPN instance MUST be the leaves of
a given Ethernet tag in the EVPN instance, then only the PEs in the the P2MP LSP. If a distinct P2MP LSP is used for a given Ethernet
Ethernet tag MUST be the leaves of the P2MP LSP. The packet MUST tag in the EVPN instance, then only the PEs in the Ethernet tag
be encapsulated in the P2MP LSP label stack. 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 an EVI, it MUST examine all imported Ethernet
routes for that ESI in order to determine the load-balancing A-D 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
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 <ESI,
EVI> is the DF for that <ES, EVI>. EVI> is the DF for that <ESI, EVI>.
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]
 End of changes. 40 change blocks. 
150 lines changed or deleted 171 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/