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

Magnus Westerlund <magnus.westerlund@ericsson.com> Thu, 20 September 2018 08:14 UTC

Return-Path: <magnus.westerlund@ericsson.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 7F442130E8D for <lisp@ietfa.amsl.com>; Thu, 20 Sep 2018 01:14:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 IyJKuHN5wiLz for <lisp@ietfa.amsl.com>; Thu, 20 Sep 2018 01:14:25 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61F6A130E50 for <lisp@ietf.org>; Thu, 20 Sep 2018 01:14:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1537431259; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YotHdRlQlhcGARnc2+VkzQ3spalJe6J3RLr1eTLPap8=; b=VbYCmLKGVGb5S6zpVYsvbvoDXvrJ5SBtAIsyYaRL1fC/dPjKo9u8lR6aPae410rV W5uKUXxBYYk31bcBkJfAGptcUvz8YwVJuvBXrLx0MNQMdnamS0PPCYiO3LXMoSuN XfrkEa3+g9vCJaKwr1H8GDxlG04MCgyoAkK9X9T9YDM=;
X-AuditID: c1b4fb30-fe1ff700000055da-3d-5ba356dbb463
Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 3B.6A.21978.BD653AB5; Thu, 20 Sep 2018 10:14:19 +0200 (CEST)
Received: from [100.94.33.105] (153.88.183.153) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Thu, 20 Sep 2018 10:14:18 +0200
To: "BRUNGARD, DEBORAH A" <db3546@att.com>, Fabio Maino <fmaino@cisco.com>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "lisp@ietf.org" <lisp@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-lisp-gpe.all@ietf.org" <draft-ietf-lisp-gpe.all@ietf.org>
References: <153553422964.14784.628403975182959075@ietfa.amsl.com> <f5930d34-4e3b-a800-4c59-b8b46fd78b73@cisco.com> <F64C10EAA68C8044B33656FA214632C88841A9D9@MISOUT7MSGUSRDE.ITServices.sbc.com>
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
Message-ID: <da339b29-5294-c54e-353d-a08924637cbf@ericsson.com>
Date: Thu, 20 Sep 2018 10:14:18 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
In-Reply-To: <F64C10EAA68C8044B33656FA214632C88841A9D9@MISOUT7MSGUSRDE.ITServices.sbc.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090805030703070701080904"
X-Originating-IP: [153.88.183.153]
X-ClientProxiedBy: ESESSMB502.ericsson.se (153.88.183.163) To ESESSMB502.ericsson.se (153.88.183.163)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrMIsWRmVeSWpSXmKPExsUyM2J7he7tsMXRBofb+Cwud3WzW7R+3cdo cWHHP0aLZxvns1hMOatuMWvPIhYHNo+X/XMYPab83sjqsWTJT6YA5igum5TUnMyy1CJ9uwSu jCc/VrEXtJ5kqmh4/IWpgfFEO1MXIyeHhICJxId3a9i7GLk4hASOMkq0HPrJCJIQEnjPKPH9 SDqILSxgJ/G1rYUZxBYRKJZYd3MuI0gDs0Avo0T3vP0scN1dHUfAutkELCRu/mhk62Lk4OAV sJdYf8oRJMwioCqxZs5DJpCwqEC0xKf/mSBhXgFBiZMzn7CA2JwCURJTv35gg5jfzSix+90c doiDtCUamjpYIa5Wkrg+7zoLhJ0ucXnFHvYJjIKzkMyahawfJMEsECbx48NVNghbXOLWk/lM ELaZxLzND5khbG2JZQtfA9kcQLaaxLJWJVRhENtaYsavg1BjFCWmdD+EGm8q8froR0YI21hi 2bq/bAsYeVYxihanFiflphsZ6aUWZSYXF+fn6eWllmxiBEbvwS2/DXYwvnzueIhRgINRiYdX yXdxtBBrYllxZe4hRhWgOY82rL7AKMWSl5+XqiTCa2IClOZNSaysSi3Kjy8qzUktPsQozcGi JM5r4bc5SkggPbEkNTs1tSC1CCbLxMEp1cBYm8228+9n/s0Coi+3Msnf4Zi3ja9y3rJHTcvT rj7pYbZWL9pfFzbXKZz/yqHNKW2hQmEnFpYu//Bqioxu9NXEk84FxgeWO5Zyitwwaffc5779 eZvu92rmg4E+QprWHzlDJ/w9zjLhnMhtgzkFnpvXbg9Pv9vOn36havLb1WnnW+8uOhyUlX5d iaU4I9FQi7moOBEASGPW6eYCAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/zSlKAfou0zsN-Rp7bjNV1oMo4Ro>
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 08:14:29 -0000

Hi,

On 9/19/2018 11:17 PM, BRUNGARD, DEBORAH A wrote:
>
> Thanks Magnus for your careful review!
>
> Fabio, on your suggested text below, it is not needed to duplicate 
> this in the IANA section. The IANA section provides guidelines on 
> assignment for IANA, not to future authors - it would not be for IANA 
> to ensure requests for registration provide the proper analysis.
>

Deborah I am disagreeing about this. The IANA section may contain 
requirements on the registration that further entries are required to 
fulfill. This becomes especially important in expert review registries. 
And in this case as a Standards Action registry, making explicit the 
expectations on new registries from the creators of the registries are 
very appropriate. It helps ensure that future extensions do think about 
important things.

So I would really like to see the text stay in.

Cheers

Magnus


> Thanks,
>
> Deborah
>
> *From:*Fabio Maino <fmaino@cisco.com>
> *Sent:* Tuesday, September 18, 2018 3:53 PM
> *To:* Magnus Westerlund <magnus.westerlund@ericsson.com>om>; tsv-art@ietf.org
> *Cc:* lisp@ietf.org; ietf@ietf.org; draft-ietf-lisp-gpe.all@ietf.org
> *Subject:* Re: Tsvart last call review of draft-ietf-lisp-gpe-05
>
> 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.
>
> 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].
>
> 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.
>
> 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  <mailto:tsv-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/  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_rfc8325_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=8gidprIUCfhadFdWi7xlWD0bPsb3dPdfCw9Qf8kdwTI&e=>  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/  <https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Dtsvwg-2Decn-2Dencap-2Dguidelines_&d=DwMDaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=xhv-vipTwtWwg5AcQtMrZCrQA1JAfYXMAgGWqbjj4Aw&s=eyO4c7D3ShNQhaa8oVDqCidHbEp3mW7AkM51duv8Qw4&e=>  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
----------------------------------------------------------------------