--- 1/draft-ietf-lisp-eid-mobility-01.txt 2018-05-14 23:13:10.634969857 -0700 +++ 2/draft-ietf-lisp-eid-mobility-02.txt 2018-05-14 23:13:10.682971016 -0700 @@ -1,22 +1,22 @@ Network Working Group M. Portoles Internet-Draft V. Ashtaputre Intended status: Experimental V. Moreno -Expires: May 19, 2018 F. Maino +Expires: November 15, 2018 F. Maino Cisco Systems D. Farinacci lispers.net - November 15, 2017 + May 14, 2018 LISP L2/L3 EID Mobility Using a Unified Control Plane - draft-ietf-lisp-eid-mobility-01 + draft-ietf-lisp-eid-mobility-02 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, as well as analyzing possible deployment options and models. Requirements Language @@ -33,25 +33,25 @@ 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 May 19, 2018. + This Internet-Draft will expire on November 15, 2018. Copyright Notice - Copyright (c) 2017 IETF Trust and the persons identified as the + Copyright (c) 2018 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 @@ -67,25 +67,25 @@ 4.1.1. Routed Traffic Flow: L3 Overlay use . . . . . . . . . 6 4.1.2. L3 Mobility Flow . . . . . . . . . . . . . . . . . . 6 4.2. Implementation Considerations . . . . . . . . . . . . . . 7 4.2.1. L3 Segmentation . . . . . . . . . . . . . . . . . . . 7 4.2.2. L3 Database-Mappings . . . . . . . . . . . . . . . . 8 4.2.3. LISP Mapping System support . . . . . . . . . . . . . 8 4.2.4. Using SMRs to Track Moved-Away Hosts . . . . . . . . 9 4.2.5. L3 multicast support . . . . . . . . . . . . . . . . 9 4.2.6. Time-to-Live Handling in Data-Plane . . . . . . . . . 9 5. L2 Overlays and Mobility Support . . . . . . . . . . . . . . 9 - 5.1. Reference Architecture and packet flows . . . . . . . . . 10 + 5.1. Reference Architecture and packet flows . . . . . . . . . 9 5.1.1. Bridged Traffic Flow: L2 Overlay use . . . . . . . . 10 5.1.2. L2 Mobility Flow . . . . . . . . . . . . . . . . . . 11 - 5.2. Implementation Considerations . . . . . . . . . . . . . . 12 - 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 12 + 5.2. Implementation Considerations . . . . . . . . . . . . . . 11 + 5.2.1. L2 Segmentation . . . . . . . . . . . . . . . . . . . 11 5.2.2. L2 Database-Mappings . . . . . . . . . . . . . . . . 12 5.2.3. Interface to the LISP Mapping System . . . . . . . . 13 5.2.4. SMR support to track L2 hosts that moved away . . . . 13 5.2.5. L2 Broadcast and Multicast traffic . . . . . . . . . 14 5.2.6. L2 Unknown Unicast Support . . . . . . . . . . . . . 14 5.2.7. Time-to-Live Handling in Data-Plane . . . . . . . . . 15 5.3. Support to ARP resolution through Mapping System . . . . 15 5.3.1. Map-Server support to ARP resolution: Packet Flow . . 15 5.3.2. ARP registrations: MAC as a locator record . . . . . 16 5.3.3. Implementation Considerations . . . . . . . . . . . . 18 @@ -128,21 +128,21 @@ An important use-case of the unified architecture is that, while most data centers are complete layer-3 routing domains, legacy applications either have not converted to IP or still use auto- discovery at layer-2 and assume all nodes in an application cluster belong to the same subnet. For these applications, the L2-overlay limits the functionality to where the legacy app lives versus having to extend layer-2 into the network. Broadcast, Unknown and Multicast traffic on the overlay are supported by either replicated unicast, or underlay (RLOC) multicast as - specified in [RFC6831] and [I-D.ietf-lisp-signal-free-multicast]. + specified in [RFC6831] and [RFC8378]. 2. Definition of Terms LISP related terms are defined as part of the LISP specification [RFC6830], notably EID, RLOC, Map-Request, Map- Reply, Map-Notify, Ingress Tunnel Router (ITR), Egress Tunnel Router (ETR), Map- Server (MS) and Map-Resolver (MR). 3. Reference System @@ -310,37 +310,37 @@ triggers sending a Map-Request for EID= to populate the map-cache of ITR A. 4.2. Implementation Considerations 4.2.1. L3 Segmentation LISP support of segmentation and multi-tenancy is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in - [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. + [RFC8060] and its use in [RFC8111]. Instance-IDs can be used to support L3 overlay segmentation, such as in extended VRFs or multi-VPN overlays. 4.2.2. L3 Database-Mappings When an end-host is attached or detected in an ETR that provides L3-overlay services and mobility, a database Mapping is registered to the mapping system with the following structure: o The EID 2-tuple (IID, IP) with its binding to a corresponding ETR locator set (IP RLOC) The registration of these EIDs MUST follow the LCAF format as defined - in [I-D.ietf-lisp-lcaf] and the specific EID record to be used is - illustrated in the following figure: + in [RFC8060] and the specific EID record to be used is illustrated in + the following figure: +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | Rsvd1 | Flags | Type = 2 | IID mask-len | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -396,30 +396,30 @@ have moved away. o Support for L3 EID records, the 2-tuple (IID, IP), for which a SMR message SHOULD be generated. 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], [I-D.ietf-lisp-signal-free-multicast] and - [I-D.coras-lisp-re]. + in in [RFC6831], [RFC8378] and [I-D.coras-lisp-re]. 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. 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. / | | \ RLOC=IP_A RLOC=IP_B RLOC=IP_C RLOC=IP_D +-+--+--+ +-+--+--+ +-+--+--+ +-+--+--+ .| xTR A |.-. .| xTR B |.-. .| xTR C |.-. .| xTR D |.-. @@ -508,23 +508,23 @@ replacing the previous one, and traffic is then forwarded to the new location. 5.2. Implementation Considerations 5.2.1. L2 Segmentation As with L3 overlays, LISP support of L2 segmentation is structured around the propagation and use of Instance-IDs, and handled as part of the EID in control plane operations. The encoding is described in - [I-D.ietf-lisp-lcaf] and its use in [I-D.ietf-lisp-ddt]. Instance- - IDs are unique to a Mapping System and MAY be used to identify the - overlay type (e.g., L2 or L3 overlay). + [RFC8060] and its use in [RFC8111]. Instance-IDs are unique to a + Mapping System and MAY be used to identify the overlay type (e.g., L2 + or L3 overlay). An Instance-ID can be used for L2 overlay segmentation. An important aspect of L2 segmentation is the mapping of VLANs to IIDs. In this case a Bridge Domain (which is the L2 equivalent to a VRF as a forwarding context) maps to an IID, a VLAN-ID may map 1:1 to a bridge domain or different VLAN-IDs on different ports may map to a common Bridge Domain, which in turn maps to an IID in the L2 overlay. When ethernet traffic is double tagged, usually the outer 802.1Q tag will be mapped to a bridge domain on a per port basis, and the inner 802.1Q tag will remain part of the payload to be handled by the @@ -539,21 +539,21 @@ 5.2.2. L2 Database-Mappings When an end-host is attached or detected in an ETR that provides L2-overlay services, a database Mapping is registered to the mapping system with the following structure: o The EID 2-tuple (IID, MAC) with its binding to a locator set (IP RLOC) The registration of these EIDs MUST follow the LCAF format as defined - in [I-D.ietf-lisp-lcaf] and as illustrated in the following figure: + in [RFC8060] and as illustrated in the following figure: +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r | Rsvd1 | Flags | Type = 2 | IID mask-len | e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -612,32 +612,31 @@ xTRs that offer L2 overlay services and are part of the same Instance-ID join a common Multicast Group. When required, this group allows ITRs to send traffic that needs to be replicated (flooded) to all ETRs participating in the L2-overlay (e.g., broadcast traffic within a subnet). When the core network (RLOC space) supports native multicast ETRs participating in the L2-overlay join a (*,G) group associated to the Instance-ID. When multicast is not available in the core network, each xTR that is part of the same instance-ID SHOULD register a (S,G) entry to the - mapping system using the procedures described in - [I-D.ietf-lisp-signal-free-multicast], where S is 0000-0000-0000/0 - and G is ffff-ffff-ffff/48. This strategy allows and ITR to know - which ETRs are part of the L2 overlay and it can head-end replicate - traffic to. + mapping system using the procedures described in [RFC8378], where S + is 0000-0000-0000/0 and G is ffff-ffff-ffff/48. This strategy allows + and ITR to know which ETRs are part of the L2 overlay and it can + head-end replicate traffic to. Following the same case, when multicast is not available in the core - network, the procedures in [I-D.ietf-lisp-signal-free-multicast] can - be used to ensure proper distribution of link-local multicast traffic - across xTRs participating in the L2 overlay. In such case, the xTRs - SHOULD join a (S,G) entry with S being 0000-0000-0000/0 and where G - is 0100-0000-0000/8. + network, the procedures in [RFC8378] can be used to ensure proper + distribution of link-local multicast traffic across xTRs + participating in the L2 overlay. In such case, the xTRs SHOULD join + a (S,G) entry with S being 0000-0000-0000/0 and where G is + 0100-0000-0000/8. 5.2.6. L2 Unknown Unicast Support An ITR attempts to resolve MAC destination misses through the Mapping System. When the destination host remains undiscovered the destination is considered an Unknown Unicast. A Map-Server SHOULD respond to a Map-Request for an undiscovered host with a Negative Map-Reply with action "Native Forward". Alternatively the action "Drop" may be used in order to suppress @@ -739,23 +738,23 @@ mapping system: o The EID 2-tuple (IID, IP) and its binding to a corresponding host MAC address. In this case both the xTRs and the Mapping System MUST support an EID-to-RLOC mapping where the MAC address is set as a locator record. In order to guarantee compatibility with current implementations of xTRs, the MAC locator record SHALL be encoded following the AFI-List - LCAF Type defined in [I-D.ietf-lisp-lcaf]. This option would also - allow adding additional attributes to the locator record, while - maintaining compatibility with legacy devices. + LCAF Type defined in [RFC8060]. This option would also allow adding + additional attributes to the locator record, while maintaining + compatibility with legacy devices. This mapping is registered with the Mapping System using the following EID record structure, +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Record TTL | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ E | Locator Count | EID mask-len | ACT |A| Reserved | I +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D | Rsvd | Map-Version Number | AFI = 16387 | @@ -967,53 +966,52 @@ DOI 10.17487/RFC6833, January 2013, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . + [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical + Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, + February 2017, . + + [RFC8111] Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. + Smirnov, "Locator/ID Separation Protocol Delegated + Database Tree (LISP-DDT)", RFC 8111, DOI 10.17487/RFC8111, + May 2017, . + + [RFC8378] Moreno, V. and D. Farinacci, "Signal-Free Locator/ID + Separation Protocol (LISP) Multicast", RFC 8378, + DOI 10.17487/RFC8378, May 2018, + . + 9.2. Informative References [I-D.coras-lisp-re] Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Maino, F., and D. Farinacci, "LISP Replication Engineering", draft-coras-lisp-re-08 (work in progress), November 2015. - [I-D.ietf-lisp-ddt] - Fuller, V., Lewis, D., Ermagan, V., Jain, A., and A. - Smirnov, "LISP Delegated Database Tree", draft-ietf-lisp- - ddt-08 (work in progress), September 2016. - - [I-D.ietf-lisp-lcaf] - Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical - Address Format (LCAF)", draft-ietf-lisp-lcaf-16 (work in - progress), October 2016. - - [I-D.ietf-lisp-signal-free-multicast] - Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", - draft-ietf-lisp-signal-free-multicast-01 (work in - progress), April 2016. - [I-D.ietf-nvo3-vxlan-gpe] - Kreeger, L. and U. Elzur, "Generic Protocol Extension for - VXLAN", draft-ietf-nvo3-vxlan-gpe-02 (work in progress), - April 2016. + Maino, F., Kreeger, L., and U. Elzur, "Generic Protocol + Extension for VXLAN", draft-ietf-nvo3-vxlan-gpe-06 (work + in progress), April 2018. [I-D.kouvelas-lisp-map-server-reliable-transport] - Cassar, C., Kouvelas, I., Lewis, D., Arango, J., and J. - Leong, "LISP Map Server Reliable Transport", draft- - kouvelas-lisp-map-server-reliable-transport-02 (work in - progress), August 2016. + Cassar, C., Leong, J., Lewis, D., Kouvelas, I., and J. + Arango, "LISP Map Server Reliable Transport", draft- + kouvelas-lisp-map-server-reliable-transport-04 (work in + progress), September 2017. Authors' Addresses Marc Portoles Comeras Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: mportole@cisco.com