Re: [lisp] LISP-GPE Review
Fabio Maino <fmaino@cisco.com> Fri, 30 March 2018 22:53 UTC
Return-Path: <fmaino@cisco.com>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9737A126B6D for <lisp@ietfa.amsl.com>; Fri, 30 Mar 2018 15:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.512
X-Spam-Level:
X-Spam-Status: No, score=-14.512 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jT-5mQnktAT4 for <lisp@ietfa.amsl.com>; Fri, 30 Mar 2018 15:53:37 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 811491200C5 for <lisp@ietf.org>; Fri, 30 Mar 2018 15:53:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=18192; q=dns/txt; s=iport; t=1522450417; x=1523660017; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=hJaV2XdXQ7lfTsNCTNfsc9Ic0y/STVjF+d7Jj65f0VM=; b=Mc83A/InKsvgPXkr7qSX9zFj4qIj1/qD3Gbmmpu7PipyYIgEFsBr6+QV BkVt4R2jl2UUFZ0VyfpD3PaqnDSlEgM3beemQ/GGwCAWTTqyOtQ7oINe+ AacWaLSsyByaGTfIcbbFnCizSnXaQFtgbKVDYNNMiuxKUaJelMH0I9aFu E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BTAQCTv75a/4YNJK1dGQEBAQEBAQEBAQEBAQcBAQEBAYMTL2FvKINciACNA4FLKYEPhWJ/hC+HQhSBZgsYC4E1AYMrAoQlITQYAQIBAQEBAQECayiFJQEBAQMBASEPAQUvBxsLGAICJgICIQYwEwYCAQGEcQMVD64bghyEVYIzDYEsgiuBCYYzJYFUP4EMIoJigk83CwEBAwGBHQgBCwQDAYMfglQChyKFMII7AjGHTCwIhVGCTYJhM4J2BoEvGiCDHYI3IoNGgQ+JFTuGK4ElHDhhcTMaCBsVOoJDCYIXF442HzAwjF8GAQgYgh8BAQ
X-IronPort-AV: E=Sophos;i="5.48,383,1517875200"; d="scan'208";a="156752177"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Mar 2018 22:53:36 +0000
Received: from [10.32.222.223] ([10.32.222.223]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w2UMrZ97006428 for <lisp@ietf.org>; Fri, 30 Mar 2018 22:53:35 GMT
To: lisp@ietf.org
References: <3B82D669-56BD-481C-884F-09A1971F06D6@gigix.net>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <088bed89-bcf0-e702-154f-d53f2a9227c3@cisco.com>
Date: Fri, 30 Mar 2018 15:53:35 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <3B82D669-56BD-481C-884F-09A1971F06D6@gigix.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/HdnIXMc5hOFO2YTTNZHSsThG9oI>
Subject: Re: [lisp] LISP-GPE Review
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Mar 2018 22:53:40 -0000
I have updated the lisp-gpe draft (https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/) to reflect Luigi's comments as discussed in London. Let me know if you have other comments. If not, this should be ready for last call. Thanks, Fabio On 3/8/18 6:05 AM, Luigi Iannone wrote: > Hi All, > > I read the LISP-GPE document. > Hereafter you can find my comments. > > Ciao > > L. > > > >> >> >> >> Internet Engineering Task Force D. Lewis >> Internet-Draft Cisco >> Intended status: Standards Track J. Lemon >> Expires: September 6, 2018 Broadcom >> P. Agarwal >> Innovium >> L. Kreeger >> >> P. Quinn >> M. Smith >> N. Yadav >> F. Maino, Ed. >> Cisco >> March 05, 2018 >> >> >> LISP Generic Protocol Extension >> draft-ietf-lisp-gpe-01 >> >> Abstract >> >> This draft describes extending the Locator/ID Separation Protocol >> (LISP), > I would add “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 >> provisions of BCP 78 and BCP 79. >> >> 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 September 6, 2018. >> >> Copyright Notice >> >> Copyright (c) 2018 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 1] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> 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 >> 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. >> >> Table of Contents >> >> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 >> 1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 >> 1.2. Definition of Terms . . . . . . . . . . . . . . . . . . . 3 >> 2. LISP Header Without Protocol Extensions . . . . . . . . . . . 3 >> 3. Generic Protocol Extension for LISP (LISP-GPE) . . . . . . . 3 >> 4. Backward Compatibility . . . . . . . . . . . . . . . . . . . 5 >> 4.1. Type of Service . . . . . . . . . . . . . . . . . . . . . 5 >> 4.2. VLAN Identifier (VID) . . . . . . . . . . . . . . . . . . 5 >> 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 >> 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 >> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 >> 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 >> 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 >> 8.2. Informative References . . . . . . . . . . . . . . . . . 7 >> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 >> >> 1. Introduction >> >> LISP, as defined in [RFC6830] > I would not cite 6830 in this document. The document defining the standard is 6830bis, hence I would refer only to the latter. > >> and extended 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 header does not specify the protocol being encapsulated and >> therefore is currently limited to encapsulating only IP packet >> payloads. Other protocols, most notably VXLAN [RFC7348] (which >> defines a similar header format to LISP), are used to encapsulate L2 >> protocols such as Ethernet. >> >> This document defines an extension for the LISP header, as defined in >> [I-D.ietf-lisp-rfc6830bis], to indicate the inner protocol, enabling >> the encapsulation of Ethernet, IP or any other desired protocol all >> the while ensuring compatibility with existing LISP deployments. >> >> A flag in the LISP header, called the P-bit, is used to signal the >> presence of the 8-bit Next Protocol field. The Next Protocol field, >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 2] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> when present, uses 8 bits of the field allocated to the echo-noncing >> and map-versioning features. The two features are still available, >> albeit with a reduced length of Nonce and Map-Version. >> >> 1.1. Conventions >> >> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", >> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this >> document are to be interpreted as described in RFC 2119 [RFC2119]. >> >> 1.2. Definition of Terms >> >> This document uses terms already defined in >> [I-D.ietf-lisp-rfc6830bis]. >> >> 2. LISP Header Without Protocol Extensions >> >> As described in the introduction, the LISP header has no protocol >> identifier that indicates the type of payload being carried. Because >> of this, LISP is limited to carry IP payloads. >> >> The LISP header [I-D.ietf-lisp-rfc6830bis] contains a series of flags >> (some defined, some reserved), a Nonce/Map-version field and an >> instance ID/Locator-status-bit field. The flags provide flexibility >> to define how the various fields are encoded. Notably, Flag bit 5 is >> the last reserved bit in the LISP header. >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |N|L|E|V|I|R|K|K| Nonce/Map-Version | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID/Locator-Status-Bits | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> LISP Header >> >> 3. Generic Protocol Extension for LISP (LISP-GPE) >> >> This document defines the following changes to the LISP header in >> order to support multi-protocol encapsulation: >> >> P Bit: Flag bit 5 is defined as the Next Protocol bit. The P bit >> MUST be set to 1 to indicate the presence of the 8 bit next >> protocol field. >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 3] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> 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. >> >> 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. >> >> This draft > s/draft/document/ > >> defines the following Next Protocol values: >> >> >> >> 0x1 : IPv4 >> >> 0x2 : IPv6 >> >> 0x3 : Ethernet >> >> 0x4 : Network Service Header [RFC8300] >> >> >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |N|L|E|V|I|P|K|K| Nonce/Map-Version | Next Protocol | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Instance ID/Locator-Status-Bits | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >> >> LISP-GPE Header >> >> >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 4] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> 4. Backward Compatibility >> >> LISP-GPE uses the same UDP destination port (4341) allocated to LISP. >> >> A LISP-GPE router MUST not encapsulate non-IP packets to a LISP >> router. A method for determining the capabilities of a LISP router >> (GPE or "legacy") is out of the scope of this draft. >> > I think this is too restrictive IMO and will will cause problem in incremental deployments. > > Imagine deploying LISP-GPE in the beta network… we cannot because this would mean having a flag day, which is impossible. > > I think would be better to have bits N, E, V to 0 when P is 1 in this way there is compatibility. > > A legacy LISP data-plane box will never participate in a mapping that is not IP over IP, hence LISP-GPE can send traffic with P=1 and Next protocol equal 1 or 2. > The legacy LISP box will receive the packet, will ignore the P bit and decapsulate as IP over IP and will work without problems. > > For the other direction, legacy LISP box sending to LISP-GPE box, everything depends again on the mappings. > Legacy LISP will talk only to xTR that locators using IP over IP, cannot do otherwise. The receiving LISP-GPE is able to handle legacy LISP traffic. > > The mappings deliver the information of "what is mapped on what" just using LCAF, but details are out of the scope of this document. > > >> When encapsulating IP packets to a LISP "legacy" router the P bit >> MUST be set to 0. >> >> 4.1. 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. >> >> 4.2. 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. >> >> 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 draft. > s/draft/document/ > >> New values are assigned via Standards Action >> [RFC5226]. >> >> +---------------+-------------+---------------+ >> | Next Protocol | Description | Reference | >> +---------------+-------------+---------------+ >> | 0 | Reserved | This Document | >> | 1 | IPv4 | This Document | >> | 2 | IPv6 | This Document | >> | 3 | Ethernet | This Document | >> | 4 | NSH | This Document | >> | 5..255 | Unassigned | | >> +---------------+-------------+---------------+ >> >> 6. Security Considerations >> >> LISP-GPE security considerations are similar to the LISP security >> considerations documented at length in [I-D.ietf-lisp-rfc6830bis]. > The reference here must be lisp threats not 6833bis. > > > >> With LISP-GPE, issues such as dataplane spoofing, flooding, and >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 5] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> traffic redirection may depend on the particular protocol payload >> encapsulated. >> >> 7. Acknowledgements >> >> A special thank you goes to Dino Farinacci for his guidance and >> detailed review. >> >> 8. References >> >> 8.1. Normative References >> >> [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate >> Requirement Levels", BCP 14, RFC 2119, >> DOI 10.17487/RFC2119, March 1997, <https://www.rfc- >> editor.org/info/rfc2119>. >> > The following can be informative. >> [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an >> IANA Considerations Section in RFCs", RFC 5226, >> DOI 10.17487/RFC5226, May 2008, <https://www.rfc- >> editor.org/info/rfc5226>. >> > I would drop this. >> [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The >> Locator/ID Separation Protocol (LISP)", RFC 6830, >> DOI 10.17487/RFC6830, January 2013, <https://www.rfc- >> editor.org/info/rfc6830>. >> >> [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID >> Separation Protocol (LISP) Map-Versioning", RFC 6834, >> DOI 10.17487/RFC6834, January 2013, <https://www.rfc- >> editor.org/info/rfc6834>. >> > This is informative. >> [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, >> <https://www.rfc-editor.org/info/rfc7348>. >> > This is informative. >> [RFC8300] Quinn, P., Ed., Elzur, U., Ed., and C. Pignataro, Ed., >> "Network Service Header (NSH)", RFC 8300, >> DOI 10.17487/RFC8300, January 2018, <https://www.rfc- >> editor.org/info/rfc8300>. >> >> >> >> >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 6] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> 8.2. Informative References >> > > This is Authoritative. >> [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-10 (work in progress), >> March 2018. >> >> Authors' Addresses >> >> Darrel Lewis >> Cisco Systems >> >> Email: darlewis@cisco.com >> >> >> John Lemon >> Broadcom >> 3151 Zanker Road >> San Jose, CA 95134 >> USA >> >> Email: john.lemon@broadcom.com >> >> >> Puneet Agarwal >> Innovium >> USA >> >> Email: puneet@acm.org >> >> >> Larry Kreeger >> USA >> >> Email: lkreeger@gmail.com >> >> >> Paul Quinn >> Cisco Systems >> >> Email: paulq@cisco.com >> >> >> Michael Smith >> Cisco Systems >> >> Email: michsmit@cisco.com >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 7] >> Internet-Draft LISP Generic Protocol Extension March 2018 >> >> >> Navindra Yadav >> Cisco Systems >> >> Email: nyadav@cisco.com >> >> >> Fabio Maino (editor) >> Cisco Systems >> San Jose, CA 95134 >> USA >> >> Email: fmaino@cisco.com >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Lewis, et al. Expires September 6, 2018 [Page 8] > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp
- [lisp] LISP-GPE Review Luigi Iannone
- Re: [lisp] LISP-GPE Review Dino Farinacci
- Re: [lisp] LISP-GPE Review Luigi Iannone
- Re: [lisp] LISP-GPE Review Fabio Maino
- Re: [lisp] LISP-GPE Review Fabio Maino