--- 1/draft-ietf-lisp-eid-mobility-08.txt 2022-01-19 00:13:10.382469174 -0800 +++ 2/draft-ietf-lisp-eid-mobility-09.txt 2022-01-19 00:13:10.434470487 -0800 @@ -1,22 +1,23 @@ Network Working Group M. Portoles Internet-Draft V. Ashtaputre -Intended status: Experimental V. Moreno -Expires: 26 January 2022 F. Maino - Cisco Systems +Intended status: Experimental F. Maino +Expires: 22 July 2022 Cisco Systems + V. Moreno + Google LLC D. Farinacci lispers.net - 25 July 2021 + 18 January 2022 LISP L2/L3 EID Mobility Using a Unified Control Plane - draft-ietf-lisp-eid-mobility-08 + draft-ietf-lisp-eid-mobility-09 Abstract The LISP control plane offers the flexibility to support multiple overlay flavors simultaneously. This document specifies how LISP can be used to provide control-plane support to deploy a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility, as well as analyzing possible deployment options and models. Requirements Language @@ -33,35 +34,35 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on 26 January 2022. + This Internet-Draft will expire on 22 July 2022. Copyright Notice - Copyright (c) 2021 IETF Trust and the persons identified as the + Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components - extracted from this document must include Simplified BSD License text - as described in Section 4.e of the Trust Legal Provisions and are - provided without warranty as described in the Simplified BSD License. + extracted from this document must include Revised BSD License text as + described in Section 4.e of the Trust Legal Provisions and are + provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 3. Reference System . . . . . . . . . . . . . . . . . . . . . . 4 4. L3 Overlays and Mobility Support . . . . . . . . . . . . . . 5 4.1. Reference Architecture and packet flows . . . . . . . . . 5 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 @@ -95,21 +97,21 @@ 5.3.2. ARP registrations: MAC as a locator record . . . . . 19 5.3.3. Implementation Considerations . . . . . . . . . . . . 21 6. Optional Deployment Models . . . . . . . . . . . . . . . . . 22 6.1. IP Forwarding of Intra-subnet Traffic . . . . . . . . . . 22 6.2. Data-plane Encapsulation Options . . . . . . . . . . . . 23 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 9.1. Normative References . . . . . . . . . . . . . . . . . . 24 9.2. Informative References . . . . . . . . . . . . . . . . . 25 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 1. Introduction This document describes the architecture and design options required to offer a unified L2 and L3 overlay solution for End-point Identifier (EID) mobility using the LISP control-plane. The architecture takes advantage of the flexibility that LISP provides to simultaneously support different overlay types. While the LISP specification defines both the data-plane and the control- @@ -232,23 +234,23 @@ :Device 1: :Device 2: :Device 3: :Device 4: '--------' '--------' '--------' '--------' (IID1,1.0.0.1) (IID1,3.0.0.2) (IID1,3.0.0.3) (IID1,2.0.0.4) (IID2,0:0:3:0:0:2) (IID2,0:0:3:0:0:3) Figure 2: Reference Mobility Architecture 4.1.1. Routed Traffic Flow: L3 Overlay use Inter-subnet traffic is encapsulated using the L3 overlay. The - process to encapsulate this traffic is the same as described in the - original specification [RFC6830]. We describe the packet flow here - for completeness + process to encapsulate this traffic is the same as described in + [I-D.ietf-lisp-rfc6830bis] and [I-D.ietf-lisp-rfc6833bis]. We + describe the packet flow here for completeness The following is a sequence example of the unicast packet flow and the control plane operations when in the topology shown in Figure 1 End-Device 1, in LISP site A, wants to communicate with End-Device 4 in LISP site D. Note that both end systems reside in different subnets. We'll assume that End-Device 1 knows the EID IP address of End-Device 4 (e.g. it is learned using a DNS service). * End-Device 1 sends an IP packet frame with destination 2.0.0.4 and source 1.0.0.1. As the destination address lies on a different @@ -419,44 +421,45 @@ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | EID-Prefix (IPv4 or IPv6) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| Priority | Weight | M Priority | M Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | Unused Flags |L|p|R| Loc-AFI | | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| Locator | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The L3 EID record follows the structure as described in [RFC6830]. + The L3 EID record follows the structure as described in + [I-D.ietf-lisp-rfc6833bis]. 4.2.3. LISP Mapping System support The interface between the xTRs and the Mapping System is described in - [RFC6833] and this document follows the specification as described - there. When available, the registrations MAY be implemented over a - reliable transport as described in + [I-D.ietf-lisp-rfc6833bis] and this document follows the + specification as described there. When available, the registrations + MAY be implemented over a reliable transport as described in [I-D.kouvelas-lisp-map-server-reliable-transport]. In order to support system convergence after mobility, when the Map- Server receives a new registration for a specific EID, it MUST send a Map-Notify to the entire RLOC set in the site that last registered this same EID. This Map-Notify is used to track moved-away state of L3 EIDs as described in Section 4.2.4. 4.2.4. Using SMRs to Track Moved-Away Hosts One of the key elements to support end-host mobility using the LISP architecture is the Solicit-Map-Request (SMR). This is a special message by means of which an ETR can request an ITR to send a new Map-Request for a particular EID record. In essence the SMR message is used as a signal to indicate a change in mapping information and - it is described with detail in [RFC6830]. + it is described in [I-D.ietf-lisp-rfc6833bis]. In order to support mobility, an ETR SHALL maintain a list of EID records for which it has to generate a SMR message whenever it receives traffic with that EID as destination. The particular strategy to maintain an Away Table is implementation specific and it will be typically based on the strategy to detect the presence of hosts and the use of Map-Notify messages received from the Map-Server. In essence the table SHOULD provide support to the following: @@ -469,23 +472,23 @@ 4.2.5. L3 multicast support L3 Multicast traffic on the overlay MAY be supported by either replicated unicast, or underlay (RLOC) multicast. Specific solutions to support L3 multicast over LISP controlled overlays are specified in in [RFC6831], and [RFC8378]. 4.2.6. Time-to-Live Handling in Data-Plane - The LISP specification ([RFC6830]) describes how to handle Time-to- - Live values of the inner and outer headers during encapsulation and - decapsulation of packets when using the L3 overlay. + The LISP specification ([I-D.ietf-lisp-rfc6830bis]) describes how to + handle Time-to-Live values of the inner and outer headers during + encapsulation and decapsulation of packets when using the L3 overlay. 5. L2 Overlays and Mobility Support 5.1. Reference Architecture and packet flows In order to support L2 packet flow descriptions in this section we use Figure 1 as reference. This section uses Sites B and C to describe the flows. / | | \ @@ -680,28 +683,29 @@ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | /| ... Layer-2 MAC Address | Priority | Weight | | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | o | M Priority | M Weight | Unused Flags |L|p|R| | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Loc-AFI | Locator.... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| ... Locator +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - The L2 EID record follows the structure as described in [RFC6830]. + The L2 EID record follows the structure as described in + [I-D.ietf-lisp-rfc6833bis]. 5.2.3. Interface to the LISP Mapping System The interface between the xTRs and the Mapping System is described in - [RFC6833] and this document follows the specification as described - there. When available, the registrations MAY be implemented over a - reliable transport. + [I-D.ietf-lisp-rfc6833bis] and this document follows the + specification as described there. When available, the registrations + MAY be implemented over a reliable transport. In order to support system convergence after mobility, when the Map- Server receives a new registration for a specific EID, it MUST send a Map-Notify to the entire RLOC set in the site that last registered this same EID. This Map-Notify is used to track moved-away state of L2 EIDs as described in Section 5.2.4. 5.2.4. SMR support to track L2 hosts that moved away In order to support mobility, an ETR SHALL maintain a list of EID @@ -888,23 +892,23 @@ | C | Rsvd1 | Flags | Type = 1 | Rsvd2 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 2 + 6 | AFI = 6 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Layer-2 MAC Address ... | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | \| ... Layer-2 MAC Address | +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+. An EID record with a locator record that carries a MAC address - follows the same structure as described in [RFC6830]. However, some - fields of the EID record and the locator record require special - consideration: + follows the same structure as described in + [I-D.ietf-lisp-rfc6833bis]. However, some fields of the EID record + and the locator record require special consideration: Locator Count: This value SHOULD be set to 1. Instance-ID: This is the IID used to provide segmentation of the L2-overlays, L3 overlays and ARP tables. Priority and Weight: IP to MAC bindings are one to one bindings. An ETR SHOULD not register more than one MAC address in the locator record together with an IP based EID. The Priority of the MAC address record is set to 255. The Weight value SHOULD be ignored @@ -1019,24 +1023,24 @@ and [VXLAN]: * VXLAN-GPE encap: This encapsulation format is defined in [I-D.ietf-lisp-gpe]. It allows encapsulation both L2 and L3 packets and the VNI field directly maps to the Instance-ID used in the control plane. Note that when using this encapsulation for a unified solution the P-bit is set and the Next-Protocol field is used (typically with values 0x1 (IPv4) or 0x2 (IPv6) in L3-overlays, and value 0x3 in L2-overlays). - * LISP encap: This is the encapsulation format defined in the - original LISP specification [RFC6830]. The encapsulation allows - encapsulating both L2 and L3 packets. The Instance-ID used in the - EIDs directly maps to the Instance-ID that the LISP header + * LISP encap: This is the encapsulation format defined in the LISP + specification [I-D.ietf-lisp-rfc6830bis]. The encapsulation + allows encapsulating both L2 and L3 packets. The Instance-ID used + in the EIDs directly maps to the Instance-ID that the LISP header carries. At the ETR, after decapsulation, the IID MAY be used to decide between L2 processing or L3 processing. * VXLAN encap: This is a L2 encapsulation format defined in [RFC7348]. While being a L2 encapsulation it can be used both for L2 and L3 overlays. The Instance-ID used in LISP signaling maps to the VNI field of the VXLAN header. Providing L3 overlays using VXLAN generally requires using the ETR MAC address as destination MAC address of the inner Ethernet header. The process to learn or derive this ETR MAC address is not included as part of this @@ -1100,46 +1104,63 @@ Separation Protocol (LISP) Multicast", RFC 8378, DOI 10.17487/RFC8378, May 2018, . 9.2. Informative References [I-D.ietf-lisp-gpe] Maino, F., Lemon, J., Agarwal, P., Lewis, D., and M. Smith, "LISP Generic Protocol Extension", Work in Progress, Internet-Draft, draft-ietf-lisp-gpe-19, 26 July - 2020, . + 2020, . [I-D.ietf-lisp-pubsub] - AlbertoRodriguezNatal, Ermagan, V., Cabellos-Aparicio, A., - Barkai, S., and M. Boucadair, "Publish/Subscribe - Functionality for LISP", Work in Progress, Internet-Draft, - draft-ietf-lisp-pubsub-09, 28 June 2021, - . + Rodriguez-Natal, A., Ermagan, V., Cabellos, A., Barkai, + S., and M. Boucadair, "Publish/Subscribe Functionality for + LISP", Work in Progress, Internet-Draft, draft-ietf-lisp- + pubsub-09, 28 June 2021, . + + [I-D.ietf-lisp-rfc6830bis] + Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. + Cabellos, "The Locator/ID Separation Protocol (LISP)", + Work in Progress, Internet-Draft, draft-ietf-lisp- + rfc6830bis-36, 18 November 2020, + . + + [I-D.ietf-lisp-rfc6833bis] + Farinacci, D., Maino, F., Fuller, V., and A. Cabellos, + "Locator/ID Separation Protocol (LISP) Control-Plane", + Work in Progress, Internet-Draft, draft-ietf-lisp- + rfc6833bis-30, 18 November 2020, + . [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private Networks (VPNs)", Work in Progress, Internet-Draft, draft- - ietf-lisp-vpn-06, 3 August 2020, . + ietf-lisp-vpn-08, 18 January 2022, + . [I-D.kouvelas-lisp-map-server-reliable-transport] - Leong, J., Lewis, D., Venkatachalapathy, B., Cassar, C., - Kouvelas, I., and J. Arango, "LISP Map Server Reliable - Transport", Work in Progress, Internet-Draft, draft- - kouvelas-lisp-map-server-reliable-transport-06, 26 April - 2021, . + Leong, J., Lewis, D., Pitta, B., Cassar, C., Kouvelas, I., + and J. Arango, "LISP Map Server Reliable Transport", Work + in Progress, Internet-Draft, draft-kouvelas-lisp-map- + server-reliable-transport-07, 18 January 2022, + . Authors' Addresses + Marc Portoles Comeras Cisco Systems 170 Tasman Drive San Jose, CA 95134 United States of America Email: mportole@cisco.com Vrushali Ashtaputre Cisco Systems @@ -1142,32 +1163,31 @@ Email: mportole@cisco.com Vrushali Ashtaputre Cisco Systems 170 Tasman Drive San Jose, CA 95134 United States of America Email: vrushali@cisco.com - Victor Moreno - Cisco Systems - 170 Tasman Drive - San Jose, CA 95134 - United States of America - - Email: vimoreno@cisco.com - Fabio Maino Cisco Systems 170 Tasman Drive San Jose, CA 95134 United States of America Email: fmaino@cisco.com + Victor Moreno + Google LLC + 1600 Amphitheatre Pkwy + Mountain View, CA 94043 + United States of America + + Email: vimoreno@google.com Dino Farinacci lispers.net San Jose, CA United States of America Email: farinacci@gmail.com