Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05

Fabio Maino <fmaino@cisco.com> Thu, 20 September 2018 20:03 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 55A1D130E2D; Thu, 20 Sep 2018 13:03:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-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 cMSItOPvSM6z; Thu, 20 Sep 2018 13:03:55 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D3130DF6; Thu, 20 Sep 2018 13:03:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27676; q=dns/txt; s=iport; t=1537473834; x=1538683434; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=y9fKvxhiXB2vAgXaefotbxtipXqbLZwtW/2ah+mYrxg=; b=YBFPaXQNt6UPJghWJCn8oizHo4syXRAuwoS8aWK/H3WLXGAMdqX9PtDp 8C61UJIWyEk2BDUaBBEUqsT+I9J+Ph5UsGybfKMVCyeb0qLaGaC29gW5N pN3rHT6i5BscYn4hz4t4OaCf2QuDy6zTo9Sd1h7lT8mm4kGiGa+RwpijS A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BeAACV/KNb/51dJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYFTgVYFKmV/KINzlESCDXiVaoFmCyOESQKDQiE3FQEDAQECAQE?= =?us-ascii?q?CbRwMhTkBBRoJJDIOAgsSBicDAgIbKwMOBgEMBgIBAYMdAYIBD6N8gS4fgwq?= =?us-ascii?q?BCgc9hQ8FBYpqF4FBP4ESJ4I2NYMbAgMBgSoBCwcBJYJ7glcCiCIgBCyFdY4?= =?us-ascii?q?HCYZDgwaGVQYXgUSEUIJfhi+LcokDgVgiZHEzGggbFYMngiUXewEDBIdXhV4?= =?us-ascii?q?fMIsmDxeCJgEB?=
X-IronPort-AV: E=Sophos;i="5.54,281,1534809600"; d="scan'208,217";a="451942747"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Sep 2018 20:03:52 +0000
Received: from [10.32.173.108] ([10.32.173.108]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTP id w8KK3pvi021391; Thu, 20 Sep 2018 20:03:51 GMT
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, tsv-art@ietf.org
Cc: lisp@ietf.org, ietf@ietf.org, draft-ietf-lisp-gpe.all@ietf.org
References: <153553422964.14784.628403975182959075@ietfa.amsl.com> <f5930d34-4e3b-a800-4c59-b8b46fd78b73@cisco.com> <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com>
From: Fabio Maino <fmaino@cisco.com>
Message-ID: <8856bfce-8d2f-baae-d85c-fea09ba86f69@cisco.com>
Date: Thu, 20 Sep 2018 13:03:51 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5dd519c0-6810-8596-37e9-377e38175a7d@ericsson.com>
Content-Type: multipart/alternative; boundary="------------DB63CE837FBE5182ABD673B0"
Content-Language: en-US
X-Outbound-SMTP-Client: 10.32.173.108, [10.32.173.108]
X-Outbound-Node: rcdn-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/HLEPIWWsiE5V-ebaMHs1ixD3dOk>
Subject: Re: [lisp] Tsvart last call review of draft-ietf-lisp-gpe-05
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 20 Sep 2018 20:03:59 -0000

Thanks Magnus,
I'll consolidate the changes we have agreed so far in the next rev that 
I plan to publish later today.

I'll then work on the comments on this email and will send you the 
corresponding actions.

Fabio

On 9/20/18 2:39 AM, Magnus Westerlund wrote:
>
> Hi Fabio,
>
> Most of the below text is excellent. Some comments inline for needed 
> clarifications and additions.
>
> On 9/18/2018 9:52 PM, Fabio Maino wrote:
>> Hi Magnus,
>> thanks for your comments.
>>
>> I think I see the points you are making.
>>
>> I'll add the section 3.1 below to specify the general transport 
>> requirements for the registration of new LISP-GPE payloads, and I 
>> will introduce two subsections to instantiate those requirements for 
>> Ethernet and NSH (section 4.2 and 4.3 will be moved here). In the 
>> "IANA Considerations" section I'll refer to this new section 3.1 as a 
>> requirement for registration of new encapsulated payload.
>>
>> "3.1 Payload Specific Transport Interactions
>>
>> To ensure that protocols that are encapsulated in LISP-GPE will work 
>> well from a transport interaction perspective, the specification of a 
>> new encapsulated payload MUST contain an analysis of how LISP-GPE 
>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>> Congestion Notification (ECN) bits whenever they apply to the new 
>> encapsulated payload.
>>
>> For IP payloads, section 5.3 of [draft-ietf-lisp-rfc6830bis] 
>> specifies how to handle UDP Checksums encouraging implementors to 
>> consider UDP checksum usage guidelines in section 3.4 of [RFC8085] 
>> when it is desirable to protect UDP and LISP headers against 
>> corruption. Each new encapsulated payloads, when registered with 
>> LISP-GPE, MUST be accompanied by a similar analysis.
>>
>> Encapsulated payloads may have a priority field that may or may not 
>> be mapped to the DSCP field of the outer IP header (part of Type of 
>> Service in IPv4 or Traffic Class in IPv6). Such new encapsulated 
>> payloads, when registered with LISP-GPE, MUST be accompanied by an 
>> analysis similar to the one performed in Section 3.1.1 of this 
>> document for Ethernet payloads.
>>
>> Encapsulated payloads may have Explicit Congestion Notification 
>> mechanisms that may or may not be mapped to the outer IP header ECN 
>> field. Such new encapsulated payolads, when registered with LISP-GPE, 
>> MUST  be accompanied by a set of guidelines derived from 
>> [draft-ietf-tsvwg-ecn-encap-guidelines] and [RFC6040].
>>
>> The rest of this section specifies payload specific transport 
>> interactions considerations for the two new LISP-GPE encapsulated 
>> payloads specified in this document: Ethernet and NSH.
>>
>> 3.1.1 Payload Specific Transport Interactions for Ethernet 
>> Encapsulated Payloads
>>
>> The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to Ethernet Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP and Ethernet headers against corruption.
>
> So this is not the necessary documentation of the analysis that 
> IP/UDP(with zero checksum)/LISP(with GPE)/Ethernet is a safe to use. 
> There needs to be an analysis here to verify that this protocol 
> combination do work. You will actually have to discuss how the 
> Ethernet encapsulation fulfills the requirements listed in Section 4 
> of RFC 6936.
>
> https://datatracker.ietf.org/doc/rfc7510/ is an example where such an 
> analysis was included. I would also note the applicability limitations 
> this has.
>
> Which actually brings up an additional issue for Ethernet 
> encapsulation. For IP the assumption is that the IP traffic that is 
> encapsulated is congestion controlled. This assumption is even less 
> certain when having Ethernet. Thus, some consideration of that issue 
> is likely needed.
>
>
>>
>> When a LISP-GPE router performs Ethernet encapsulation, the inner 
>> 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 as per guidelines provided by [RFC8325].
>
> I don't know enough about IEEE and the various versions of Ethernet 
> and WLAN here to be certain that 802.1Q PCP's can be mapped directly 
> to the 802.11 User Priorities discussed in RFC8325. Please investigate 
> if they are the same, and if they are the same priorities, then make a 
> explicit statement that they are applicable.
>
>>
>> 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.
>>
>> 3.1.2 Payload Specific Transport Interactions for NSH Encapsulated 
>> Payloads
>>
>> The UDP Checksum considerations specified in section 5.3 of 
>> [draft-ietf-lisp-rfc6830bis] apply to NSH Encapsulated Payloads. 
>> Implementors are encouraged to consider the UDP checksum usage 
>> guidelines in section 3.4 of [RFC8085] when it is desirable to 
>> protect UDP, LISP, and NSH headers against corruption.
>
> Same as for Ethernet also the NSH header needs to have a documented 
> analsysis of fulfillment of the requirements.
>
>
>>
>> When a LISP-GPE router performs an NSH encapsulation, DSCP and ECN 
>> values MAY be mapped as specified for the Next Protocol encapsulated 
>> by NSH (namely IPv4, IPv6 and Ethernet)."
>>
>>
>> I will also add a paragraph to "Iana Considerations" that says:
>>
>>
>> "To ensure that protocols that are encapsulated in LISP-GPE will work 
>> well from a transport interaction perspective, the registration of a 
>> new encapsulated payload MUST contain an analysis of how LISP-GPE 
>> SHOULD deal with outer UDP Checksum, DSCP mapping, and Explicit 
>> Congestion Notification (ECN) bits whenever they apply to the new 
>> encapsulated payload. The analysis for the new encapsulated payload 
>> registered in this document is in section 3.1."
>>
>> Please, let me know if this address your comments.
>>
>> Thanks,
>> Fabio
>>
>>
>>
>> On 8/29/18 2:17 AM, Magnus Westerlund wrote:
>>> Reviewer: Magnus Westerlund
>>> Review result: Not Ready
>>>
>>> This document has been reviewed as part of the transport area directorate's
>>> ongoing effort to review key IETF documents. These comments were written
>>> primarily for the transport area directors, but are copied to the document's
>>> authors and WG for their information and to allow them to address any issues
>>> raised.
>>>
>>> When done at the time of IETF Last Call, the authors should consider this
>>> review together with any other last-call comments they receive.
>>> Please always CCtsv-art@ietf.org  if you reply to or forward this review.
>>>
>>> Issue A.
>>>
>>> The reason I state Not Ready has to do with this documents failure to consider
>>> the use of zero checksum for IPv6 when tunneling other things than IP. The none
>>> GPE version is limited to tunnel IP for which the analysis for use of zero
>>> checksum has been done. Each of the new tunneled protocols that are specified
>>> in this document, i.e. ethernet and NHS, will need to perform the analysis if
>>> they are safe to use zero checksum or not, and if not disallow zero checksum
>>> for IPv6/UDP. The documetn also need a requirement in the registration
>>> requirements to perform this analysis and defined if zero checksum is
>>> acceptable or not.
>>>
>>> Citing Section 5.3 of draft-ietf-lisp-rfc6830bis
>>>
>>>     UDP Checksum:  The 'UDP Checksum' field SHOULD be transmitted as zero
>>>        by an ITR for either IPv4 [RFC0768] and IPv6 encapsulation
>>>        [RFC6935] [RFC6936].  When a packet with a zero UDP checksum is
>>>        received by an ETR, the ETR MUST accept the packet for
>>>        decapsulation.  When an ITR transmits a non-zero value for the UDP
>>>        checksum, it MUST send a correctly computed value in this field.
>>>        When an ETR receives a packet with a non-zero UDP checksum, it MAY
>>>        choose to verify the checksum value.  If it chooses to perform
>>>        such verification, and the verification fails, the packet MUST be
>>>        silently dropped.  If the ETR chooses not to perform the
>>>        verification, or performs the verification successfully, the
>>>        packet MUST be accepted for decapsulation.  The handling of UDP
>>>        zero checksums over IPv6 for all tunneling protocols, including
>>>        LISP, is subject to the applicability statement in [RFC6936].
>>>
>>> The issue is that when LISP encapsulate other protocols the impact of a
>>> missdelivered tunnel packet to the wrong ETR can have different impacts. As
>>> well as errors in the headers of the encapsulated packet that may be assumed to
>>> be protected by the encapsulating layer. Thus, individual analysis of each
>>> protocol that are tunneled are needed.
>>>
>>> B.) 4.2.  Type of Service
>>>
>>>     When a LISP-GPE router performs Ethernet encapsulation, the inner
>>>     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.
>>>
>>> Any recommendation about how to perform that mapping? Maybe parts of
>>> https://datatracker.ietf.org/doc/rfc8325/  are relevant in this context.
>>>
>>> C. General case of 4.2:
>>>
>>> I expect other protocols than Ethernet may have a priority field that may or
>>> may not be mapped to the DSCP field of the tunnel packet.
>>>
>>> I would expect that for new protocol registration in the LISP-GPE Next Protocol
>>> Registry should consider this. Thus, it would be good to note that such
>>> considerations are needed and part of what should be evaluated for new
>>> registrations.
>>>
>>> D. ECN handling
>>>
>>> Section 5.3 of draft-ietf-lisp-rfc6830bis states:
>>>
>>>     o  The 'Explicit Congestion Notification' (ECN) field (bits 6 and 7
>>>        of the IPv6 'Traffic Class' field) requires special treatment in
>>>        order to avoid discarding indications of congestion [RFC3168].
>>>        ITR encapsulation MUST copy the 2-bit 'ECN' field from the inner
>>>        header to the outer header.  Re-encapsulation MUST copy the 2-bit
>>>        'ECN' field from the stripped outer header to the new outer
>>>        header.
>>>
>>> The above rules may not be applicable for all transport protocols. Thus I think
>>> it is required that one do protocol specific considerations of ECN. TSVWG are
>>> working on recommendations for tunnels handling of  ECN here, see:
>>> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-ecn-encap-guidelines/  Thus,
>>> my expectation would be to ensure that the registered protocols have defined
>>> ECN handling, explicitly or by reference. Secondly that registration
>>> requirement states the need for this consideration.
>>>
>>> Summary: To ensure that future added protocols that are encapsulated will work
>>> well from a transport interaction perspective there need to be a requirement on
>>> new registration to consider and define how they use zero checksum, any DSCP
>>> mapping and ECN bits. In addition the current document needs to ensure these
>>> things are clearly specified for the encapsulated protocols in this document.
>>>
>>>
>>
> -- 
>
> Magnus Westerlund
>
> ----------------------------------------------------------------------
> Network Architecture & Protocols, Ericsson Research
> ----------------------------------------------------------------------
> Ericsson AB                 | Phone  +46 10 7148287
> Torshamnsgatan 23           | Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden | mailto:magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------