--- 1/draft-ietf-lisp-gpe-03.txt 2018-07-19 21:13:11.492435051 -0700 +++ 2/draft-ietf-lisp-gpe-04.txt 2018-07-19 21:13:11.512435536 -0700 @@ -1,24 +1,24 @@ Internet Engineering Task Force F. Maino, Ed. Internet-Draft Cisco Intended status: Standards Track J. Lemon -Expires: October 7, 2018 Broadcom +Expires: January 20, 2019 Broadcom P. Agarwal Innovium D. Lewis M. Smith Cisco - April 5, 2018 + July 19, 2018 LISP Generic Protocol Extension - draft-ietf-lisp-gpe-03 + draft-ietf-lisp-gpe-04 Abstract This document describes extending the Locator/ID Separation Protocol (LISP) Data-Plane, via changes to the LISP header, to support multi- protocol encapsulation. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -27,21 +27,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 http://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 October 7, 2018. + This Internet-Draft will expire on January 20, 2019. Copyright Notice 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -61,21 +61,21 @@ 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 4 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Type of Service . . . . . . . . . . . . . . . . . . . . . 6 4.3. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 6 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements and Contributors . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 - 8.2. Informative References . . . . . . . . . . . . . . . . . 7 + 8.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction LISP Data-Plane, as defined in in [I-D.ietf-lisp-rfc6830bis], defines an encapsulation format that carries IPv4 or IPv6 (henceforth referred to as IP) packets in a LISP header and outer UDP/IP transport. The LISP Data-Plane header does not specify the protocol being @@ -139,23 +139,24 @@ P = 0 indicates that the payload MUST conform to LISP as defined in [I-D.ietf-lisp-rfc6830bis]. Flag bit 5 was chosen as the P bit because this flag bit is currently unallocated. Next Protocol: The lower 8 bits of the first 32-bit word are used to carry a Next Protocol. This Next Protocol field contains the protocol of the encapsulated payload packet. LISP uses the lower 24 bits of the first word for either a nonce, - an echo-nonce, or to support map-versioning [RFC6834]. These are - all optional capabilities that are indicated in the LISP header by - setting the N, E, and the V bit respectively. + an echo-nonce, or to support map-versioning + [I-D.ietf-lisp-6834bis]. These are all optional capabilities that + are indicated in the LISP header by setting the N, E, and the V + bit respectively. When the P-bit and the N-bit are set to 1, the Nonce field is the middle 16 bits. When the P-bit and the V-bit are set to 1, the Version field is the middle 16 bits. When the P-bit is set to 1 and the N-bit and the V-bit are both 0, the middle 16-bits are set to 0. @@ -185,21 +186,21 @@ The next Section describes a method to determine the Data-Plane capabilities of a LISP ETR, based on the use of the "Multiple Data- Planes" LCAF type defined in [RFC8060]. Other mechanisms can be used, including static xTR configuration, but are out of the scope of this document. When encapsulating IP packets to a non LISP-GPE capable router the P bit MUST be set to 0. - A LISP-GPE router MUST not encapsulate non-IP packets to a non LISP- + A LISP-GPE router MUST NOT encapsulate non-IP packets to a non LISP- GPE capable router. 4.1. Use of "Multiple Data-Planes" LCAF to Determine ETR Capabilities The LISP Canonical Address Format (LCAF) [RFC8060] defines the "Multiple Data-Planes" LCAF type, that can be included by an ETR in a Map-Reply to encode the encapsularion formats supported by a given RLOC. In this way an ITR can be made aware of the capability to support LISP-GPE on a given RLOC of that ETR. @@ -224,36 +225,37 @@ g Bit: The RLOCs listed in the AFI-encoded addresses in the next longword can accept LISP-GPE (Generic Protocol Extension) encapsulation using destination UDP port 4341 All other fields: As defined in [RFC8060] 4.2. Type of Service When a LISP-GPE router performs Ethernet encapsulation, the inner - 802.1Q [IEEE8021Q] priority code point (PCP) field MAY be mapped from - the encapsulated frame to the Type of Service field in the outer IPv4 - header, or in the case of IPv6 the 'Traffic Class' field + 802.1Q [IEEE.802.1Q_2014] priority code point (PCP) field MAY be + mapped from the encapsulated frame to the Type of Service field in + the outer IPv4 header, or in the case of IPv6 the 'Traffic Class' + field 4.3. VLAN Identifier (VID) When a LISP-GPE router performs Ethernet encapsulation, the inner - header 802.1Q [IEEE8021Q] VLAN Identifier (VID) MAY be mapped to, or - used to determine the LISP Instance ID field. + header 802.1Q [IEEE.802.1Q_2014] VLAN Identifier (VID) MAY be mapped + to, or used to determine the LISP Instance ID field. 5. IANA Considerations IANA is requested to set up a registry of LISP-GPE "Next Protocol". These are 8-bit values. Next Protocol values in the table below are defined in this document. New values are assigned via Standards - Action [RFC5226]. The protocols that are being assigned values do + Action [RFC8126]. The protocols that are being assigned values do not themselves need to be IETF standards track protocols. +---------------+-------------+---------------+ | Next Protocol | Description | Reference | +---------------+-------------+---------------+ | 0 | Reserved | This Document | | 1 | IPv4 | This Document | | 2 | IPv6 | This Document | | 3 | Ethernet | This Document | | 4 | NSH | This Document | @@ -294,59 +296,66 @@ o Larry Kreeger o John Lemon, Broadcom o Puneet Agarwal, Innovium 8. References 8.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-00 (work in progress), July 2018. + [I-D.ietf-lisp-rfc6830bis] Farinacci, D., Fuller, V., Meyer, D., Lewis, D., and A. Cabellos-Aparicio, "The Locator/ID Separation Protocol - (LISP)", draft-ietf-lisp-rfc6830bis-12 (work in progress), - March 2018. + (LISP)", draft-ietf-lisp-rfc6830bis-14 (work in progress), + July 2018. + + [IEEE.802.1Q_2014] + IEEE, "IEEE Standard for Local and metropolitan area + networks--Bridges and Bridged Networks", IEEE 802.1Q-2014, + DOI 10.1109/ieeestd.2014.6991462, December 2014, + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . - [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID - Separation Protocol (LISP) Map-Versioning", RFC 6834, - DOI 10.17487/RFC6834, January 2013, . - 8.2. Informative References - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", RFC 5226, - DOI 10.17487/RFC5226, May 2008, . - [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, . [RFC7835] Saucez, D., Iannone, L., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Threat Analysis", RFC 7835, DOI 10.17487/RFC7835, April 2016, . [RFC8060] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Address Format (LCAF)", RFC 8060, DOI 10.17487/RFC8060, February 2017, . + [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for + Writing an IANA Considerations Section in RFCs", BCP 26, + RFC 8126, DOI 10.17487/RFC8126, June 2017, + . + [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., "Network Service Header (NSH)", RFC 8300, DOI 10.17487/RFC8300, January 2018, . Authors' Addresses Fabio Maino (editor) Cisco Systems San Jose, CA 95134