draft-ietf-bess-evpn-irb-extended-mobility-01.txt   draft-ietf-bess-evpn-irb-extended-mobility-02.txt 
BESS Working Group N. Malhotra, Ed. Internet Draft N. Malhotra, Ed.
INTERNET-DRAFT Arrcus BESS Working Group A. Sajassi
Intended Status: Proposed Standard A. Pattekar
Intended Status: Proposed Standard A. Sajassi
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: Dec 21, 2019 June 19, 2019 Expires: May 5, 2020 Nov 2, 2019
Extended Mobility Procedures for EVPN-IRB Extended Mobility Procedures for EVPN-IRB
draft-ietf-bess-evpn-irb-extended-mobility-01 draft-ietf-bess-evpn-irb-extended-mobility-02
Abstract Abstract
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
skipping to change at page 3, line 6 skipping to change at page 3, line 4
3.2.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . 7 3.2.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . 7
3.2.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3 Problem . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3 Host 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 . . . . . . . . . . . . . . . . 11 4. EVPN All Active multi-homed ES . . . . . . . . . . . . . . . . 11
5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12
6. Solution Components . . . . . . . . . . . . . . . . . . . . . 13 6. Solution Components . . . . . . . . . . . . . . . . . . . . . 13
6.1 Sequence Number Inheritance . . . . . . . . . . . . . . . . 13 6.1 Sequence Number Inheritance . . . . . . . . . . . . . . . . 13
6.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . . . 14 6.2 MAC Sharing . . . . . . . . . . . . . . . . . . . . . . . . 14
6.3 Multi-homing Mobility Synchronization . . . . . . . . . . . 15 6.3 Multi-homing Mobility Synchronization . . . . . . . . . . . 15
7. Requirements for Sequence Number Assignment . . . . . . . . . 15 7. Requirements for Sequence Number Assignment . . . . . . . . . 15
7.1 LOCAL MAC-IP learning . . . . . . . . . . . . . . . . . . . 15 7.1 LOCAL MAC-IP learning . . . . . . . . . . . . . . . . . . . 15
7.2 LOCAL MAC learning . . . . . . . . . . . . . . . . . . . . 16 7.2 LOCAL MAC learning . . . . . . . . . . . . . . . . . . . . 16
7.3 Remote MAC OR MAC-IP Update . . . . . . . . . . . . . . . . 16 7.3 Remote MAC OR MAC-IP Update . . . . . . . . . . . . . . . . 16
7.4 REMOTE (SYNC) MAC update . . . . . . . . . . . . . . . . . 16 7.4 REMOTE (SYNC) MAC update . . . . . . . . . . . . . . . . . 16
7.5 REMOTE (SYNC) MAC-IP update . . . . . . . . . . . . . . . . 17 7.5 REMOTE (SYNC) MAC-IP update . . . . . . . . . . . . . . . . 17
7.6 Inter-op . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6 Inter-op . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.7 MAC Sharing Race Condition . . . . . . . . . . . . . . . . 18 7.7 MAC Sharing Race Condition . . . . . . . . . . . . . . . . 18
8. Routed Overlay . . . . . . . . . . . . . . . . . . . . . . . . 18 7.8 Mobility Convergence . . . . . . . . . . . . . . . . . . . 18
9. Duplicate Host Detection . . . . . . . . . . . . . . . . . . . 19 7.8.1 Generalized Probing Logic . . . . . . . . . . . . . . . 19
9.1 Scenario A . . . . . . . . . . . . . . . . . . . . . . . . . 19 8. Routed Overlay . . . . . . . . . . . . . . . . . . . . . . . . 19
9. Duplicate Host Detection . . . . . . . . . . . . . . . . . . . 20
9.1 Scenario A . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2 Scenario B . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2 Scenario B . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2.1 Duplicate IP Detection Procedure for Scenario B . . . . 20 9.2.1 Duplicate IP Detection Procedure for Scenario B . . . . 21
9.3 Scenario C . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.3 Scenario C . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.4 Duplicate Host Recovery . . . . . . . . . . . . . . . . . . 21 9.4 Duplicate Host Recovery . . . . . . . . . . . . . . . . . . 22
9.4.1 Route Un-freezing Configuration . . . . . . . . . . . . 21 9.4.1 Route Un-freezing Configuration . . . . . . . . . . . . 22
9.4.2 Route Clearing Configuration . . . . . . . . . . . . . 22 9.4.2 Route Clearing Configuration . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1 Normative References . . . . . . . . . . . . . . . . . . . 23 12.1 Normative References . . . . . . . . . . . . . . . . . . . 24
12.2 Informative References . . . . . . . . . . . . . . . . . . 23 12.2 Informative References . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix A . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
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-IRB] for more background on EVPN IRB forwarding modes. refer to [EVPN-IRB] for more background on EVPN IRB forwarding modes.
skipping to change at page 18, line 24 skipping to change at page 18, line 24
out on PE2 may trigger a race condition. This race condition together out on PE2 may trigger a race condition. This race condition together
with MAC sequence number assignment rules defined in section 7.1 can 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 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, times with an incremented sequence number until stale entries [I1,
M1] and [I3, M2] have been probed out from PE1 and PE2 respectively. M1] and [I3, M2] have been probed out from PE1 and PE2 respectively.
An implementation MUST ensure proper probing procedures to remove An implementation MUST ensure proper probing procedures to remove
stale ARP, ND, and local MAC entries, following a move, on learning 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 remote routes as defined in section 7.3 (and as per [EVPN-IRB]) to
minimize exposure to this race condition. minimize exposure to this race condition.
7.8 Mobility Convergence
This sections is to be treated as optional and details ARP and ND
probing procedures that MAY be implemented to achieve faster host re-
learning and convergence on mobility events.
o Following a host move from PE1 to PE2, the host's MAC is
discovered at PE2 as a local MAC via a data frames received from
the host. If PE2 has a prior REMOTE MAC-IP host route for this
MAC from PE1, an ARP/ND probe MAY be triggered at PE2 to learn
the MAC-IP as a local adjacency and trigger EVPN RT-2
advertisement for this MAC-IP across the overlay with new
reachability via PE2. This results in a reliable "event based"
host IP learning triggered by a "MAC learning event" across the
overlay, and hence faster convergence of overlay routed flows to
the host.
o Following a host move from PE1 to PE2, once PE1 receives a MAC
or MAC-IP route from PE2 with a higher sequence number, an ARP/ND
probe MAY be triggered at PE1 to clear the stale local MAC-IP
neighbor adjacency OR re-learn the local MAC-IP in case the host
has moved back or is duplicate.
o Following a local MAC age-out, if there is a local IP adjacency
with this MAC, an ARP/ND probe MAY be triggered for this IP to
either re-learn the local MAC and maintain local l3 and l2
reachability to this host OR to clear the ARP/ND entry in case
the host is indeed no longer local. Note that this accomplishes
clearing of stale ARP entries, triggered by a MAC age-out event
even when the ARP refresh timer was longer than the MAC age-out
timer. Clearing of stale IP neighbor entries in-turn facilitates
traffic convergence in the event that the host was silent and not
discovered at its new location. Once stale neighbor entry for the
host is cleared, routed traffic flow destined for the host can
re-trigger ARP/ND discovery for this host at the new location.
7.8.1 Generalized Probing Logic
Above probing logic may be generalized as probing for an IP neighbor
anytime a resolving parent MAC route is "inconsistent" with the MAC-
IP neighbor route, where being inconsistent is defined as being not
present OR conflicting in terms of the route source being local OR
remote. MAC-IP to MAC parent relationship described earlier in this
document in section 6.1 MAY be used to achieve this logic.
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-
skipping to change at page 23, line 45 skipping to change at page 24, line 45
Authors would like to thank Vibov Bhan and Patrice Brisset for Authors would like to thank Vibov Bhan and Patrice Brisset for
feedback the process of design and implementation of procedures feedback the process of design and implementation of procedures
defined in this document. Authors would like to thank Wen Lin for a defined in this document. Authors would like to thank Wen Lin for a
detailed review and valuable comments related to MAC sharing race detailed review and valuable comments related to MAC sharing race
conditions. conditions.
Authors' Addresses Authors' Addresses
Neeraj Malhotra (Editor) Neeraj Malhotra (Editor)
Arrcus Cisco
EMail: neeraj.ietf@gmail.com EMail: neeraj.ietf@gmail.com
Ali Sajassi Ali Sajassi
Cisco Cisco
EMail: sajassi@cisco.com EMail: sajassi@cisco.com
Aparna Pattekar Aparna Pattekar
Cisco Cisco
Email: apjoshi@cisco.com Email: apjoshi@cisco.com
Jorge Rabadan Jorge Rabadan
 End of changes. 8 change blocks. 
24 lines changed or deleted 70 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/