--- 1/draft-ietf-lisp-rfc6830bis-06.txt 2017-11-11 17:13:09.737240352 -0800 +++ 2/draft-ietf-lisp-rfc6830bis-07.txt 2017-11-11 17:13:09.849243033 -0800 @@ -1,22 +1,22 @@ Network Working Group D. Farinacci Internet-Draft V. Fuller Intended status: Standards Track D. Meyer -Expires: May 3, 2018 D. Lewis +Expires: May 15, 2018 D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - October 30, 2017 + November 11, 2017 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-06 + draft-ietf-lisp-rfc6830bis-07 Abstract This document describes the data-plane protocol for the Locator/ID Separation Protocol (LISP). LISP defines two namespaces, End-point Identifiers (EIDs) that identify end-hosts and Routing Locators (RLOCs) that identify network attachment points. With this, LISP effectively separates control from data, and allows routers to create overlay networks. LISP-capable routers exchange encapsulated packets according to EID-to-RLOC mappings stored in a local map-cache. The @@ -35,21 +35,21 @@ 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 3, 2018. + This Internet-Draft will expire on May 15, 2018. Copyright Notice Copyright (c) 2017 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 @@ -104,26 +104,27 @@ 19. Security Considerations . . . . . . . . . . . . . . . . . . . 43 20. Network Management Considerations . . . . . . . . . . . . . . 44 21. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 21.1. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . 44 22. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 22.1. Normative References . . . . . . . . . . . . . . . . . . 44 22.2. Informative References . . . . . . . . . . . . . . . . . 47 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 51 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 51 B.1. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 - B.2. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52 - B.3. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 - B.4. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 52 - B.5. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 - B.6. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 - B.7. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 + B.2. Changes to draft-ietf-lisp-rfc6830bis-06 . . . . . . . . 52 + B.3. Changes to draft-ietf-lisp-rfc6830bis-05 . . . . . . . . 52 + B.4. Changes to draft-ietf-lisp-rfc6830bis-04 . . . . . . . . 52 + B.5. Changes to draft-ietf-lisp-rfc6830bis-03 . . . . . . . . 53 + B.6. Changes to draft-ietf-lisp-rfc6830bis-02 . . . . . . . . 53 + B.7. Changes to draft-ietf-lisp-rfc6830bis-01 . . . . . . . . 53 + B.8. Changes to draft-ietf-lisp-rfc6830bis-00 . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 1. Introduction This document describes the Locator/Identifier Separation Protocol (LISP). LISP is an encapsulation protocol built around the fundamental idea of separating the topological location of a network attachment point from the node's identity [CHIAPPA]. As a result LISP creates two namespaces: Endpoint Identifiers (EIDs), that are used to identify end-hosts (e.g., nodes or Virtual Machines) and @@ -1016,26 +1017,25 @@ advertised by the ITR in the ICMP Unreachable/Fragmentation- Needed message is the effective MTU minus the LISP encapsulation length. Even though this mechanism is stateful, it has advantages over the stateless IP fragmentation mechanism, by not involving the destination host with reassembly of ITR fragmented packets. 8. Using Virtualization and Segmentation with LISP - When multiple organizations inside of a LISP site are using private - addresses [RFC1918] as EID-Prefixes, their address spaces MUST remain - segregated due to possible address duplication. An Instance ID in - the address encoding can aid in making the entire AFI-based address - unique. See IANA Considerations of [I-D.ietf-lisp-rfc6833bis] for - details on possible address encodings. + There are several cases where segregation is needed at the EID level. + For instance, this is the case for deployments containing overlapping + addresses, traffic isolation policies or multi-tenant virtualization. + For these and other scenarios where segregation is needed, Instance + IDs are used. An Instance ID can be carried in a LISP-encapsulated packet. An ITR that prepends a LISP header will copy a 24-bit value used by the LISP router to uniquely identify the address space. The value is copied to the 'Instance ID' field of the LISP header, and the I-bit is set to 1. When an ETR decapsulates a packet, the Instance ID from the LISP header is used as a table identifier to locate the forwarding table to use for the inner destination EID lookup. @@ -2383,20 +2383,27 @@ documents were being prepared for IESG last call, and for his meticulous reviews and detailed commentaries on the 7 working group last call documents progressing toward standards-track RFCs. Appendix B. Document Change Log [RFC Editor: Please delete this section on publication as RFC.] B.1. Changes to draft-ietf-lisp-rfc6830bis-06 + o Posted November 2017. + + o Rephrase how Instance-IDs are used and don't refer to [RFC1918] + addresses. + +B.2. Changes to draft-ietf-lisp-rfc6830bis-06 + o Posted October 2017. o Put RTR definition before it is used. o Rename references that are now working group drafts. o Remove "EIDs MUST NOT be used as used by a host to refer to other hosts. Note that EID blocks MAY LISP RLOCs". o Indicate what address-family can appear in data packets. @@ -2404,61 +2411,61 @@ o ETRs may, rather than will, be the ones to send Map-Replies. o Recommend, rather than mandate, max encapsulation headers to 2. o Reference VPN draft when introducing Instance-ID. o Indicate that SMRs can be sent when ITR/ETR are in the same node. o Clarify when private addreses can be used. -B.2. Changes to draft-ietf-lisp-rfc6830bis-05 +B.3. Changes to draft-ietf-lisp-rfc6830bis-05 o Posted August 2017. o Make it clear that a Reencapsulating Tunnel Router is an RTR. -B.3. Changes to draft-ietf-lisp-rfc6830bis-04 +B.4. Changes to draft-ietf-lisp-rfc6830bis-04 o Posted July 2017. o Changed reference of IPv6 RFC2460 to RFC8200. o Indicate that the applicability statement for UDP zero checksums over IPv6 adheres to RFC6936. -B.4. Changes to draft-ietf-lisp-rfc6830bis-03 +B.5. Changes to draft-ietf-lisp-rfc6830bis-03 o Posted May 2017. o Move the control-plane related codepoints in the IANA Considerations section to RFC6833bis. -B.5. Changes to draft-ietf-lisp-rfc6830bis-02 +B.6. Changes to draft-ietf-lisp-rfc6830bis-02 o Posted April 2017. o Reflect some editorial comments from Damien Sausez. -B.6. Changes to draft-ietf-lisp-rfc6830bis-01 +B.7. Changes to draft-ietf-lisp-rfc6830bis-01 o Posted March 2017. o Include references to new RFCs published. o Change references from RFC6833 to RFC6833bis. o Clarified LCAF text in the IANA section. o Remove references to "experimental". -B.7. Changes to draft-ietf-lisp-rfc6830bis-00 +B.8. Changes to draft-ietf-lisp-rfc6830bis-00 o Posted December 2016. o Created working group document from draft-farinacci-lisp -rfc6830-00 individual submission. No other changes made. Authors' Addresses Dino Farinacci Cisco Systems