Re: [lisp] LISP-GPE Review

[Fabio Maino <[e-mail]>]

I have published rev -03 
(https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/) that fixes a 
couple of nits identified by Joel.

Changes are highlighted in the attached file.

Thanks,
Fabio



On 3/30/18 3:53 PM, Fabio Maino wrote:
> 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: [e-mail]
>>>
>>>
>>>     John Lemon
>>>     Broadcom
>>>     3151 Zanker Road
>>>     San Jose, CA  95134
>>>     USA
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>     Puneet Agarwal
>>>     Innovium
>>>     USA
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>     Larry Kreeger
>>>     USA
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>     Paul Quinn
>>>     Cisco Systems
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>     Michael Smith
>>>     Cisco Systems
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>
>>> Lewis, et al.           Expires September 6, 2018               
>>> [Page 7]
>>> Internet-Draft       LISP Generic Protocol Extension March 2018
>>>
>>>
>>>     Navindra Yadav
>>>     Cisco Systems
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>     Fabio Maino (editor)
>>>     Cisco Systems
>>>     San Jose, CA  95134
>>>     USA
>>>
>>>     Email: [e-mail]
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Lewis, et al.           Expires September 6, 2018               
>>> [Page 8]
>> _______________________________________________
>> lisp mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/lisp
>
>
> _______________________________________________
> lisp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lisp