draft-ietf-bess-evpn-inter-subnet-forwarding-06.txt   draft-ietf-bess-evpn-inter-subnet-forwarding-07.txt 
L2VPN Workgroup A. Sajassi, Ed. L2VPN Workgroup A. Sajassi, Ed.
INTERNET-DRAFT S. Salam INTERNET-DRAFT S. Salam
Intended Status: Standards Track S. Thoria Intended Status: Standards Track S. Thoria
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
J. Rabadan J. Rabadan
Nokia Nokia
Expires: August 3, 2019 February 3, 2019 Expires: August 11, 2019 February 11, 2019
Integrated Routing and Bridging in EVPN Integrated Routing and Bridging in EVPN
draft-ietf-bess-evpn-inter-subnet-forwarding-06 draft-ietf-bess-evpn-inter-subnet-forwarding-07
Abstract Abstract
EVPN provides an extensible and flexible multi-homing VPN solution EVPN provides an extensible and flexible multi-homing VPN solution
over an MPLS/IP network for intra-subnet connectivity among Tenant over an MPLS/IP network for intra-subnet connectivity among Tenant
Systems and End Devices that can be physical or virtual. However, Systems and End Devices that can be physical or virtual. However,
there are scenarios for which there is a need for a dynamic and there are scenarios for which there is a need for a dynamic and
efficient inter-subnet connectivity among these Tenant Systems and efficient inter-subnet connectivity among these Tenant Systems and
End Devices while maintaining the multi-homing capabilities of EVPN. End Devices while maintaining the multi-homing capabilities of EVPN.
This document describes an Integrated Routing and Bridging (IRB) This document describes an Integrated Routing and Bridging (IRB)
skipping to change at page 2, line 27 skipping to change at page 2, line 27
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 EVPN PE Model for IRB Operation . . . . . . . . . . . . . . . . 7 2 EVPN PE Model for IRB Operation . . . . . . . . . . . . . . . . 7
3 Symmetric and Asymmetric IRB . . . . . . . . . . . . . . . . . 8 3 Symmetric and Asymmetric IRB . . . . . . . . . . . . . . . . . 8
3.1 IRB Interface and its MAC & IP addresses . . . . . . . . . . 11 3.1 IRB Interface and its MAC & IP addresses . . . . . . . . . . 11
3.2 Symmetric IRB Procedures . . . . . . . . . . . . . . . . . . 13 3.2 Symmetric IRB Procedures . . . . . . . . . . . . . . . . . . 13
3.2.1 Control Plane - Ingress PE . . . . . . . . . . . . . . . 13 3.2.1 Control Plane - Advertising PE . . . . . . . . . . . . . 13
3.2.2 Control Plane - Egress PE . . . . . . . . . . . . . . . 14 3.2.2 Control Plane - Receiving PE . . . . . . . . . . . . . . 14
3.2.3 Data Plane - Ingress PE . . . . . . . . . . . . . . . . 15 3.2.3 Data Plane - Ingress PE . . . . . . . . . . . . . . . . 15
3.2.4 Data Plane - Egress PE . . . . . . . . . . . . . . . . . 15 3.2.4 Data Plane - Egress PE . . . . . . . . . . . . . . . . . 15
3.3 Asymmetric IRB Procedures . . . . . . . . . . . . . . . . . 16 3.3 Asymmetric IRB Procedures . . . . . . . . . . . . . . . . . 16
3.3.1 Control Plane - Ingress PE . . . . . . . . . . . . . . . 16 3.3.1 Control Plane - Advertising PE . . . . . . . . . . . . . 16
3.3.2 Control Plane - Egress PE . . . . . . . . . . . . . . . 17 3.3.2 Control Plane - Receiving PE . . . . . . . . . . . . . . 17
3.3.3 Data Plane - Ingress PE . . . . . . . . . . . . . . . . 17 3.3.3 Data Plane - Ingress PE . . . . . . . . . . . . . . . . 17
3.3.4 Data Plane - Egress PE . . . . . . . . . . . . . . . . . 18 3.3.4 Data Plane - Egress PE . . . . . . . . . . . . . . . . . 18
4 Mobility Procedure . . . . . . . . . . . . . . . . . . . . . . . 18 4 Mobility Procedure . . . . . . . . . . . . . . . . . . . . . . . 18
4.1 Mobility Procedure for Symmetric IRB . . . . . . . . . . . . 19 4.1 Initiating an ARP Request upon a Move . . . . . . . . . . . 19
4.1.1 Initiating an ARP Request upon a Move . . . . . . . . . 19 4.2 Sending Data Traffic without an ARP Request . . . . . . . . 20
4.1.2 Sending Data Traffic without an ARP Request . . . . . . 20 4.3 Silent Host . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Silent Host . . . . . . . . . . . . . . . . . . . . . . 22 5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 BGP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1 Router's MAC Extended Community . . . . . . . . . . . . . . 23
5.1 Router's MAC Extended Community . . . . . . . . . . . . . . 22
6 Operational Models for Symmetric Inter-Subnet Forwarding . . . . 23 6 Operational Models for Symmetric Inter-Subnet Forwarding . . . . 23
6.1 IRB forwarding on NVEs for Tenant Systems . . . . . . . . . 23 6.1 IRB forwarding on NVEs for Tenant Systems . . . . . . . . . 23
6.1.1 Control Plane Operation . . . . . . . . . . . . . . . . 25 6.1.1 Control Plane Operation . . . . . . . . . . . . . . . . 25
6.1.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 26 6.1.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 26
6.2 IRB forwarding on NVEs for Subnets behind Tenant Systems . . 27 6.2 IRB forwarding on NVEs for Subnets behind Tenant Systems . . 27
6.2.1 Control Plane Operation . . . . . . . . . . . . . . . . 28 6.2.1 Control Plane Operation . . . . . . . . . . . . . . . . 29
6.2.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 29 6.2.2 Data Plane Operation . . . . . . . . . . . . . . . . . . 30
7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31
8 Security Considerations . . . . . . . . . . . . . . . . . . . . 30 8 Security Considerations . . . . . . . . . . . . . . . . . . . . 31
9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31 9 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 31
10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.1 Normative References . . . . . . . . . . . . . . . . . . . 31 10.1 Normative References . . . . . . . . . . . . . . . . . . . 32
10.2 Informative References . . . . . . . . . . . . . . . . . . 31 10.2 Informative References . . . . . . . . . . . . . . . . . . 32
11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 11 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Terminology Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AC: Attachment Circuit. AC: Attachment Circuit.
skipping to change at page 4, line 28 skipping to change at page 4, line 26
IRB: Integrated Routing and Bridging interface. It connects an IP-VRF IRB: Integrated Routing and Bridging interface. It connects an IP-VRF
to a BD (or subnet). to a BD (or subnet).
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 an NVE/PE, as per [RFC7432]. A MAC-VRF is Control (MAC) addresses on an NVE/PE, as per [RFC7432]. A MAC-VRF is
also an instantiation of an EVI in an NVE/PE. also an instantiation of an EVI in an NVE/PE.
ML: MAC address length. ML: MAC address length.
NDP: Neighbor Discovery Protocol. ND: Neighbor Discovery Protocol.
NVE: Network Virtualization Edge. NVE: Network Virtualization Edge.
GENEVE: Generic Network Virtualization Encapsulation, [GENEVE]. GENEVE: Generic Network Virtualization Encapsulation, [GENEVE].
NVO: Network Virtualization Overlays. NVO: Network Virtualization Overlays.
RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined RT-2: EVPN route type 2, i.e., MAC/IP advertisement route, as defined
in [RFC7432]. in [RFC7432].
skipping to change at page 6, line 46 skipping to change at page 6, line 46
a packet by packet basis thus meeting the requirements for both intra a packet by packet basis thus meeting the requirements for both intra
and inter-subnet forwarding and avoiding non-optimum traffic and inter-subnet forwarding and avoiding non-optimum traffic
forwarding associate with centralized L3GW approach. forwarding associate with centralized L3GW approach.
Some TSes run non-IP protocols in conjunction with their IP traffic. Some TSes run non-IP protocols in conjunction with their IP traffic.
Therefore, it is important to handle both kinds of traffic optimally Therefore, it is important to handle both kinds of traffic optimally
- e.g., to bridge non-IP and intra-subnet traffic and to route inter- - e.g., to bridge non-IP and intra-subnet traffic and to route inter-
subnet IP traffic. Therefore, the solution needs to meet the subnet IP traffic. Therefore, the solution needs to meet the
following requirements: following requirements:
R1: The solution MUST allow for both inter-subnet and intra-subnet R1: The solution must allow for both inter-subnet and intra-subnet
traffic belonging to the same tenant to be locally routed and bridged traffic belonging to the same tenant to be locally routed and bridged
respectively. The solution MUST provide IP routing for inter-subnet respectively. The solution must provide IP routing for inter-subnet
traffic and Ethernet Bridging for intra-subnet traffic. traffic and Ethernet Bridging for intra-subnet traffic.
R2: The solution MUST support bridging for non-IP traffic. R2: The solution must support bridging for non-IP traffic.
R3: The solution MUST allow inter-subnet switching to be disabled on R3: The solution must allow inter-subnet switching to be disabled on
a per VLAN basis on PEs where the traffic needs to be back hauled to a per VLAN basis on PEs where the traffic needs to be back hauled to
another node (i.e., for performing FW or DPI functionality). another node (i.e., for performing FW or DPI functionality).
2 EVPN PE Model for IRB Operation 2 EVPN PE Model for IRB Operation
Since this document discusses IRB operation in relationship to EVPN Since this document discusses IRB operation in relationship to EVPN
MAC-VRF, IP-VRF, EVI, Bridge Domain (BD), Bridge Table (BT), and IRB MAC-VRF, IP-VRF, EVI, Bridge Domain (BD), Bridge Table (BT), and IRB
interfaces, it is important to understand the relationship among interfaces, it is important to understand the relationship among
these components. Therefore, the following PE model is demonstrated these components. Therefore, the following PE model is illustrated
below to a) describe these components and b) illustrate the below to a) describe these components and b) illustrate the
relationship among them. relationship among them.
+-------------------------------------------------------------+ +-------------------------------------------------------------+
| | | |
| +------------------+ IRB PE | | +------------------+ IRB PE |
| Attachment | +------------------+ | | Attachment | +------------------+ |
| Circuit(AC1) | | +----------+ | MPLS/NVO tnl | Circuit(AC1) | | +----------+ | MPLS/NVO tnl
----------------------*Bridge | | +----- ----------------------*Bridge | | +-----
| | | |Table(BT1)| | +-----------+ / \ \ | | | |Table(BT1)| | +-----------+ / \ \
| | | | *---------* |<--> |Eth| | | | | *---------* |<--> |Eth|
| | | |Eth-Tag x | |IRB1| | \ / / | | | | VLAN x | |IRB1| | \ / /
| | | +----------+ | | | +----- | | | +----------+ | | | +-----
| | | ... | | IP-VRF1 | | | | | ... | | IP-VRF1 | |
| | | +----------+ | | RD2/RT2 |MPLS/NVO tnl | | | +----------+ | | RD2/RT2 |MPLS/NVO tnl
| | | |Bridge | | | | +----- | | | |Bridge | | | | +-----
| | | |Table(BT2)| |IRB2| | / \ \ | | | |Table(BT2)| |IRB2| | / \ \
| | | | *---------* |<--> |IP | | | | | *---------* |<--> |IP |
----------------------*Eth-Tag y | | +-----------+ \ / / ----------------------* VLAN y | | +-----------+ \ / /
| AC2 | | +----------+ | +----- | AC2 | | +----------+ | +-----
| | | MAC-VRF1 | | | | | MAC-VRF1 | |
| +-+ RD1/RT1 | | | +-+ RD1/RT1 | |
| +------------------+ | | +------------------+ |
| | | |
| | | |
+-------------------------------------------------------------+ +-------------------------------------------------------------+
Figure 1: EVPN IRB PE Model Figure 1: EVPN IRB PE Model
A tenant needing IRB services on a PE, requires an IP Virtual Routing A tenant needing IRB services on a PE, requires an IP Virtual Routing
and Forwarding table (IP-VRF) along with one or more MAC Virtual and Forwarding table (IP-VRF) along with one or more MAC Virtual
Routing and Forwarding tables (MAC-VRFs). An IP-VRF, as defined in Routing and Forwarding tables (MAC-VRFs). An IP-VRF, as defined in
[RFC4364], is the instantiation of an IPVPN in a PE. A MAC-VRF, as [RFC4364], is the instantiation of an IPVPN instance in a PE. A MAC-
defined in [RFC7432], is the instantiation of an EVI (EVPN Instancce) VRF, as defined in [RFC7432], is the instantiation of an EVI (EVPN
in a PE. A MAC-VRF can consists of one or more Bridge Tables (BTs) Instance) in a PE. A MAC-VRF can consists of one or more Bridge
where each BT corresponds to a VLAN (broadcast domain - BD). If Tables (BTs) where each BT corresponds to a VLAN (broadcast domain -
service interfaces for an EVPN PE are configured in VLAN-Based mode BD). If service interfaces for an EVPN PE are configured in VLAN-
(i.e., section 6.1 of [RFC7432]), then there is only a single BT per Based mode (i.e., section 6.1 of [RFC7432]), then there is only a
MAC-VRF (per EVI) - i.e., there is only one tenant VLAN per EVI. single BT per MAC-VRF (per EVI) - i.e., there is only one tenant VLAN
However, if service interfaces for an EVPN PE are configured in VLAN- per EVI. However, if service interfaces for an EVPN PE are configured
Aware Bundle mode (i.e., section 6.3 of [RFC7432]), then there are in VLAN-Aware Bundle mode (i.e., section 6.3 of [RFC7432]), then
several BTs per MAC-VRF (per EVI) - i.e., there are several tenant there are several BTs per MAC-VRF (per EVI) - i.e., there are several
VLANs per EVI. tenant VLANs per EVI.
Each BT is connected to a IP-VRF via a L3 interface called IRB Each BT is connected to a IP-VRF via a L3 interface called IRB
interface. Since a single tenant subnet is typically (and in this interface. Since a single tenant subnet is typically (and in this
document) represented by a VLAN (and thus supported by a single BT), document) represented by a VLAN (and thus supported by a single BT),
for a given tenant there are as many BTs as there are subnets and for a given tenant there are as many BTs as there are subnets and
thus there are also as many IRB interfaces between the tenant IP-VRF thus there are also as many IRB interfaces between the tenant IP-VRF
and the associated BTs as shown in the PE model above. and the associated BTs as shown in the PE model above.
IP-VRF is identified by its corresponding route target and route IP-VRF is identified by its corresponding route target and route
distinguisher and MAC-VRF is also identified by its corresponding distinguisher and MAC-VRF is also identified by its corresponding
skipping to change at page 11, line 32 skipping to change at page 11, line 32
To support inter-subnet forwarding on a PE, the PE acts as an IP To support inter-subnet forwarding on a PE, the PE acts as an IP
Default Gateway from the perspective of the attached Tenant Systems Default Gateway from the perspective of the attached Tenant Systems
where default gateway MAC and IP addresses are configured on each IRB where default gateway MAC and IP addresses are configured on each IRB
interface associated with its subnet and falls into one of the interface associated with its subnet and falls into one of the
following two options: following two options:
1. All the PEs for a given tenant subnet use the same anycast default 1. All the PEs for a given tenant subnet use the same anycast default
gateway IP and MAC addresses . On each PE, this default gateway IP gateway IP and MAC addresses . On each PE, this default gateway IP
and MAC addresses correspond to the IRB interface connecting the BT and MAC addresses correspond to the IRB interface connecting the BT
associated with the tenant's <EVI, VLAN> to the corresponding associated with the tenant's VLAN to the corresponding tenant's IP-
tenant's IP-VRF. VRF.
2. Each PE for a given tenant subnet uses the same anycast default 2. Each PE for a given tenant subnet uses the same anycast default
gateway IP address but its own MAC address. These MAC addresses are gateway IP address but its own MAC address. These MAC addresses are
aliased to the same anycast default gateway IP address through the aliased to the same anycast default gateway IP address through the
use of the Default Gateway extended community as specified in use of the Default Gateway extended community as specified in
[RFC7432], which is carried in the EVPN MAC/IP Advertisement routes. [RFC7432], which is carried in the EVPN MAC/IP Advertisement routes.
On each PE, this default gateway IP address along with its associated On each PE, this default gateway IP address along with its associated
MAC addresses correspond to the IRB interface connecting the BT MAC addresses correspond to the IRB interface connecting the BT
associated with the tenant's <EVI, VLAN> to the corresponding associated with the tenant's VLAN to the corresponding tenant's IP-
tenant's IP-VRF. VRF.
It is worth noting that if the applications that are running on the It is worth noting that if the applications that are running on the
TSes are employing or relying on any form of MAC security, then TSes are employing or relying on any form of MAC security, then
either the first model (i.e. using anycast MAC address) should be either the first model (i.e. using anycast MAC address) should be
used to ensure that the applications receive traffic from the same used to ensure that the applications receive traffic from the same
IRB interface MAC address that they are sending to, or if the second IRB interface MAC address that they are sending to, or if the second
model is used, then the IRB interface MAC address MUST be the one model is used, then the IRB interface MAC address MUST be the one
used in the initial ARP reply or ND Neighbor Advertisement (NA) for used in the initial ARP reply or ND Neighbor Advertisement (NA) for
that TS. that TS.
Although both of these options are equally applicable to both Although both of these options are equally applicable to both
symmetric and asymmetric IRB, the option-1 is recommended because of symmetric and asymmetric IRB, the option-1 is recommended because of
the ease of anycast MAC address provisioning on not only the IRB the ease of anycast MAC address provisioning on not only the IRB
interface associated with a given subnet across all the PEs interface associated with a given subnet across all the PEs
corresponding to that EVI but also on all IRB interfaces associated corresponding to that VLAN but also on all IRB interfaces associated
with all the tenant's subnets across all the PEs corresponding to all with all the tenant's subnets across all the PEs corresponding to all
the EVIs for that tenant. Furthermore, it simplifies the operation as the VLANs for that tenant. Furthermore, it simplifies the operation
there is no need for Default Gateway extended community advertisement as there is no need for Default Gateway extended community
and its associated MAC aliasing procedure. Yet another advantage is advertisement and its associated MAC aliasing procedure. Yet another
that following host mobility, the host does not need to refresh the advantage is that following host mobility, the host does not need to
default GW ARP/ND entry. refresh the default GW ARP/ND entry.
If option-1 is used, an implementation MAY choose to auto-derive the If option-1 is used, an implementation MAY choose to auto-derive the
anycast MAC address. If auto-derivation is used, the anycast MAC MUST anycast MAC address. If auto-derivation is used, the anycast MAC MUST
be auto-derived out of the following ranges (which are defined in be auto-derived out of the following ranges (which are defined in
[RFC5798]): [RFC5798]):
- Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID} (in hex, in Internet - Anycast IPv4 IRB case: 00-00-5E-00-01-{VRID} (in hex, in Internet
standard bit-order) standard bit-order)
- Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID} (in hex, in Internet - Anycast IPv6 IRB case: 00-00-5E-00-02-{VRID} (in hex, in Internet
skipping to change at page 13, line 12 skipping to change at page 13, line 12
hardware address in the payload). For example, in figure 4, TS1 is hardware address in the payload). For example, in figure 4, TS1 is
configured with the anycast IPx address as its default gateway IP configured with the anycast IPx address as its default gateway IP
address and thus when it sends an ARP request for IPx (anycast IP address and thus when it sends an ARP request for IPx (anycast IP
address of the IRB interface for BT1), the PE1 sends an ARP reply address of the IRB interface for BT1), the PE1 sends an ARP reply
with the MACx which is the anycast MAC address of that IRB interface. with the MACx which is the anycast MAC address of that IRB interface.
Traffic routed from IP-VRF1 to TS1 SHOULD use the anycast MAC address Traffic routed from IP-VRF1 to TS1 SHOULD use the anycast MAC address
as source MAC address. as source MAC address.
3.2 Symmetric IRB Procedures 3.2 Symmetric IRB Procedures
3.2.1 Control Plane - Ingress PE 3.2.1 Control Plane - Advertising PE
When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of
a TS (via an ARP request), it adds the MAC address to the a TS (via an ARP request), it adds the MAC address to the
corresponding MAC-VRF/BT of that tenant's subnet and adds the IP corresponding MAC-VRF/BT of that tenant's subnet and adds the IP
address to the IP-VRF for that tenant. Furthermore, it adds this TS's address to the IP-VRF for that tenant. Furthermore, it adds this TS's
MAC and IP address association to its ARP table. It then builds an MAC and IP address association to its ARP table. It then builds an
EVPN MAC/IP Advertisement route (type 2) as follows and advertises it EVPN MAC/IP Advertisement route (type 2) as follows and advertises it
to other PEs participating in that tenant's VPN. to other PEs participating in that tenant's VPN.
- The Length field of the BGP EVPN NLRI for an EVPN MAC/IP - The Length field of the BGP EVPN NLRI for an EVPN MAC/IP
skipping to change at page 14, line 9 skipping to change at page 14, line 9
For symmetric IRB mode, Router's MAC EC is needed to carry the PE's For symmetric IRB mode, Router's MAC EC is needed to carry the PE's
overlay MAC address (e.g., inner MAC address in NVO encapsulation) overlay MAC address (e.g., inner MAC address in NVO encapsulation)
which is used for IP-VRF to IP-VRF communications with Ethernet NVO which is used for IP-VRF to IP-VRF communications with Ethernet NVO
tunnel. If MPLS or IP-only NVO tunnel is used, then there is no need tunnel. If MPLS or IP-only NVO tunnel is used, then there is no need
to send Router's MAC Extended Community along with this route. to send Router's MAC Extended Community along with this route.
This route MUST be advertised with two route targets - one This route MUST be advertised with two route targets - one
corresponding to the MAC-VRF of the tenant's subnet and another corresponding to the MAC-VRF of the tenant's subnet and another
corresponding to the tenant's IP-VRF. corresponding to the tenant's IP-VRF.
3.2.2 Control Plane - Egress PE 3.2.2 Control Plane - Receiving PE
When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP
Advertisement route advertisement, it performs the following: Advertisement route advertisement, it performs the following:
- Using MAC-VRF Route Target (and Ethernet Tag if different from - Using MAC-VRF Route Target (and Ethernet Tag if different from
zero), it identifies the corresponding MAC-VRF (and BT). If the MAC- zero), it identifies the corresponding MAC-VRF (and BT). If the MAC-
VRF (and BT) exists (e.g., it is locally configured) then it imports VRF (and BT) exists (e.g., it is locally configured) then it imports
the MAC address into it. Otherwise, it does not import the MAC the MAC address into it. Otherwise, it does not import the MAC
address. address.
skipping to change at page 14, line 37 skipping to change at page 14, line 37
If the receiving PE receives this route with both the MAC-VRF and IP- If the receiving PE receives this route with both the MAC-VRF and IP-
VRF route targets but the MAC/IP Advertisement route does not include VRF route targets but the MAC/IP Advertisement route does not include
MPLS label2 field and if the receiving PE supports asymmetric IRB MPLS label2 field and if the receiving PE supports asymmetric IRB
mode, then the receiving PE installs the MAC address in the mode, then the receiving PE installs the MAC address in the
corresponding MAC-VRF and <IP, MAC> association in the ARP table for corresponding MAC-VRF and <IP, MAC> association in the ARP table for
that tenant (identified by the corresponding IP-VRF route target). that tenant (identified by the corresponding IP-VRF route target).
If the receiving PE receives this route with both the MAC-VRF and IP- If the receiving PE receives this route with both the MAC-VRF and IP-
VRF route targets but the MAC/IP Advertisement route does not include VRF route targets but the MAC/IP Advertisement route does not include
MPLS label2 field and if the receiving PE does not support asymmetric MPLS label2 field and if the receiving PE does not support either
IRB mode, then if it has the corresponding MAC-VRF, it only imports asymmetric or symmetric IRB modes, then if it has the corresponding
the MAC address; otherwise, if it doesn't have the corresponding MAC- MAC-VRF, it only imports the MAC address; otherwise, if it doesn't
VRF, it MUST treat the route as withdraw [RFC7606] and log an error have the corresponding MAC-VRF, it MUST treat the route as withdraw
message. [RFC7606] and log an error message.
If the receiving PE receives this route with both the MAC-VRF and IP- If the receiving PE receives this route with both the MAC-VRF and IP-
VRF route targets and the MAC/IP Advertisement route includes MPLS VRF route targets and the MAC/IP Advertisement route includes MPLS
label2 field but the receiving PE only supports asymmetric IRB mode, label2 field but the receiving PE only supports asymmetric IRB mode,
then the receiving PE MUST ignore MPLS label2 field and install the then the receiving PE MUST ignore MPLS label2 field and install the
MAC address in the corresponding MAC-VRF and <IP, MAC> association in MAC address in the corresponding MAC-VRF and <IP, MAC> association in
the ARP table for that tenant (identified by the corresponding IP-VRF the ARP table for that tenant (identified by the corresponding IP-VRF
route target). route target).
3.2.3 Data Plane - Ingress PE 3.2.3 Data Plane - Ingress PE
skipping to change at page 15, line 27 skipping to change at page 15, line 27
If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's If the tunnel type is that of MPLS or IP-only NVO tunnel, then TS's
IP packet is sent over the tunnel without any Ethernet header. IP packet is sent over the tunnel without any Ethernet header.
However, if the tunnel type is that of Ethernet NVO tunnel, then an However, if the tunnel type is that of Ethernet NVO tunnel, then an
Ethernet header needs to be added to the TS's IP packet. The source Ethernet header needs to be added to the TS's IP packet. The source
MAC address of this inner Ethernet header is set to the ingress PE's MAC address of this inner Ethernet header is set to the ingress PE's
router MAC address and the destination MAC address of this inner router MAC address and the destination MAC address of this inner
Ethernet header is set to the egress PE's router MAC address. The Ethernet header is set to the egress PE's router MAC address. The
MPLS VPN label or VNI fields are set accordingly and the packet is MPLS VPN label or VNI fields are set accordingly and the packet is
forwarded to the egress PE. forwarded to the egress PE.
If case of NVO tunnel encapsulation, the outer source and destination In case of NVO tunnel encapsulation, the outer source and destination
IP addresses are set to the ingress and egress PE BGP next-hop IP IP addresses are set to the ingress and egress PE BGP next-hop IP
addresses respectively. addresses respectively.
3.2.4 Data Plane - Egress PE 3.2.4 Data Plane - Egress PE
When the tenant's MPLS or NVO encapsulated packet is received over an When the tenant's MPLS or NVO encapsulated packet is received over an
MPLS or NVO tunnel by the egress PE, the egress PE removes NVO tunnel MPLS or NVO tunnel by the egress PE, the egress PE removes NVO tunnel
encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or encapsulation and uses the VPN MPLS label (for MPLS encapsulation) or
VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup VNI (for NVO encapsulation) to identify the IP-VRF in which IP lookup
needs to be performed. If the VPN MPLS label or VNI identifies a MAC- needs to be performed. If the VPN MPLS label or VNI identifies a MAC-
skipping to change at page 16, line 8 skipping to change at page 16, line 8
destination MAC address and a source MAC address corresponding to destination MAC address and a source MAC address corresponding to
that IRB interface and sends the packet to its destination subnet that IRB interface and sends the packet to its destination subnet
MAC-VRF/BT. MAC-VRF/BT.
The destination MAC address lookup in the MAC-VRF/BT results in local The destination MAC address lookup in the MAC-VRF/BT results in local
adjacency (e.g., local interface) over which the Ethernet frame is adjacency (e.g., local interface) over which the Ethernet frame is
sent on. sent on.
3.3 Asymmetric IRB Procedures 3.3 Asymmetric IRB Procedures
3.3.1 Control Plane - Ingress PE 3.3.1 Control Plane - Advertising PE
When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of When a PE (e.g., PE1 in figure 4 above) learns MAC and IP address of
a TS (e.g., via an ARP request), it populates its MAC-VRF/BT, IP-VRF, a TS (e.g., via an ARP request), it populates its MAC-VRF/BT, IP-VRF,
and ARP table just as in the case for symmetric IRB. It then builds and ARP table just as in the case for symmetric IRB. It then builds
an EVPN MAC/IP Advertisement route (type 2) as follow and advertises an EVPN MAC/IP Advertisement route (type 2) as follow and advertises
it to other PEs participating in that tenant's VPN. it to other PEs participating in that tenant's VPN.
- The Length field of the BGP EVPN NLRI for an EVPN MAC/IP - The Length field of the BGP EVPN NLRI for an EVPN MAC/IP
Advertisement route MUST be either 37 (if IPv4 address is carried) or Advertisement route MUST be either 37 (if IPv4 address is carried) or
49 (if IPv6 address is carried). 49 (if IPv6 address is carried).
skipping to change at page 16, line 32 skipping to change at page 16, line 32
and MPLS Label1 fields MUST be set per [RFC7432] and [RFC8365]. and MPLS Label1 fields MUST be set per [RFC7432] and [RFC8365].
- The MPLS Label2 field MUST NOT be included in this route. - The MPLS Label2 field MUST NOT be included in this route.
Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length, Just as in [RFC7432], the RD, Ethernet Tag ID, MAC Address Length,
MAC Address, IP Address Length, and IP Address fields are part of MAC Address, IP Address Length, and IP Address fields are part of
the route key used by BGP to compare routes. The rest of the fields the route key used by BGP to compare routes. The rest of the fields
are not part of the route key. are not part of the route key.
This route is advertised along with the following extended This route is advertised along with the following extended
communitiy: community:
1) Tunnel Type Extended Community 1) Tunnel Type Extended Community
For asymmetric IRB mode, Router's MAC EC is not needed because For asymmetric IRB mode, Router's MAC EC is not needed because
forwarding is performed using destination TS's MAC address which is forwarding is performed using destination TS's MAC address which is
carried in this EVPN route type-2 advertisement. carried in this EVPN route type-2 advertisement.
This route MUST always be advertised with the MAC-VRF route target. This route MUST always be advertised with the MAC-VRF route target.
It MAY also be advertised with a second route target corresponding to It MAY also be advertised with a second route target corresponding to
the IP-VRF. If only MAC-VRF route target is used, then the receiving the IP-VRF. If only MAC-VRF route target is used, then the receiving
PE uses the MAC-VRF route target to identify the corresponding IP-VRF PE uses the MAC-VRF route target to identify the corresponding IP-VRF
- i.e., many MAC-VRF route targets map to the same IP-VRF for a given - i.e., many MAC-VRF route targets map to the same IP-VRF for a given
tenant. Since in this asymmetric IRB mode, each PE is configured with tenant. Since in this asymmetric IRB mode, each PE is configured with
every BD for a tenant, the MAC-VRF route target has the same all VLANs of a tenant, the MAC-VRF route target has the same
reachability as the IP-VRF route target and that is why the use of reachability as the IP-VRF route target and that is why the use of
IP-VRF route target is optional for this IRB mode. IP-VRF route target is optional for this IRB mode.
3.3.2 Control Plane - Egress PE 3.3.2 Control Plane - Receiving PE
When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP When a PE (e.g., PE2 in figure 4 above) receives this EVPN MAC/IP
Advertisement route advertisement, it performs the following: Advertisement route advertisement, it performs the following:
- Using MAC-VRF route target, it identifies the corresponding MAC-VRF - Using MAC-VRF route target, it identifies the corresponding MAC-VRF
and imports the MAC address into it. For asymmetric IRB mode, it is and imports the MAC address into it. For asymmetric IRB mode, it is
assumed that all PEs participating in a tenant's VPN are configured assumed that all PEs participating in a tenant's VPN are configured
with all subnets and corresponding MAC-VRFs/BTs even if there are no with all subnets (i.e., all VLANs) and corresponding MAC-VRFs/BTs
locally attached TSes for some of these subnets. The reason for this even if there are no locally attached TSes for some of these subnets.
is because ingress PE needs to do forwarding based on destination The reason for this is because ingress PE needs to do forwarding
TS's MAC address and does proper NVO tunnel encapsulation which are based on destination TS's MAC address and does proper NVO tunnel
property of a lookup in MAC-VRF/BT. An implementation may choose to encapsulation which are property of a lookup in MAC-VRF/BT. An
consolidate the lookup at the ingress PE's IP-VRF with the lookup at implementation may choose to consolidate the lookup at the ingress
the ingress PE's destination subnet MAC-VRF. Consideration for such PE's IP-VRF with the lookup at the ingress PE's destination subnet
consolidation of lookups is an implementation exercise and thus its MAC-VRF. Consideration for such consolidation of lookups is an
specification is outside the scope of this document. implementation exercise and thus its specification is outside the
scope of this document.
- Using MAC-VRF route target, it identifies the corresponding ARP - Using MAC-VRF route target, it identifies the corresponding ARP
table for the tenant and it adds an entry to the ARP table for the table for the tenant and it adds an entry to the ARP table for the
TS's MAC and IP address association. It should be noted that the TS's MAC and IP address association. It should be noted that the
tenant's ARP table at the receiving PE is identified by all the MAC- tenant's ARP table at the receiving PE is identified by all the MAC-
VRF route targets for that tenant. If IP-VRF route target is included VRF route targets for that tenant. If IP-VRF route target is included
with this route advertisement, then it MAY be used for the with this route advertisement, then it MAY be used for the
identification of tenant's ARP table. identification of tenant's ARP table.
If the receiving PE receives the MAC/IP Advertisement route with MPLS If the receiving PE receives the MAC/IP Advertisement route with MPLS
label2 field but the receiving PE only supports asymmetric IRB mode, label2 field but the receiving PE only supports asymmetric IRB mode,
then the receiving PE MUST ignore MPLS label2 field and install the then the receiving PE MUST ignore MPLS label2 field and install the
MAC address in the corresponding MAC-VRF and <IP, MAC> association in MAC address in the corresponding MAC-VRF and <IP, MAC> association in
the ARP table for that tenant (identified by either MAC-VRF or IP-VRF the ARP table for that tenant (identified by either MAC-VRF or IP-VRF
route targets). route target).
If the receiving PE receives the MAC/IP Advertisement route with MPLS If the receiving PE receives the MAC/IP Advertisement route with MPLS
label2 field and it can support symmetric IRB mode, then it should label2 field and it can support symmetric IRB mode, then it should
use the MAC-VRF route target to identify its corresponding MAC-VRF use the MAC-VRF route target to identify its corresponding MAC-VRF
table and import the MAC address. It should use the IP-VRF route table and import the MAC address. It should use the IP-VRF route
target to identify the corresponding IP-VRF table and import the IP target to identify the corresponding IP-VRF table and import the IP
address. It MUST not import <IP, MAC> association into its ARP address. It MUST not import <IP, MAC> association into its ARP
table. table.
3.3.3 Data Plane - Ingress PE 3.3.3 Data Plane - Ingress PE
skipping to change at page 19, line 18 skipping to change at page 19, line 18
mobility procedures for L2-only services for both single-homed TS and mobility procedures for L2-only services for both single-homed TS and
multi-homed TS. This section describes the incremental procedures and multi-homed TS. This section describes the incremental procedures and
BGP Extended Communities needed to handle the MAC mobility for IRB. BGP Extended Communities needed to handle the MAC mobility for IRB.
In order to place the emphasis on the differences between L2-only and In order to place the emphasis on the differences between L2-only and
IRB use cases, the incremental procedure is described for single- IRB use cases, the incremental procedure is described for single-
homed TS with the expectation that the reader can easily extrapolate homed TS with the expectation that the reader can easily extrapolate
multi-homed TS based on the procedures described in section 15 of multi-homed TS based on the procedures described in section 15 of
[RFC7432]. This section describes mobility procedures for both [RFC7432]. This section describes mobility procedures for both
symmetric and asymmetric IRB. symmetric and asymmetric IRB.
4.1 Mobility Procedure for Symmetric IRB
When a TS moves from a source NVE to a target NVE, it can behave in When a TS moves from a source NVE to a target NVE, it can behave in
one of the following three ways: one of the following three ways:
1) TS initiates an ARP request upon a move to the target NVE 1) TS initiates an ARP request upon a move to the target NVE
2) TS sends data packet without first initiating an ARP request to 2) TS sends data packet without first initiating an ARP request to
the target NVE the target NVE
3) TS is a silent host and neither initiates an ARP request nor sends 3) TS is a silent host and neither initiates an ARP request nor sends
any packets any packets
skipping to change at page 19, line 41 skipping to change at page 19, line 39
The following subsections describe the procedures for each of the The following subsections describe the procedures for each of the
above options. In the following subsections, it is assumed that the above options. In the following subsections, it is assumed that the
MAC & IP addresses of a TS have one-to-one relationship (i.e., there MAC & IP addresses of a TS have one-to-one relationship (i.e., there
is one IP address per MAC address and vise versa). If such there is is one IP address per MAC address and vise versa). If such there is
many-to-one relationship such that there are many host IP addresses many-to-one relationship such that there are many host IP addresses
correspond to a single host MAC address or there are many host MAC correspond to a single host MAC address or there are many host MAC
addresses correspond to a single IP address, then to detect host addresses correspond to a single IP address, then to detect host
mobility, the procedures in [IRB-EXT-MOBILITY] must be exercised mobility, the procedures in [IRB-EXT-MOBILITY] must be exercised
followed by the procedures described below. followed by the procedures described below.
4.1.1 Initiating an ARP Request upon a Move 4.1 Initiating an ARP Request upon a Move
In this scenario when a TS moves from a source NVE to a target NVE, In this scenario when a TS moves from a source NVE to a target NVE,
the TS initiates an ARP request upon the move (e.g., gratuitous ARP) the TS initiates an ARP request upon the move (e.g., gratuitous ARP)
to the target NVE. to the target NVE.
The target NVE upon receiving this ARP request, updates its MAC-VRF, The target NVE upon receiving this ARP request, updates its MAC-VRF,
IP-VRF, and ARP table with the host MAC, IP, and local adjacency IP-VRF, and ARP table with the host MAC, IP, and local adjacency
information (e.g., local interface). information (e.g., local interface).
Since this NVE has previously learned the same MAC and IP addresses Since this NVE has previously learned the same MAC and IP addresses
from the source NVE, it recognizes that there has been a MAC move and from the source NVE, it recognizes that there has been a MAC move and
it initiates MAC mobility procedures per [RFC7432] by advertising an it initiates MAC mobility procedures per [RFC7432] by advertising an
EVPN MAC/IP route with both the MAC and IP addresses filled in along EVPN MAC/IP route with both the MAC and IP addresses filled in (per
with MAC Mobility Extended Community with the sequence number sections 3.2.1 and 3.3.1) along with MAC Mobility Extended Community
incremented by one. The target NVE also exercises the MAC duplication with the sequence number incremented by one. The target NVE also
detection procedure in section 15.1 of [RFC 7432]. exercises the MAC duplication detection procedure in section 15.1 of
[RFC 7432].
The source NVE upon receiving this MAC/IP advertisement, realizes The source NVE upon receiving this MAC/IP advertisement, realizes
that the MAC has moved to the target NVE. It updates its MAC-VRF and that the MAC has moved to the target NVE. It updates its MAC-VRF and
IP-VRF table accordingly with the adjacency information of the target IP-VRF table accordingly with the adjacency information of the target
NVE and withdraws its EVPN MAC/IP route. Furthermore, it sends an ARP NVE. In case of the asymmetric IRB, the source NVE also updates its
probe locally to ensure that the MAC is gone. After no ARP response ARP table with the received adjacency information and in case of the
is received, it then deletes its ARP entry corresponding to that <IP, symmetric IRB, the source NVE removes the entry associated with the
MAC>. If an ARP response is received, the source NVE updates its ARP received <MAC, IP> from its local ARP table. It then withdraws its
entry timer for that <IP, MAC> and re-advertises an EVPN MAC/IP route EVPN MAC/IP route. Furthermore, it sends an ARP probe locally to
for that <IP, MAC> along with MAC Mobility Extended Community with ensure that the MAC is gone. If an ARP response is received, the
the sequence number incremented by one. The source NVE also exercises source NVE updates its ARP entry for that <IP, MAC> and re-advertises
the MAC duplication detection procedure in section 15.1 of [RFC an EVPN MAC/IP route for that <IP, MAC> along with MAC Mobility
7432]. Extended Community with the sequence number incremented by one. The
source NVE also exercises the MAC duplication detection procedure in
section 15.1 of [RFC 7432].
All other remote NVE devices upon receiving the MAC/IP advertisement All other remote NVE devices upon receiving the MAC/IP advertisement
route with MAC Mobility extended community compare the sequence route with MAC Mobility extended community compare the sequence
number in this advertisement with the one previously received. If the number in this advertisement with the one previously received. If the
new sequence number is greater than the old one, then they update the new sequence number is greater than the old one, then they update the
MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF
tables to point to the target NVE. Furthermore, upon receiving the tables to point to the target NVE. Furthermore, upon receiving the
MAC/IP withdraw for the TS from the source NVE, these remote PEs MAC/IP withdraw for the TS from the source NVE, these remote PEs
perform the cleanups for their BGP tables. perform the cleanups for their BGP tables.
4.1.2 Sending Data Traffic without an ARP Request 4.2 Sending Data Traffic without an ARP Request
In this scenario when a TS moves from a source NVE to a target NVE, In this scenario when a TS moves from a source NVE to a target NVE,
the TS starts sending data traffic without first initiating an ARP the TS starts sending data traffic without first initiating an ARP
request. request.
The target NVE upon receiving the first data packet, it learns the The target NVE upon receiving the first data packet, it learns the
MAC address of the TS in data plane and updates its MAC-VRF table MAC address of the TS in data plane and updates its MAC-VRF table
with the MAC address and the local adjacency information (e.g., local with the MAC address and the local adjacency information (e.g., local
interface) accordingly. The target NVE realizes that there has been a interface) accordingly. The target NVE realizes that there has been a
MAC move because the same MAC address has been learned remotely from MAC move because the same MAC address has been learned remotely from
skipping to change at page 21, line 22 skipping to change at page 21, line 23
accordingly by updating the adjacency information for that MAC accordingly by updating the adjacency information for that MAC
address to point to the target NVE and withdraws its EVPN MAC/IP address to point to the target NVE and withdraws its EVPN MAC/IP
route that has only the MAC address (if it has advertised such route route that has only the MAC address (if it has advertised such route
previously). Furthermore, it searches its ARP table for this MAC and previously). Furthermore, it searches its ARP table for this MAC and
sends an ARP probe for this <MAC,IP> pair. The ARP request message is sends an ARP probe for this <MAC,IP> pair. The ARP request message is
sent both locally to all attached TSes in that subnet as well as it sent both locally to all attached TSes in that subnet as well as it
is sent to other NVEs participating in that subnet including the is sent to other NVEs participating in that subnet including the
target NVE. target NVE.
- The target NVE passes the ARP request to its locally attached TSes - The target NVE passes the ARP request to its locally attached TSes
and when it receives the ARP response, it sends an EVPN MAC/IP and when it receives the ARP response, it updates its IP-VRF and ARP
advertisement route with both the MAC and IP addresses filled in table with the host <MAC, IP> information. It also sends an EVPN
along with MAC Mobility Extended Community with the sequence number MAC/IP advertisement route with both the MAC and IP addresses filled
set to the same value as the one for MAC-only advertisement route it in along with MAC Mobility Extended Community with the sequence
sent previously. number set to the same value as the one for MAC-only advertisement
route it sent previously.
- When the source NVE receives the EVPN MAC/IP advertisement, it - When the source NVE receives the EVPN MAC/IP advertisement, it
updates its IP-VRF table with the new adjacency information updates its IP-VRF table with the new adjacency information
(pointing to the target NVE) and deletes the associated ARP entry (pointing to the target NVE). In case of the asymmetric IRB, the
from its ARP table. Furthermore, it withdraws its previously source NVE also updates its ARP table with the received adjacency
advertised EVPN MAC/IP route with both the MAC and IP addresses. information and in case of the symmetric IRB, the source NVE removes
the entry associated with the received <MAC, IP> from its local ARP
table. Furthermore, it withdraws its previously advertised EVPN
MAC/IP route with both the MAC and IP address fields filled in.
- All other remote NVE devices upon receiving the MAC/IP - All other remote NVE devices upon receiving the MAC/IP
advertisement route with MAC Mobility extended community compare the advertisement route with MAC Mobility extended community compare the
sequence number in this advertisement with the one previously sequence number in this advertisement with the one previously
received. If the new sequence number is greater than the old one, received. If the new sequence number is greater than the old one,
then they update the MAC/IP addresses of the TS in their then they update the MAC/IP addresses of the TS in their
corresponding MAC-VRF and IP-VRF tables to point to the new NVE. corresponding MAC-VRF and IP-VRF tables to point to the new NVE.
Furthermore, upon receiving the MAC/IP withdraw for the TS from the Furthermore, upon receiving the MAC/IP withdraw for the TS from the
old NVE, these remote PEs perform the cleanups for their BGP tables. old NVE, these remote PEs perform the cleanups for their BGP tables.
skipping to change at page 21, line 47 skipping to change at page 22, line 4
received. If the new sequence number is greater than the old one, received. If the new sequence number is greater than the old one,
then they update the MAC/IP addresses of the TS in their then they update the MAC/IP addresses of the TS in their
corresponding MAC-VRF and IP-VRF tables to point to the new NVE. corresponding MAC-VRF and IP-VRF tables to point to the new NVE.
Furthermore, upon receiving the MAC/IP withdraw for the TS from the Furthermore, upon receiving the MAC/IP withdraw for the TS from the
old NVE, these remote PEs perform the cleanups for their BGP tables. old NVE, these remote PEs perform the cleanups for their BGP tables.
If EVPN-IRB NVEs are configured not to advertise MAC-only routes, If EVPN-IRB NVEs are configured not to advertise MAC-only routes,
then upon receiving the first data packet, it learns the MAC address then upon receiving the first data packet, it learns the MAC address
of the TS and updates the MAC entry in the corresponding MAC-VRF of the TS and updates the MAC entry in the corresponding MAC-VRF
table with the local adjacency information (e.g., local interface). table with the local adjacency information (e.g., local interface).
It also realizes that there has been a MAC move because the same MAC It also realizes that there has been a MAC move because the same MAC
address has been learned remotely from the source NVE. It then sends address has been learned remotely from the source NVE. It then sends
an unicast ARP request to the host and when receiving an ARP an unicast ARP request to the host and when receiving an ARP
response, it follows the procedure outlined in section 4.1.1. response, it follows the procedure outlined in section 4.1.
4.1.3 Silent Host 4.3 Silent Host
In this scenario when a TS moves from a source NVE to a target NVE, In this scenario when a TS moves from a source NVE to a target NVE,
the TS is silent and it neither initiates an ARP request nor it sends the TS is silent and it neither initiates an ARP request nor it sends
any data traffic. Therefore, neither the target nor the source NVEs any data traffic. Therefore, neither the target nor the source NVEs
are aware of the MAC move. are aware of the MAC move.
On the source NVE, the MAC age-out timer (for the silent host that On the source NVE, the MAC age-out timer (for the silent host that
has moved) expires and as the result it triggers an ARP probe on the has moved) expires and as the result it triggers an ARP probe on the
source NVE. The ARP request gets sent both locally to all the source NVE. The ARP request gets sent both locally to all the
attached TSes on that subnet as well as it gets sent to all the attached TSes on that subnet as well as it gets sent to all the
remote NVEs (including the target NVE) participating in that subnet. remote NVEs (including the target NVE) participating in that subnet.
It also withdraw the EVPN MAC/IP route with only the MAC address (if It also withdraw the EVPN MAC/IP route with only the MAC address (if
it has previously advertised such a route). it has previously advertised such a route).
The target NVE passes the ARP request to its locally attached TSes The target NVE passes the ARP request to its locally attached TSes
and when it receives the ARP response, it sends an EVPN MAC/IP and when it receives the ARP response, it updates its MAC-VRF, IP-
advertisement route with both the MAC and IP addresses filled in VRF, and ARP table with the host <MAC, IP> and local adjacency
information (e.g., local interface). It also sends an EVPN MAC/IP
advertisement route with both the MAC and IP address fields filled in
along with MAC Mobility Extended Community with the sequence number along with MAC Mobility Extended Community with the sequence number
incremented by one. incremented by one.
When the source NVE receives the EVPN MAC/IP advertisement, it When the source NVE receives the EVPN MAC/IP advertisement, it
updates its IP-VRF table with the new adjacency information updates its IP-VRF table with the new adjacency information
(pointing to the target NVE) and deletes the associated ARP entry (pointing to the target NVE). In case of the asymmetric IRB, the
from its ARP table. Furthermore, it withdraws its previously source NVE also updates its ARP table with the received adjacency
advertised EVPN MAC/IP route with both the MAC and IP addresses. information and in case of the symmetric IRB, the source NVE removes
the entry associated with the received <MAC, IP> from its local ARP
table. Furthermore, it withdraws its previously advertised EVPN
MAC/IP route with both the MAC and IP address fields filled in.
All other remote NVE devices upon receiving the MAC/IP advertisement All other remote NVE devices upon receiving the MAC/IP advertisement
route with MAC Mobility extended community compare the sequence route with MAC Mobility extended community compare the sequence
number in this advertisement with the one previously received. If the number in this advertisement with the one previously received. If the
new sequence number is greater than the old one, then they update the new sequence number is greater than the old one, then they update the
MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF MAC/IP addresses of the TS in their corresponding MAC-VRF and IP-VRF
tables to point to the new NVE. Furthermore, upon receiving the tables to point to the new NVE. Furthermore, upon receiving the
MAC/IP withdraw for the TS from the old NVE, these remote PEs perform MAC/IP withdraw for the TS from the old NVE, these remote PEs perform
the cleanups for their BGP tables. the cleanups for their BGP tables.
skipping to change at page 28, line 44 skipping to change at page 29, line 35
6.2.1 Control Plane Operation 6.2.1 Control Plane Operation
Each NVE advertises a Route Type-5 (RT-5, IP Prefix Route defined in Each NVE advertises a Route Type-5 (RT-5, IP Prefix Route defined in
[EVPN-PREFIX]) for each of its subnet prefixes with the IP address of [EVPN-PREFIX]) for each of its subnet prefixes with the IP address of
its TS as the next hop (gateway address field) as follow: its TS as the next hop (gateway address field) as follow:
- RD associated with the IP-VRF - RD associated with the IP-VRF
- ESI = 0 - ESI = 0
- Ethernet Tag = 0; - Ethernet Tag = 0;
- IP Prefix Length = 32 or 128 - IP Prefix Length = 0 to 32 or 0 to 128
- IP Prefix = SNi - IP Prefix = SNi
- Gateway Address = IPi; IP address of TS - Gateway Address = IPi; IP address of TS
- Label = 0 - Label = 0
This RT-5 is advertised with one or more Route Targets that have been This RT-5 is advertised with one or more Route Targets that have been
configured as "export route targets" of the IP-VRF from which the configured as "export route targets" of the IP-VRF from which the
route is originated. route is originated.
Each NVE also advertises an RT-2 (MAC/IP Advertisement Route) along Each NVE also advertises an RT-2 (MAC/IP Advertisement Route) along
with their associated Route Targets and Extended Communities for each with their associated Route Targets and Extended Communities for each
of its TSes exactly as described in section 6.1.1. of its TSes exactly as described in section 6.1.1.
Upon receiving the RT-5 advertisement, the receiving NVE performs the Upon receiving the RT-5 advertisement, the receiving NVE performs the
following: following:
skipping to change at page 30, line 29 skipping to change at page 31, line 16
- The IP packet is encapsulated with an Ethernet header with the MAC - The IP packet is encapsulated with an Ethernet header with the MAC
SA set to that of the access-facing IRB interface of the egress NVE SA set to that of the access-facing IRB interface of the egress NVE
(NVE2) and the MAC DA is set to that of destination TS (TS3) MAC (NVE2) and the MAC DA is set to that of destination TS (TS3) MAC
address. The packet is sent to the corresponding MAC-VRF3 and after a address. The packet is sent to the corresponding MAC-VRF3 and after a
lookup of MAC DA, is forwarded to the destination TS (TS3) over the lookup of MAC DA, is forwarded to the destination TS (TS3) over the
corresponding interface. corresponding interface.
7 Acknowledgements 7 Acknowledgements
The authors would like to thank Sami Boutros, Jeffrey Zhang, The authors would like to thank Sami Boutros, Jeffrey Zhang,
Krzysztof Szarkowicz, and Neeraj Malhotra for their valuable Krzysztof Szarkowicz, Lukas Krattiger and Neeraj Malhotra for their
comments. The authors would also like to thank Linda Dunbar for her valuable comments. The authors would also like to thank Linda Dunbar
engaging discussions. for her engaging discussions.
8 Security Considerations 8 Security Considerations
This document describes a set of procedures for Inter-Subnet This document describes a set of procedures for Inter-Subnet
Forwarding of tenant traffic across PEs (or NVEs). These procedures Forwarding of tenant traffic across PEs (or NVEs). These procedures
include both layer-2 forwarding and layer-3 routing on a packet by include both layer-2 forwarding and layer-3 routing on a packet by
packet basis. The security consideration for layer-2 forwarding in packet basis. The security consideration for layer-2 forwarding in
this document follow that of [RFC7432] for MPLS encapsulation and it this document follow that of [RFC7432] for MPLS encapsulation and it
follows that of [RFC8365] for VxLAN or GENEVE encapsulations. follows that of [RFC8365] for VxLAN or GENEVE encapsulations.
 End of changes. 45 change blocks. 
108 lines changed or deleted 120 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/