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: A0BeAACV/KNb/51dJa1bGgEBAQEBAgEBAQEIAQEBAYFTgVYFKmV/KINzlESCDXiVaoFmCyOESQKDQiE3FQEDAQECAQECbRwMhTkBBRoJJDIOAgsSBicDAgIbKwMOBgEMBgIBAYMdAYIBD6N8gS4fgwqBCgc9hQ8FBYpqF4FBP4ESJ4I2NYMbAgMBgSoBCwcBJYJ7glcCiCIgBCyFdY4HCYZDgwaGVQYXgUSEUIJfhi+LcokDgVgiZHEzGggbFYMngiUXewEDBIdXhV4fMIsmDxeCJgEB
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 > ----------------------------------------------------------------------
- [lisp] Tsvart last call review of draft-ietf-lisp… Magnus Westerlund
- Re: [lisp] Tsvart last call review of draft-ietf-… Fabio Maino
- Re: [lisp] Tsvart last call review of draft-ietf-… BRUNGARD, DEBORAH A
- Re: [lisp] Tsvart last call review of draft-ietf-… Magnus Westerlund
- Re: [lisp] Tsvart last call review of draft-ietf-… Magnus Westerlund
- Re: [lisp] Tsvart last call review of draft-ietf-… BRUNGARD, DEBORAH A
- Re: [lisp] Tsvart last call review of draft-ietf-… Magnus Westerlund
- Re: [lisp] Tsvart last call review of draft-ietf-… Fabio Maino
- Re: [lisp] Tsvart last call review of draft-ietf-… Fabio Maino
- Re: [lisp] Tsvart last call review of draft-ietf-… Luigi Iannone
- Re: [lisp] Tsvart last call review of draft-ietf-… Fabio Maino