--- 1/draft-ietf-lisp-rfc6830bis-28.txt 2020-01-08 12:13:22.404777891 -0800 +++ 2/draft-ietf-lisp-rfc6830bis-29.txt 2020-01-08 12:13:22.520780823 -0800 @@ -1,25 +1,25 @@ Network Working Group D. Farinacci Internet-Draft lispers.net Obsoletes: 6830 (if approved) V. Fuller Intended status: Standards Track vaf.net Internet Consulting -Expires: May 20, 2020 D. Meyer +Expires: July 11, 2020 D. Meyer 1-4-5.net D. Lewis Cisco Systems A. Cabellos (Ed.) UPC/BarcelonaTech - November 17, 2019 + January 8, 2020 The Locator/ID Separation Protocol (LISP) - draft-ietf-lisp-rfc6830bis-28 + draft-ietf-lisp-rfc6830bis-29 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. @@ -38,25 +38,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 20, 2020. + This Internet-Draft will expire on July 11, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 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 @@ -74,21 +74,21 @@ 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 13 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 14 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . 15 6. LISP EID-to-RLOC Map-Cache . . . . . . . . . . . . . . . . . 19 7. Dealing with Large Encapsulated Packets . . . . . . . . . . . 19 7.1. A Stateless Solution to MTU Handling . . . . . . . . . . 20 7.2. A Stateful Solution to MTU Handling . . . . . . . . . . . 21 8. Using Virtualization and Segmentation with LISP . . . . . . . 21 9. Routing Locator Selection . . . . . . . . . . . . . . . . . . 22 10. Routing Locator Reachability . . . . . . . . . . . . . . . . 24 - 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 25 + 10.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . . 26 11. EID Reachability within a LISP Site . . . . . . . . . . . . . 27 12. Routing Locator Hashing . . . . . . . . . . . . . . . . . . . 27 13. Changing the Contents of EID-to-RLOC Mappings . . . . . . . . 28 13.1. Locator-Status-Bits . . . . . . . . . . . . . . . . . . 29 13.2. Database Map-Versioning . . . . . . . . . . . . . . . . 29 14. Multicast Considerations . . . . . . . . . . . . . . . . . . 30 15. Router Performance Considerations . . . . . . . . . . . . . . 31 16. Security Considerations . . . . . . . . . . . . . . . . . . . 32 17. Network Management Considerations . . . . . . . . . . . . . . 33 18. Changes since RFC 6830 . . . . . . . . . . . . . . . . . . . 33 @@ -1007,21 +1007,22 @@ 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. For example, an 802.1Q VLAN tag or VPN identifier could be used as a 24-bit Instance ID. See [I-D.ietf-lisp-vpn] for LISP VPN use-case details. Participants within a LISP deployment must agree on the meaning of - Instance ID values. + Instance ID values. The source and destination EIDs MUST belong to + the same Instance ID. 9. Routing Locator Selection The Map-Cache contains the state used by ITRs and PITRs to encapsulate packets. When an ITR/PITR receives a packet from inside the LISP site to a destination outside of the site a longest-prefix match lookup of the EID is done to the Map-Cache (see Section 6). The lookup returns a single Locator-Set containing a list of RLOCs corresponding to the EID's topological location. Each RLOC in the Locator-Set is associated with a 'Priority' and 'Weight', this @@ -1209,38 +1210,39 @@ other Locator reachability algorithms. Once the ITR determines that the path to the ETR is down, it can switch to another Locator for that EID-Prefix. Note that "ITR" and "ETR" are relative terms here. Both devices MUST be implementing both ITR and ETR functionality for the echo nonce mechanism to operate. The ITR and ETR MAY both go into the echo-nonce-request state at the same time. The number of packets sent or the time during which echo - nonce requests are sent is an implementation-specific setting. - However, when an ITR is in the echo-nonce-request state, it can echo - the ETR's nonce in the next set of packets that it encapsulates and - subsequently continue sending echo-nonce-request packets. + nonce requests are sent is an implementation-specific setting. In + this case, an xTR receiving the echo-nonce-request packets will + suspend the echo-nonce-request state and setup a 'echo-nonce-request- + state' timer. After the 'echo-nonce-request-state' timer expires it + will resume the echo-nonce-request state. This mechanism does not completely solve the forward path reachability problem, as traffic may be unidirectional. That is, the ETR receiving traffic at a site MAY not be the same device as an ITR that transmits traffic from that site, or the site-to-site traffic is unidirectional so there is no ITR returning traffic. The echo-nonce algorithm is bilateral. That is, if one side sets the E-bit and the other side is not enabled for echo-noncing, then the echoing of the nonce does not occur and the requesting side may - erroneously consider the Locator unreachable. An ITR SHOULD only set - the E-bit in an encapsulated data packet when it knows the ETR is - enabled for echo-noncing. This is conveyed by the E-bit in the RLOC- - probe Map-Reply message. + erroneously consider the Locator unreachable. An ITR SHOULD set the + E-bit in an encapsulated data packet when it knows the ETR is enabled + for echo-noncing. This is conveyed by the E-bit in the RLOC-probe + Map-Reply message. Many implementations default to not advertising they are echo-nonce capable in Map-Reply messages and so RLOC-probing tends to be used for RLOC reachability. The echo-nonce mechanism SHOULD NOT be used over the public Internet and SHOULD only be used in trusted and closed deployments. Refer to Section 16 for security issues regarding this mechanism. 11. EID Reachability within a LISP Site @@ -1582,22 +1584,22 @@ 20.1. Normative References [I-D.ietf-lisp-6834bis] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", draft-ietf- lisp-6834bis-04 (work in progress), August 2019. [I-D.ietf-lisp-rfc6833bis] Farinacci, D., Maino, F., Fuller, V., and A. Cabellos- Aparicio, "Locator/ID Separation Protocol (LISP) Control- - Plane", draft-ietf-lisp-rfc6833bis-25 (work in progress), - June 2019. + Plane", draft-ietf-lisp-rfc6833bis-26 (work in progress), + November 2019. [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, . [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate @@ -1654,22 +1656,22 @@ . [I-D.ietf-lisp-introduction] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-introduction-13 (work in progress), April 2015. [I-D.ietf-lisp-vpn] Moreno, V. and D. Farinacci, "LISP Virtual Private - Networks (VPNs)", draft-ietf-lisp-vpn-04 (work in - progress), May 2019. + Networks (VPNs)", draft-ietf-lisp-vpn-05 (work in + progress), November 2019. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, .