draft-ietf-bess-evpn-irb-extended-mobility-00.txt   draft-ietf-bess-evpn-irb-extended-mobility-01.txt 
BESS Working Group N. Malhotra, Ed. BESS Working Group N. Malhotra, Ed.
INTERNET-DRAFT Arrcus INTERNET-DRAFT Arrcus
Intended Status: Proposed Standard A. Sajassi Intended Status: Proposed Standard A. Sajassi
A. Pattekar A. Pattekar
(Cisco) Cisco
A. Lingala A. Lingala
AT&T AT&T
J. Rabadan J. Rabadan
Nokia Nokia
J. Drake J. Drake
Juniper Networks Juniper Networks
Expires: Sept 28, 2019 March 27, 2019 Expires: Dec 21, 2019 June 19, 2019
Extended Mobility Procedures for EVPN-IRB Extended Mobility Procedures for EVPN-IRB
draft-ietf-bess-evpn-irb-extended-mobility-00 draft-ietf-bess-evpn-irb-extended-mobility-01
Abstract Abstract
The procedure to handle host mobility in a layer 2 Network with EVPN Procedure to handle host mobility in a layer 2 Network with EVPN
control plane is defined as part of RFC 7432. EVPN has since evolved control plane is defined as part of RFC 7432. EVPN has since evolved
to find wider applicability across various IRB use cases that include to find wider applicability across various IRB use cases that include
distributing both MAC and IP reachability via a common EVPN control distributing both MAC and IP reachability via a common EVPN control
plane. MAC Mobility procedures defined in RFC 7432 are extensible to plane. MAC Mobility procedures defined in RFC 7432 are extensible to
IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed
across VM moves. Generic mobility support for IP and MAC that allows across VM moves. Generic mobility support for IP and MAC that allows
these bindings to change across moves is required to support a these bindings to change across moves is required to support a
broader set of EVPN IRB use cases, and requires further broader set of EVPN IRB use cases, and requires further
consideration. EVPN all-active multi-homing further introduces consideration. EVPN all-active multi-homing further introduces
scenarios that require additional consideration from mobility scenarios that require additional consideration from mobility
perspective. Intent of this draft is to enumerate a set of design perspective. This document enumerates a set of design considerations
considerations applicable to mobility across EVPN IRB use cases and applicable to mobility across these EVPN IRB use cases and defines
define generic sequence number assignment procedures to address these generic sequence number assignment procedures to address these IRB
IRB use cases. use cases.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 36 skipping to change at page 2, line 36
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Optional MAC only RT-2 . . . . . . . . . . . . . . . . . . . . 5 2. Optional MAC only RT-2 . . . . . . . . . . . . . . . . . . . . 6
3. Mobility Use Cases . . . . . . . . . . . . . . . . . . . . . . 6 3. Mobility Use Cases . . . . . . . . . . . . . . . . . . . . . . 6
3.1 VM MAC+IP Move . . . . . . . . . . . . . . . . . . . . . . 6 3.1 Host MAC+IP Move . . . . . . . . . . . . . . . . . . . . . 6
3.2 VM IP Move to new MAC . . . . . . . . . . . . . . . . . . . 6 3.2 Host IP Move to new MAC . . . . . . . . . . . . . . . . . . 6
3.2.1 VM Reload . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1 VM Reload . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . 6 3.2.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 VM MAC move to new IP . . . . . . . . . . . . . . . . . . . 8 3.3 Host MAC move to new IP . . . . . . . . . . . . . . . . . . 8
3.3.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1 Problem . . . . . . . . . . . . . . . . . . . . . . . . 8
4. EVPN All Active multi-homed ES . . . . . . . . . . . . . . . . 10 4. EVPN All Active multi-homed ES . . . . . . . . . . . . . . . . 11
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 11 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
6. Solution Components . . . . . . . . . . . . . . . . . . . . . 12 6. Solution Components . . . . . . . . . . . . . . . . . . . . . 13
6.1 Sequence Number Inheritance . . . . . . . . . . . . . . . . 12 6.1 Sequence Number Inheritance . . . . . . . . . . . . . . . . 13
6.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . . . 13 6.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3 Multi-homing Mobility Synchronization . . . . . . . . . . . 14 6.3 Multi-homing Mobility Synchronization . . . . . . . . . . . 15
7. Requirements for Sequence Number Assignment . . . . . . . . . 14 7. Requirements for Sequence Number Assignment . . . . . . . . . 15
7.1 LOCAL MAC-IP learning . . . . . . . . . . . . . . . . . . . 14 7.1 LOCAL MAC-IP learning . . . . . . . . . . . . . . . . . . . 15
7.2 LOCAL MAC learning . . . . . . . . . . . . . . . . . . . . 15 7.2 LOCAL MAC learning . . . . . . . . . . . . . . . . . . . . 16
7.3 Remote MAC OR MAC-IP Update . . . . . . . . . . . . . . . . 15 7.3 Remote MAC OR MAC-IP Update . . . . . . . . . . . . . . . . 16
7.4 REMOTE (SYNC) MAC update . . . . . . . . . . . . . . . . . 15 7.4 REMOTE (SYNC) MAC update . . . . . . . . . . . . . . . . . 16
7.5 REMOTE (SYNC) MAC-IP update . . . . . . . . . . . . . . . . 16 7.5 REMOTE (SYNC) MAC-IP update . . . . . . . . . . . . . . . . 17
7.6 Inter-op . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.6 Inter-op . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. Routed Overlay . . . . . . . . . . . . . . . . . . . . . . . . 16 7.7 MAC Sharing Race Condition . . . . . . . . . . . . . . . . 18
9. Duplicate Host Detection . . . . . . . . . . . . . . . . . . . 18 8. Routed Overlay . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1 Scenario A . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Duplicate Host Detection . . . . . . . . . . . . . . . . . . . 19
9.2 Scenario B . . . . . . . . . . . . . . . . . . . . . . . . . 18 9.1 Scenario A . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2.1 Duplicate IP Detection Procedure for Scenario B . . . . 19 9.2 Scenario B . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.3 Scenario C . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2.1 Duplicate IP Detection Procedure for Scenario B . . . . 20
9.4 Duplicate Host Recovery . . . . . . . . . . . . . . . . . . 20 9.3 Scenario C . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.4.1 Route Un-freezing Configuration . . . . . . . . . . . . 20 9.4 Duplicate Host Recovery . . . . . . . . . . . . . . . . . . 21
9.4.2 Route Clearing Configuration . . . . . . . . . . . . . 21 9.4.1 Route Un-freezing Configuration . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9.4.2 Route Clearing Configuration . . . . . . . . . . . . . 22
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
12.1 Normative References . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
12.2 Informative References . . . . . . . . . . . . . . . . . . 22 12.1 Normative References . . . . . . . . . . . . . . . . . . . 23
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 12.2 Informative References . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1 Introduction 1 Introduction
EVPN-IRB enables capability to advertise both MAC and IP routes via a EVPN-IRB enables capability to advertise both MAC and IP routes via a
single MAC+IP RT-2 advertisement. MAC is imported into local bridge single MAC+IP RT-2 advertisement. MAC is imported into local bridge
MAC table and enables L2 bridged traffic across the network overlay. MAC table and enables L2 bridged traffic across the network overlay.
IP is imported into the local ARP table in an asymmetric IRB design IP is imported into the local ARP table in an asymmetric IRB design
OR imported into the IP routing table in a symmetric IRB design, and OR imported into the IP routing table in a symmetric IRB design, and
enables routed traffic across the layer 2 network overlay. Please enables routed traffic across the layer 2 network overlay. Please
refer to [EVPN-INTER-SUBNET] more background on EVPN IRB forwarding refer to [EVPN-IRB] for more background on EVPN IRB forwarding modes.
modes.
To support EVPN mobility procedure, a single sequence number mobility To support EVPN mobility procedure, a single sequence number mobility
attribute is advertised with the combined MAC+IP route. A single attribute is advertised with the combined MAC+IP route. A single
sequence number advertised with the combined MAC+IP route to resolve sequence number advertised with the combined MAC+IP route to resolve
both MAC and IP reachability implicitly assumes a 1:1 fixed mapping both MAC and IP reachability implicitly assumes a 1:1 fixed mapping
between IP and MAC. While a fixed 1:1 mapping between IP and MAC is a between IP and MAC. While a fixed 1:1 mapping between IP and MAC is a
common use case that could be addressed via existing MAC mobility common use case that could be addressed via existing MAC mobility
procedure, additional IRB scenarios need to be considered, that don't procedure, additional IRB scenarios need to be considered, that don't
necessarily adhere to this assumption. Following IRB mobility necessarily adhere to this assumption. Following IRB mobility
scenarios are considered: scenarios are considered:
skipping to change at page 5, line 24 skipping to change at page 5, line 24
o Asymmetric EVPN IRB overlay o Asymmetric EVPN IRB overlay
o Routed EVPN overlay o Routed EVPN overlay
1.1 Terminology 1.1 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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
o ARP is widely referred to in this document. This is simply for o EVPN-IRB: A BGP-EVPN distributed control plane based integrated
ease of reading, and as such, these references are equally routing and bridging fabric overlay discussed in [EVPN-IRB]
applicable to ND (neighbor discovery) as well. o Underlay: IP or MPLS fabric core network that provides IP or
MPLS routed reachability between EVPN PEs.
o GW: used widely in the document refers to an IRB GW that is o Overlay: VPN or service layer network consisting of EVPN PEs
doing routing and bridging between an access network and an EVPN OR VPN provider-edge (PE) switch-router devices that runs on top
enabled overlay network. of an underlay routed core.
o EVPN PE: A PE switch-router in a data-center fabric that
o RT-2: EVPN route type 2 carrying both MAC and IP reachability runs overlay BGP-EVPN control plane and connects to overlay CE
host devices. An EVPN PE may also be the first-hop layer-3
o RT-5: EVPN route type 5 carrying IP prefix reachability gateway for CE/host devices. This document refers to EVPN PE as a
logical function in a data-center fabric. This EVPN PE function
o ES: EVPN Ethernet Segment may be physically hosted on a top-of-rack switching device (ToR)
OR at layer(s) above the ToR in the Clos fabric. An EVPN PE is
typically also an IP or MPLS tunnel end-point for overlay VPN
flow
o Symmetric EVPN-IRB: An overlay fabric first-hop routing
architecture as defined in [EVPN-IRB], wherein, overlay host-to-
host routed inter-subnet flows are routed at both ingress and
egress EVPN PEs.
o Asymmetric EVPN-IRB: An overlay fabric first-hop routing
architecture as defined in [EVPN-IRB], wherein, overlay host-to-
host routed inter-subnet flows are routed and bridged at ingress
PE and bridged at egress PEs.
o ARP: Address Resolution Protocol [RFC 826]. ARP references in
this document are equally applicable to ND as well.
o ND: IPv6 Neighbor Discovery Protocol [RFC 4861].
o Ethernet-Segment: physical Ethernet or LAG port that connects an
access device to an EVPN PE, as defined in [RFC 7432].
o ESI: Ethernet Segment Identifier as defined in [RFC 7432].
o LAG: Layer-2 link-aggregation, also known as layer-2 bundle
port-channel, or bond interface.
o EVPN all-active multi-homing: PE-CE all-active multi-homing
achieved via a multi-homed layer-2 LAG interface on a CE with
member links to multiple PEs and related EVPN procedures on the
PEs.
o RT-2: EVPN route type 2 carrying both MAC and IP reachability.
o RT-5: EVPN route type 5 carrying IP prefix reachability.
o MAC-IP: IP association for a MAC, referred to in this document o MAC-IP: IP association for a MAC, referred to in this document
may be IPv4, IPv6 or both. may be IPv4, IPv6 or both.
2. Optional MAC only RT-2 2. Optional MAC only RT-2
In an EVPN IRB scenario, where a single MAC+IP RT-2 advertisement In an EVPN IRB scenario, where a single MAC+IP RT-2 advertisement
carries both IP and MAC routes, a MAC only RT-2 advertisement is carries both IP and MAC routes, a MAC only RT-2 advertisement is
redundant for host MACs that are advertised via MAC+IP RT-2. As a redundant for host MACs that are advertised via MAC+IP RT-2. As a
result, a MAC only RT-2 is an optional route that may not be result, a MAC only RT-2 is an optional route that may not be
advertised from or received at an IRB GW. This is an important advertised from or received at an EVPN PE. This is an important
consideration for mobility scenarios discussed in subsequent consideration for mobility scenarios discussed in subsequent
sections. sections.
MAC only RT-2 may still be advertised for non-IP host MACs that are MAC only RT-2 may still be advertised for non-IP host MACs that are
not advertised via MAC+IP RT-2. not advertised via MAC+IP RT-2.
3. Mobility Use Cases 3. Mobility Use Cases
This section describes the IRB mobility use cases considered in this This section describes the IRB mobility use cases considered in this
document. Procedures to address them are covered later in section 6 document. Procedures to address them are covered later in section 6
and section 7. and section 7.
o VM move results in VM IP and MAC moving together o Host move results in Host IP and MAC moving together
o VM move results in VM IP moving to a new MAC association o Host move results in Host IP moving to a new MAC association
o VM move results in VM MAC moving to a new IP association o Host move results in Host MAC moving to a new IP association
3.1 VM MAC+IP Move 3.1 Host MAC+IP Move
This is the baseline case, wherein a VM move results in both VM MAC This is the baseline case, wherein a host move results in both host
and IP moving together with no change in MAC-IP binding across a MAC and IP moving together with no change in MAC-IP binding across a
move. Existing MAC mobility defined in RFC 7432 may be leveraged to move. Existing MAC mobility defined in RFC 7432 may be leveraged to
apply to corresponding MAC+IP route to support this mobility apply to corresponding MAC+IP route to support this mobility
scenario. scenario.
3.2 VM IP Move to new MAC 3.2 Host IP Move to new MAC
This is the case, where a VM move results in VM IP moving to a new This is the case, where a host move results in VM IP moving to a new
MAC binding. MAC binding.
3.2.1 VM Reload 3.2.1 VM Reload
A VM reload or an orchestrated VM move that results in VM being re- A host reload or an orchestrated host move that results in host being
spawned at a new location may result in VM getting a new MAC re-spawned at a new location may result in host getting a new MAC
assignment, while maintaining existing IP address. This results in a assignment, while maintaining existing IP address. This results in a
VM IP move to a new MAC binding: host IP move to a new MAC binding:
IP-a, MAC-a ---> IP-a, MAC-b IP-a, MAC-a ---> IP-a, MAC-b
3.2.2 MAC Sharing 3.2.2 MAC Sharing
This takes into account scenarios, where multiple hosts, each with a This takes into account scenarios, where multiple hosts, each with a
unique IP, may share a common MAC binding, and a host move results in unique IP, may share a common MAC binding, and a host move results in
a new MAC binding for the host IP. a new MAC binding for the host IP.
As an example, host VMs running on a single physical server, each As an example, hosts running on a single physical server, each with a
with a unique IP, may share the same physical server MAC. In yet unique IP, may share the same physical server MAC. In yet another
another scenario, an L2 access network may be behind a firewall, such scenario, an L2 access network may be behind a firewall, such that
that all hosts IPs on the access network are learnt with a common all hosts IPs on the access network are learnt with a common firewall
firewall MAC. In all such "shared MAC" use cases, multiple local MAC- MAC. In all such "shared MAC" use cases, multiple local MAC-IP ARP
IP ARP entries may be learnt with the same MAC. A VM IP move, in such entries may be learnt with the same MAC. A host IP move, in such
scenarios (for e.g., to a new physical server), could result in new scenarios (for e.g., to a new physical server), could result in new
MAC association for the VM IP. MAC association for the host IP.
3.2.3 Problem 3.2.3 Problem
In both of the above scenarios, a combined MAC+IP EVPN RT-2 In both of the above scenarios, a combined MAC+IP EVPN RT-2
advertised with a single sequence number attribute implicitly assumes advertised with a single sequence number attribute implicitly assumes
a fixed IP to MAC mapping. A host IP move to a new MAC breaks this a fixed IP to MAC mapping. A host IP move to a new MAC breaks this
assumption and results in a new MAC+IP route. If this new MAC+IP assumption and results in a new MAC+IP route. If this new MAC+IP
route is independently assigned a new sequence number, the sequence route is independently assigned a new sequence number, the sequence
number can no longer be used to determine most recent host IP number can no longer be used to determine most recent host IP
reachability in a symmetric EVPN-IRB design OR the most recent IP to reachability in a symmetric EVPN-IRB design OR the most recent IP to
MAC binding in an asymmetric EVPN-IRB design. MAC binding in an asymmetric EVPN-IRB design.
+------------------------+ +------------------------+
| Underlay Network Fabric| | Underlay Network Fabric|
+------------------------+ +------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| GW1 | | GW2 | | GW3 | | GW4 | | GW5 | | GW6 | | PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ / \ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 / \ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ / \ / \ / \ /
+\---/+ +\---/+ +\---/+ +\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / | | \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
Server-MAC1 Server-MAC2 Server-MAC3 Server-MAC1 Server-MAC2 Server-MAC3
| | | | | |
[VM-IP1, VM-IP2] [VM-IP3, VM-IP4] [VM-IP5, VM-IP6] [VM-IP1, VM-IP2] [VM-IP3, VM-IP4] [VM-IP5, VM-IP6]
Figure 1 Figure 1
As an example, consider a topology shown in Figure 1, with host VMs As an example, consider a topology shown in Figure 1, with host VMs
sharing the physical server MAC. In steady state, [IP1, MAC1] route sharing the physical server MAC. In steady state, [IP1, MAC1] route
is learnt at [GW1, GW2] and advertised to remote GWs with a sequence is learnt at [PE1, PE2] and advertised to remote PEs with a sequence
number N. Now, VM-IP1 is moved to Server-MAC2. ARP or ND based local number N. Now, VM-IP1 is moved to Server-MAC2. ARP or ND based local
learning at [GW3, GW4] would now result in a new [IP1, MAC2] route learning at [PE3, PE4] would now result in a new [IP1, MAC2] route
being learnt. If route [IP1, MAC2] is learnt as a new MAC+IP route being learnt. If route [IP1, MAC2] is learnt as a new MAC+IP route
and assigned a new sequence number of say 0, mobility procedure for and assigned a new sequence number of say 0, mobility procedure for
VM-IP1 will not trigger across the overlay network. VM-IP1 will not trigger across the overlay network.
A clear sequence number assignment procedure needs to be defined to A sequence number assignment procedure needs to be defined to
unambiguously determine the most recent IP reachability, IP to MAC unambiguously determine the most recent IP reachability, IP to MAC
binding, and MAC reachability for such a MAC sharing scenario. binding, and MAC reachability for such a MAC sharing scenario.
3.3 VM MAC move to new IP 3.3 Host MAC move to new IP
This is a scenario where host move or re-provisioning behind a new This is a scenario where host move or re-provisioning behind a new
gateway location may result in the same VM MAC getting a new IP gateway location may result in host getting a new IP address
address assigned. assigned, while keeping the same MAC.
3.3.1 Problem 3.3.1 Problem
Complication with this scenario is that MAC reachability could be Complication with this scenario is that MAC reachability could be
carried via a combined MAC+IP route while a MAC only route may not be carried via a combined MAC+IP route while a MAC only route may not be
advertised at all. A single sequence number association with the advertised at all. A single sequence number association with the
MAC+IP route again implicitly assumes a fixed mapping between MAC and MAC+IP route again implicitly assumes a fixed mapping between MAC and
IP. A MAC move resulting in a new IP association for the host MAC IP. A MAC move resulting in a new IP association for the host MAC
breaks this assumption and results in a new MAC+IP route. If this new breaks this assumption and results in a new MAC+IP route. If this new
MAC+IP route independently assumes a new sequence number, this MAC+IP route independently assumes a new sequence number, this
mobility attribute can no longer be used to determine most recent mobility attribute can no longer be used to determine most recent
host MAC reachability as opposed to the older existing MAC host MAC reachability.
reachability.
+------------------------+ +------------------------+
| Underlay Network Fabric| | Underlay Network Fabric|
+------------------------+ +------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| GW1 | | GW2 | | GW3 | | GW4 | | GW5 | | GW6 | | PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ / \ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 / \ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ / \ / \ / \ /
+\---/+ +\---/+ +\---/+ +\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / | | \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
Server1 Server2 Server3 Server1 Server2 Server3
| | | | | |
[VM-IP1-M1, VM-IP2-M2] [VM-IP3-M3, VM-IP4-M4] [VM-IP5-M5, VM-IP6-M6] [VM-IP1-M1, VM-IP2-M2] [VM-IP3-M3, VM-IP4-M4] [VM-IP5-M5, VM-IP6-M6]
As an example, IP1-M1 is learnt locally at [GW1, GW2] and currently As an example, consider a host VM IP1-M1 that is learnt locally at
advertised to remote hosts with a sequence number N. Consider a [PE1, PE2] and advertised to remote hosts with a sequence number N.
scenario where a VM with MAC M1 is re-provisioned at server 2, Consider a scenario where this VM with MAC M1 is re-provisioned at
however, as part of this re-provisioning, assigned a different IP server 2, however, as part of this re-provisioning, assigned a
address say IP7. [IP7, M1] is learnt as a new route at [GW3, GW4] and different IP address say IP7. [IP7, M1] is learnt as a new route at
advertised to remote GWs with a sequence number of 0. As a result, L3 [PE3, PE4] and advertised to remote PEs with a sequence number of 0.
reachability to IP7 would be established across the overlay, however, As a result, L3 reachability to IP7 would be established across the
MAC mobility procedure for MAC1 will not trigger as a result of this overlay, however, MAC mobility procedure for MAC1 will not trigger as
MAC-IP route advertisement. If an optional MAC only route is also a result of this MAC-IP route advertisement. If an optional MAC only
advertised, sequence number associated with the MAC only route would route is also advertised, sequence number associated with the MAC
trigger MAC mobility as per [RFC7432]. However, in the absence of an only route would trigger MAC mobility as per [RFC7432]. However, in
additional MAC only route advertisement, a single sequence number the absence of an additional MAC only route advertisement, a single
advertised with a combined MAC+IP route would not be sufficient to sequence number advertised with a combined MAC+IP route would not be
update MAC reachability across the overlay. sufficient to update MAC reachability across the overlay.
A MAC-IP sequence number assignment procedure needs to be defined to A MAC-IP sequence number assignment procedure needs to be defined to
unambiguously determine the most recent MAC reachability in such a unambiguously determine the most recent MAC reachability in such a
scenario without a MAC only route being advertised. scenario without a MAC only route being advertised.
Further, GW1/GW2, on learning new reachability for [IP7, M1] via Further, PE1/PE2, on learning new reachability for [IP7, M1] via
GW3/GW4 MUST probe and delete any local IPs associated with MAC M1, PE3/PE4 MUST probe and delete any local IPs associated with MAC M1,
such as [IP1, M1] in the above example. such as [IP1, M1] in the above example.
Arguably, MAC mobility sequence number defined in [RFC7432], could be Arguably, MAC mobility sequence number defined in [RFC7432], could be
interpreted to apply only to the MAC part of MAC-IP route, and would interpreted to apply only to the MAC part of MAC-IP route, and would
hence cover this scenario. It could hence be interpreted as a hence cover this scenario. It could hence be interpreted as a
clarification to [RFC7432] and one of the considerations for a common clarification to [RFC7432] and one of the considerations for a common
sequence number assignment procedure across all MAC-IP mobility sequence number assignment procedure across all MAC-IP mobility
scenarios detailed in this document. scenarios detailed in this document.
4. EVPN All Active multi-homed ES 4. EVPN All Active multi-homed ES
+------------------------+ +------------------------+
| Underlay Network Fabric| | Underlay Network Fabric|
+------------------------+ +------------------------+
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| GW1 | | GW2 | | GW3 | | GW4 | | GW5 | | GW6 | | PE1 | | PE2 | | PE3 | | PE4 | | PE5 | | PE6 |
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
\ / \ / \ / \ / \ / \ /
\ ESI-1 / \ ESI-2 / \ ESI-3 / \ ESI-1 / \ ESI-2 / \ ESI-3 /
\ / \ / \ / \ / \ / \ /
+\---/+ +\---/+ +\---/+ +\---/+ +\---/+ +\---/+
| \ / | | \ / | | \ / | | \ / | | \ / | | \ / |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
Server-1 Server-2 Server-3 Server-1 Server-2 Server-3
Figure 2 Figure 2
Consider an EVPN-IRB overlay network shown in Figure 2, with hosts Consider an EVPN-IRB overlay network shown in Figure 2, with hosts
multi-homed to two or more leaf GW devices via an all-active multi- multi-homed to two or more PE devices via an all-active multi-homed
homed ES. MAC and ARP entries learnt on a local ESI may also be ES. MAC and ARP entries learnt on a local ES may also be synchronized
synchronized across the multi-homing GW devices sharing this ESI. across the multi-homing PE devices sharing this ES. This MAC and ARP
This MAC and ARP SYNC enables local switching of intra and inter SYNC enables local switching of intra and inter subnet ECMP traffic
subnet ECMP traffic flows from remote hosts. In other words, local flows from remote hosts. In other words, local MAC and ARP entries on
MAC and ARP entries on a given Ethernet segment (ES) may be learnt a given ES may be learnt via local learning and / or via sync from
via local learning and / or sync from another GW device sharing the another PE device sharing the same ES.
same ES.
For a host that is multi-homed to multiple GW devices via an all- For a host that is multi-homed to multiple PE devices via an all-
active ES interface, local learning of host MAC and MAC-IP at each GW active ES interface, local learning of host MAC and MAC-IP at each PE
device is an independent asynchronous event, that is dependent on device is an independent asynchronous event, that is dependent on
traffic flow and or ARP / ND response from the host hashing to a traffic flow and or ARP / ND response from the host hashing to a
directly connected GW on the MC-LAG interface. As a result, sequence directly connected PE on the MC-LAG interface. As a result, sequence
number mobility attribute value assigned to a locally learnt MAC or number mobility attribute value assigned to a locally learnt MAC or
MAC-IP route (as per RFC 7432) at each device may not always be the MAC-IP route at each device may not always be the same, depending on
same, depending on transient states on the device at the time of transient states on the device at the time of local learning.
local learning.
As an example, consider a host VM that is deleted from ESI-2 and As an example, consider a host VM that is deleted from ESI-2 and
moved to ESI-1. It is possible for host to be learnt on say, GW1 moved to ESI-1. It is possible for host to be learnt on say, PE1
following deletion of the remote route from [GW3, GW4], while being following deletion of the remote route from [PE3, PE4], while being
learnt on GW2 prior to deletion of remote route from [GW3, GW4]. If learnt on PE2 prior to deletion of remote route from [PE3, PE4]. If
so, GW1 would process local host route learning as a new route and so, PE1 would process local host route learning as a new route and
assign a sequence number of 0, while GW2 would process local host assign a sequence number of 0, while PE2 would process local host
route learning as a remote to local move and assign a sequence number route learning as a remote to local move and assign a sequence number
of N+1, N being the existing sequence number assigned at [GW3, GW4]. of N+1, N being the existing sequence number assigned at [PE3, PE4].
Inconsistent sequence numbers advertised from multi-homing devices Inconsistent sequence numbers advertised from multi-homing devices
introduces ambiguity with respect to sequence number based mobility introduces:
procedures across the overlay.
o Ambiguity with respect to how the remote ToRs should handle o Ambiguity with respect to how the remote PEs should handle
paths with same ESI and different sequence numbers. A remote ToR paths with same ESI and different sequence numbers. A remote PE
may not program ECMP paths if it receives routes with different may not program ECMP paths if it receives routes with different
sequence numbers from a set of multi-homing GWs sharing the same sequence numbers from a set of multi-homing PEs sharing the same
ESI. ESI.
o Breaks consistent route versioning across the network overlay o Breaks consistent route versioning across the network overlay
that is needed for EVPN mobility procedures to work. that is needed for EVPN mobility procedures to work.
As an example, in this inconsistent state, GW2 would drop a remote As an example, in this inconsistent state, PE2 would drop a remote
route received for the same host with sequence number N (as its local route received for the same host with sequence number N (as its local
sequence number is N+1), while GW1 would install it as the best route sequence number is N+1), while PE1 would install it as the best route
(as its local sequence number is 0). (as its local sequence number is 0).
There is need for a mechanism to ensure consistency of sequence There is need for a mechanism to ensure consistency of sequence
numbers advertised from a set of multi-homing devices for EVPN numbers advertised from a set of multi-homing devices for EVPN
mobility to work reliably. mobility to work reliably.
In order to support mobility for multi-homed hosts using the sequence In order to support mobility for multi-homed hosts using the sequence
number mobility attribute, local MAC and MAC-IP routes MUST be number mobility attribute, local MAC and MAC-IP routes learnt on a
advertised with the same sequence number by all GW devices that the multi-homed ES MUST be advertised with the same sequence number by
ESI is multi-homed to. In other words, there is need for a mechanism all PE devices that the ES is multi-homed to. There is need for a
to ensure consistency of sequence numbers advertised from a set of mechanism to ensure consistency of sequence numbers assigned across
multi-homing devices for EVPN mobility to work reliably. these PEs.
5. Design Considerations 5. Design Considerations
To summarize, sequence number assignment scheme and implementation To summarize, sequence number assignment scheme and implementation
must take following considerations into account: must take following considerations into account:
o MAC+IP may be learnt on an ESI multi-homed to multiple GW o MAC+IP may be learnt on an ES multi-homed to multiple PE
devices, hence requires sequence numbers to be synchronized devices, hence requires sequence numbers to be synchronized
across multi-homing GW devices. across multi-homing PE devices.
o MAC only RT-2 is optional in an IRB scenario and may not o MAC only RT-2 is optional in an IRB scenario and may not
necessarily be advertised in addition to MAC+IP RT-2 necessarily be advertised in addition to MAC+IP RT-2
o Single MAC may be associated with multiple IPs, i.e., multiple o Single MAC may be associated with multiple IPs, i.e., multiple
host IPs may share a common MAC host IPs may share a common MAC
o Host IP move could result in host moving to a new MAC, resulting o Host IP move could result in host moving to a new MAC, resulting
in a new IP to MAC association and a new MAC+IP route. in a new IP to MAC association and a new MAC+IP route.
skipping to change at page 12, line 18 skipping to change at page 13, line 15
o LOCAL MAC-IP learn via ARP would always accompanied by a LOCAL o LOCAL MAC-IP learn via ARP would always accompanied by a LOCAL
MAC learn event resulting from the ARP packet. MAC and MAC-IP MAC learn event resulting from the ARP packet. MAC and MAC-IP
learning, however, could happen in any order learning, however, could happen in any order
o Use cases discussed earlier that do not maintain a constant 1:1 o Use cases discussed earlier that do not maintain a constant 1:1
MAC-IP mapping across moves could potentially be addressed by MAC-IP mapping across moves could potentially be addressed by
using separate sequence numbers associated with MAC and IP using separate sequence numbers associated with MAC and IP
components of MAC+IP route. Maintaining two separate sequence components of MAC+IP route. Maintaining two separate sequence
numbers however adds significant overhead with respect to numbers however adds significant overhead with respect to
complexity, debugability, and backward compatibility. It is complexity, debugability, and backward compatibility. Hence, this
therefore goal of solution presented here to address these document addresses these requirements via a single sequence
requirements via a single sequence number attribute. number attribute.
6. Solution Components 6. Solution Components
This section goes over main components of the EVPN IRB mobility This section goes over main components of the EVPN IRB mobility
solution proposed in this draft. Later sections will go over exact solution proposed in this draft. Later sections will go over exact
sequence number assignment procedures resulting from concepts sequence number assignment procedures resulting from concepts
described in this section. described in this section.
6.1 Sequence Number Inheritance 6.1 Sequence Number Inheritance
skipping to change at page 13, line 39 skipping to change at page 14, line 38
. | . |
Mx-IPw ----- Mx-IPw -----
| | | |
Mx-IPx ----- Mx-IPx -----
In such a case, a host-IP move to a different physical server would In such a case, a host-IP move to a different physical server would
result in IP moving to a new MAC binding. A new MAC-IP route result in IP moving to a new MAC binding. A new MAC-IP route
resulting from this move must now be advertised with a sequence resulting from this move must now be advertised with a sequence
number that is higher than the previous MAC-IP route for this IP, number that is higher than the previous MAC-IP route for this IP,
advertised from the prior location. As an example, consider a route advertised from the prior location. As an example, consider a route
Mx-IPx that is currently advertised with sequence number N from GW1. Mx-IPx that is currently advertised with sequence number N from PE1.
IPx moving to a new physical server behind GW2 results in IPx being IPx moving to a new physical server behind PE2 results in IPx being
associated with MAC Mz. A new local Mz-IPx route resulting from this associated with MAC Mz. A new local Mz-IPx route resulting from this
move at GW2 must now be advertised with a sequence number higher than move at PE2 must now be advertised with a sequence number higher than
N. This is so that GW devices, including GW1, GW2, and other remote N. This is so that PE devices, including PE1, PE2, and other remote
GW devices that are part of the overlay can clearly determine and PE devices that are part of the overlay can clearly determine and
program the most recent MAC binding and reachability for the IP. GW1, program the most recent MAC binding and reachability for the IP. PE1,
on receiving this new Mz-IPx route with sequence number say, N+1, for on receiving this new Mz-IPx route with sequence number say, N+1, for
symmetric IRB case, would update IPx reachability via GW2 in symmetric IRB case, would update IPx reachability via PE2 in
forwarding, for asymmetric IRB case, would update IPx's ARP binding forwarding, for asymmetric IRB case, would update IPx's ARP binding
to Mz. In addition, GW1 would clear and withdraw the stale Mx-IPx to Mz. In addition, PE1 would clear and withdraw the stale Mx-IPx
route with the lower sequence number. route with the lower sequence number.
This also implies that sequence number associated with local MAC Mz This also implies that sequence number associated with local MAC Mz
and all local MAC-IP children of Mz at GW2 must now be incremented to and all local MAC-IP children of Mz at PE2 must now be incremented to
N+1, and re-advertised across the overlay. While this re- N+1, and re-advertised across the overlay. While this re-
advertisement of all local MAC-IP children routes affected by the advertisement of all local MAC-IP children routes affected by the
parent MAC route is an overhead, it avoids the need for two separate parent MAC route is an overhead, it avoids the need for two separate
sequence number attributes to be maintained and advertised for IP and sequence number attributes to be maintained and advertised for IP and
MAC components of MAC+IP RT-2. Implementation would need to be able MAC components of MAC+IP RT-2. Implementation would need to be able
to lookup MAC-IP routes for a given IP and update sequence number for to lookup MAC-IP routes for a given IP and update sequence number for
it's parent MAC and its MAC-IP children. it's parent MAC and its MAC-IP children.
6.3 Multi-homing Mobility Synchronization 6.3 Multi-homing Mobility Synchronization
In order to support mobility for multi-homed hosts, local MAC and In order to support mobility for multi-homed hosts, local MAC and
MAC-IP routes learnt on the shared ESI MUST be advertised with the MAC-IP routes learnt on a shared ES MUST be advertised with the same
same sequence number by all GW devices that the ESI is multi-homed sequence number by all PE devices that the ES is multi-homed to. This
to. This also applies to local MAC only routes. LOCAL MAC and MAC-IP also applies to local MAC only routes. LOCAL MAC and MAC-IP may be
may be learnt natively via data plane and ARP/ND respectively as well learnt natively via data plane and ARP/ND respectively as well as via
as via SYNC from another multi-homing GW to achieve local switching. SYNC from another multi-homing PE to achieve local switching. Local
Local and SYNC route learning can happen in any order. Local MAC-IP and SYNC route learning can happen in any order. Local MAC-IP routes
routes advertised by all multi-homing GW devices sharing the ESI must advertised by all multi-homing PE devices sharing the ES must carry
carry the same sequence number, independent of the order in which the same sequence number, independent of the order in which they are
they are learnt. This implies: learnt. This implies:
o On local or sync MAC-IP route learning, sequence number for the o On local or sync MAC-IP route learning, sequence number for the
local MAC-IP route MUST be compared and updated to the higher local MAC-IP route MUST be compared and updated to the higher
value. value.
o On local or sync MAC route learning, sequence number for the o On local or sync MAC route learning, sequence number for the
local MAC route MUST be compared and updated to the higher value. local MAC route MUST be compared and updated to the higher value.
If an update to local MAC-IP sequence number is required as a result If an update to local MAC-IP sequence number is required as a result
of above comparison with sync MAC-IP route, it would essentially of above comparison with sync MAC-IP route, it would essentially
amount to a sequence number update on the parent local MAC, resulting amount to a sequence number update on the parent local MAC, resulting
in the inherited sequence number update on the MAC-IP route. in inherited sequence number update on the MAC-IP route.
7. Requirements for Sequence Number Assignment 7. Requirements for Sequence Number Assignment
Following sections summarize sequence number assignment procedure Following sections summarize sequence number assignment procedure
needed on local and sync MAC and MAC-IP route learning events in needed on local and sync MAC and MAC-IP route learning events in
order to accomplish the above. order to accomplish the above.
7.1 LOCAL MAC-IP learning 7.1 LOCAL MAC-IP learning
A local Mx-IPx learning via ARP or ND should result in computation OR A local Mx-IPx learning via ARP or ND should result in computation OR
skipping to change at page 15, line 40 skipping to change at page 16, line 40
updated sequence number. updated sequence number.
Note that the local MAC sequence number might already be present if Note that the local MAC sequence number might already be present if
there was a local MAC-IP learnt prior to the local MAC, in which case there was a local MAC-IP learnt prior to the local MAC, in which case
the above may not result in any change in local MAC's sequence the above may not result in any change in local MAC's sequence
number. number.
7.3 Remote MAC OR MAC-IP Update 7.3 Remote MAC OR MAC-IP Update
On receiving a remote MAC OR MAC-IP route update associated with a On receiving a remote MAC OR MAC-IP route update associated with a
MAC Mx with a sequence number that is higher than a LOCAL route for MAC Mx with a sequence number that is higher than or equal to
MAC Mx: sequence number assigned to a LOCAL route for MAC Mx:
o GW MUST trigger probe and deletion procedure for all LOCAL IPs o PE MUST trigger probe and deletion procedure for all LOCAL IPs
associated with MAC Mx associated with MAC Mx
o GW MUST trigger deletion procedure for LOCAL MAC route for Mx o PE MUST trigger deletion procedure for LOCAL MAC route for Mx
7.4 REMOTE (SYNC) MAC update 7.4 REMOTE (SYNC) MAC update
Corresponding local MAC Mx (if present) Sequence number should be re- Corresponding local MAC Mx (if present) sequence number should be re-
computed as follows: computed as follows:
o If the current sequence number is less than the received SYNC o If the current sequence number is less than the received SYNC
MAC sequence number, it MUST be increased to be equal to received MAC sequence number, it MUST be increased to be equal to received
SYNC MAC sequence number. SYNC MAC sequence number.
o If a LOCAL MAC sequence number is updated as a result of the o If a LOCAL MAC sequence number is updated as a result of the
above, all LOCAL MAC-IPs associated with MAC Mx MUST inherit the above, all LOCAL MAC-IPs associated with MAC Mx MUST inherit the
updated sequence number. updated sequence number.
7.5 REMOTE (SYNC) MAC-IP update 7.5 REMOTE (SYNC) MAC-IP update
If this is a SYNCed MAC-IP on a local ESI, it would also result in a If this is a SYNCed MAC-IP on a local ES, it would also result in a
derived SYNC MAC Mx route entry, as MAC only RT-2 advertisement is derived SYNC MAC Mx route entry, as MAC only RT-2 advertisement is
optional. Corresponding local MAC Mx (if present) Sequence number optional. Corresponding local MAC Mx (if present) sequence number
should be re-computed as follows: should be re-computed as follows:
o If the current sequence number is less than the received SYNC o If the current sequence number is less than the received SYNC
MAC sequence number, it MUST be increased to be equal to received MAC sequence number, it MUST be increased to be equal to received
SYNC MAC sequence number. SYNC MAC sequence number.
o If a LOCAL MAC sequence number is updated as a result of the o If a LOCAL MAC sequence number is updated as a result of the
above, all LOCAL MAC-IPs associated with MAC Mx MUST inherit the above, all LOCAL MAC-IPs associated with MAC Mx MUST inherit the
updated sequence number. updated sequence number.
7.6 Inter-op 7.6 Inter-op
In general, if all GW nodes in the overlay network follow the above In general, if all PE nodes in the overlay network follow the above
sequence number assignment procedure, and the GW is advertising both sequence number assignment procedure, and the PE is advertising both
MAC+IP and MAC routes, sequence number advertised with the MAC and MAC+IP and MAC routes, sequence number advertised with the MAC and
MAC+IP routes with the same MAC would always be the same. However, an MAC+IP routes with the same MAC would always be the same. However, an
inter-op scenario with a different implementation could arise, where inter-op scenario with a different implementation could arise, where
a GW implementation non-compliant with this document or with RFC 7432 a PE implementation non-compliant with this document or with RFC 7432
assigns and advertises independent sequence numbers to MAC and MAC+IP assigns and advertises independent sequence numbers to MAC and MAC+IP
routes. To handle this case, if different sequence numbers are routes. To handle this case, if different sequence numbers are
received for remote MAC+IP and corresponding remote MAC routes from a received for remote MAC+IP and corresponding remote MAC routes from a
remote GW, sequence number associated with the remote MAC route remote PE, sequence number associated with the remote MAC route
should be computed as: should be computed as:
o Highest of the all received sequence numbers with remote MAC+IP o Highest of the all received sequence numbers with remote MAC+IP
and MAC routes with the same MAC. and MAC routes with the same MAC.
o MAC sequence number would be re-computed on a MAC or MAC+IP o MAC sequence number would be re-computed on a MAC or MAC+IP
route withdraw as per above. route withdraw as per above.
A MAC and / or IP move to the local GW would now result in the MAC A MAC and / or IP move to the local PE would now result in the MAC
(and hence all MAC-IP) sequence numbers incremented from the above (and hence all MAC-IP) sequence numbers incremented from the above
computed remote MAC sequence number. computed remote MAC sequence number.
7.7 MAC Sharing Race Condition
In a MAC sharing use case described in section 6.2, a race condition
is possible with simultaneous host moves between a pair of PEs. As an
example, consider PE1 with local host IPs I1 and I2 sharing MAC M1,
and PE2 with local host IPs I3 and I4 sharing MAC M2. A simultaneous
move of I1 from PE1 to PE2 and of I3 from PE2 to PE1, such that I3 is
learnt on PE1 before I1's local entry has been probed out on PE1
and/or I1 is learnt on PE2 before I3's local entry has been probed
out on PE2 may trigger a race condition. This race condition together
with MAC sequence number assignment rules defined in section 7.1 can
cause new mac-ip routes [I1, M2] and [I3, M1] to bounce a couple of
times with an incremented sequence number until stale entries [I1,
M1] and [I3, M2] have been probed out from PE1 and PE2 respectively.
An implementation MUST ensure proper probing procedures to remove
stale ARP, ND, and local MAC entries, following a move, on learning
remote routes as defined in section 7.3 (and as per [EVPN-IRB]) to
minimize exposure to this race condition.
8. Routed Overlay 8. Routed Overlay
An additional use case is possible, such that traffic to an end host An additional use case is possible, such that traffic to an end host
in the overlay is always IP routed. In a purely routed overlay such in the overlay is always IP routed. In a purely routed overlay such
as this: as this:
o A host MAC is never advertised in EVPN overlay control plane o A host MAC is never advertised in EVPN overlay control plane
o Host /32 or /128 IP reachability is distributed across the o Host /32 or /128 IP reachability is distributed across the
overlay via EVPN route type 5 (RT-5) along with a zero or non- overlay via EVPN route type 5 (RT-5) along with a zero or non-
zero ESI zero ESI
skipping to change at page 17, line 19 skipping to change at page 18, line 41
o Host /32 or /128 IP reachability is distributed across the o Host /32 or /128 IP reachability is distributed across the
overlay via EVPN route type 5 (RT-5) along with a zero or non- overlay via EVPN route type 5 (RT-5) along with a zero or non-
zero ESI zero ESI
o An overlay IP subnet may still be stretched across the underlay o An overlay IP subnet may still be stretched across the underlay
fabric, however, intra-subnet traffic across the stretched fabric, however, intra-subnet traffic across the stretched
overlay is never bridged overlay is never bridged
o Both inter-subnet and intra-subnet traffic, in the overlay is o Both inter-subnet and intra-subnet traffic, in the overlay is
IP routed at the EVPN GW. IP routed at the EVPN PE.
Please refer to [RFC 7814] for more details. Please refer to [RFC 7814] for more details.
Host mobility within the stretched subnet would still need to be Host mobility within the stretched subnet would still need to be
supported for this use. In the absence of any host MAC routes, supported for this use. In the absence of any host MAC routes,
sequence number mobility EXT-COMM specified in [RFC7432], section 7.7 sequence number mobility EXT-COMM specified in [RFC7432], section 7.7
may be associated with a /32 OR /128 host IP prefix advertised via may be associated with a /32 OR /128 host IP prefix advertised via
EVPN route type 5. MAC mobility procedures defined in RFC 7432 can EVPN route type 5. MAC mobility procedures defined in RFC 7432 can
now be applied as is to host IP prefixes: now be applied as is to host IP prefixes:
skipping to change at page 20, line 24 skipping to change at page 21, line 43
This section lists possible additional corrective actions that could This section lists possible additional corrective actions that could
be taken to achieve faster recovery to normal operation. be taken to achieve faster recovery to normal operation.
9.4.1 Route Un-freezing Configuration 9.4.1 Route Un-freezing Configuration
Unfreezing the DUPLICATE OR FROZEN MAC or IP via a CLI can be Unfreezing the DUPLICATE OR FROZEN MAC or IP via a CLI can be
leveraged to recover from DUPLICATE and FROZEN state following leveraged to recover from DUPLICATE and FROZEN state following
corrective un-provisioning of the duplicate MAC or IP. corrective un-provisioning of the duplicate MAC or IP.
Unfreezing the frozen MAC or IP via a CLI at a GW should result in Unfreezing the frozen MAC or IP via a CLI at a PE should result in
that MAC OR IP being advertised with a sequence number that is higher that MAC OR IP being advertised with a sequence number that is higher
than the sequence number advertised from the other location of that than the sequence number advertised from the other location of that
MAC or IP. MAC or IP.
Two possible corrective un-provisioning scenarios exist: Two possible corrective un-provisioning scenarios exist:
o Scenario A: A duplicate MAC or IP may have been un-provisioned o Scenario A: A duplicate MAC or IP may have been un-provisioned
at the location where it was NOT marked as DUPLICATE and FROZEN at the location where it was NOT marked as DUPLICATE and FROZEN
o Scenario B: A duplicate MAC or IP may have been un-provisioned o Scenario B: A duplicate MAC or IP may have been un-provisioned
at the location where it was marked as DUPLICATE and FROZEN at the location where it was marked as DUPLICATE and FROZEN
Unfreezing the DUPLICATE and FROZEN MAC or IP, following the above Unfreezing the DUPLICATE and FROZEN MAC or IP, following the above
corrective un-provisioning scenarios would result in recovery to corrective un-provisioning scenarios would result in recovery to
steady state as follows: steady state as follows:
o Scenario A: If the duplicate MAC or IP was un-provisioned at o Scenario A: If the duplicate MAC or IP was un-provisioned at
the location where it was NOT marked as DUPLICATE, unfreezing the the location where it was NOT marked as DUPLICATE, unfreezing the
route at the FROZEN location will result in the route being route at the FROZEN location will result in the route being
advertised with a higher sequence number. This would in-turn advertised with a higher sequence number. This would in-turn
result in automatic clearing of local route at the GW location, result in automatic clearing of local route at the PE location,
where the host was un-provisioned via ARP/ND PROBE and DELETE where the host was un-provisioned via ARP/ND PROBE and DELETE
procedure specified earlier in section 8 and in [RFC 7432]. procedure specified earlier in section 8 and in [RFC 7432].
o Scenario B: If the duplicate host is un-provisioned at the o Scenario B: If the duplicate host is un-provisioned at the
location where it was marked as DUPLICATE, unfreezing the route location where it was marked as DUPLICATE, unfreezing the route
will trigger an advertisement with a higher sequence number to will trigger an advertisement with a higher sequence number to
the other location. This would in-turn trigger re-learning of the other location. This would in-turn trigger re-learning of
local route at the remote location, resulting in another local route at the remote location, resulting in another
advertisement with a higher sequence number from the remote advertisement with a higher sequence number from the remote
location. Route at the local location would now be cleared on location. Route at the local location would now be cleared on
skipping to change at page 21, line 45 skipping to change at page 23, line 17
12.1 Normative References 12.1 Normative References
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <http://www.rfc-editor.org/info/rfc7432>. 2015, <http://www.rfc-editor.org/info/rfc7432>.
[EVPN-PROXY-ARP] Rabadan et al., "Operational Aspects of Proxy- [EVPN-PROXY-ARP] Rabadan et al., "Operational Aspects of Proxy-
ARP/ND in EVPN Networks", draft-ietf-bess-evpn-proxy-arp- ARP/ND in EVPN Networks", draft-ietf-bess-evpn-proxy-arp-
nd-02, work in progress, April 2017, nd-06, work in progress, April 2019,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy- <https://tools.ietf.org/html/draft-ietf-bess-evpn-proxy-
arp-nd-02>. arp-nd-06>.
[EVPN-INTER-SUBNET] Sajassi et al., "Integrated Routing and Bridging [EVPN-IRB] Sajassi et al., "Integrated Routing and Bridging in
in EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-03, EVPN", draft-ietf-bess-evpn-inter-subnet-forwarding-08,
work in progress, Feb 2017, work in progress, March 2019,
<https://tools.ietf.org/html/draft-ietf-bess-evpn-inter- <https://tools.ietf.org/html/draft-ietf-bess-evpn-inter-
subnet-forwarding-03>. subnet-forwarding-08>.
[RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., Fee, B., [RFC7814] Xu, X., Jacquenet, C., Raszuk, R., Boyes, T., Fee, B.,
"Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension "Virtual Subnet: A BGP/MPLS IP VPN-Based Subnet Extension
Solution", RFC 7814, March 2016, Solution", RFC 7814, March 2016,
<https://tools.ietf.org/html/rfc7814>. <https://tools.ietf.org/html/rfc7814>.
12.2 Informative References 12.2 Informative References
13. Acknowledgements 13. Acknowledgements
Authors would like to thank Vibov Bhan and Patrice Brisset for Authors would like to thank Vibov Bhan and Patrice Brisset for
feedback and comments through the process. feedback the process of design and implementation of procedures
defined in this document. Authors would like to thank Wen Lin for a
detailed review and valuable comments related to MAC sharing race
conditions.
Authors' Addresses Authors' Addresses
Neeraj Malhotra (Editor) Neeraj Malhotra (Editor)
Arrcus Arrcus
EMail: neeraj.ietf@gmail.com EMail: neeraj.ietf@gmail.com
Ali Sajassi Ali Sajassi
Cisco Cisco
EMail: sajassi@cisco.com EMail: sajassi@cisco.com
 End of changes. 77 change blocks. 
183 lines changed or deleted 228 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/