Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

"Fabio Maino (fmaino)" <fmaino@cisco.com> Thu, 09 July 2020 00:09 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 5CEE53A0A16; Wed, 8 Jul 2020 17:09:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.598
X-Spam-Level:
X-Spam-Status: No, score=-9.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, 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 header.b=cLJ7A/HM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=GBLWQnK9
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 lPZ6-BcX5i-V; Wed, 8 Jul 2020 17:09:15 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D77D13A0A0E; Wed, 8 Jul 2020 17:09:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9360; q=dns/txt; s=iport; t=1594253355; x=1595462955; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=2lSQdrHWGJied5Eem+74Yj8I5+JmOZeJLcwDFTe/cKo=; b=cLJ7A/HMJTbmMcBZKgTuJpsXK7HFC0pVTqHG50G6UrMdjmtZfqOt6iDi TKsypWkPUf61ECwXOxtlQW6LwRrGO0qqmcOn2h6SklWTS++lkGxv6yMNu Xa1C8ThmWg4oW1XtkFYZuHJZHQCPQbC1Wb/97sogOSRHLWkgLQl/ydhXx Q=;
IronPort-PHdr: =?us-ascii?q?9a23=3AOU/flx2MRgmgifTgsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxWGuadmjUTCWsPQ7PcXw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoOklOE8G4bFrX8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DJAADDXwZf/49dJa1gGgEBAQEBAQE?= =?us-ascii?q?BAQEDAQEBARIBAQEBAgIBAQEBQIFKgVJRB29YLywKhCmDRgONLiWYW4FCgRE?= =?us-ascii?q?DVQsBAQEMAQEYCwoCBAEBhE0CF4F9AiQ4EwIDAQELAQEFAQEBAgEGBG2FWwy?= =?us-ascii?q?FbwEBAQEDAQEQEREMAQEsCwELBAIBCBEDAQIDAiYCAgIlCxUFAwgCBAENBSK?= =?us-ascii?q?DBAGCSwMuAQ6hAgKBOYhhdoEygwEBAQWBRkGDGBiCDgMGgQ4qgmqCTUeCUhu?= =?us-ascii?q?EBBqBQT+BEScMEIJNPoJcAQEBAgGBJgELBwEhgxYzgi2PKIMToVIIfAqCXIh?= =?us-ascii?q?LjBSEawMdgnOJM4UiiDeFI4QjjTiBZYg3kCaEIAIEAgQFAg4BAQWBaiNnWBE?= =?us-ascii?q?HcBUaISoBgj5QFwINjh6DcYUUhUJ0AjUCBgEHAQEDCQF7jGmBNQGBEAEB?=
X-IronPort-AV: E=Sophos;i="5.75,329,1589241600"; d="scan'208";a="797303052"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Jul 2020 00:09:13 +0000
Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 06909D3J020704 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jul 2020 00:09:13 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 19:09:12 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 8 Jul 2020 19:09:12 -0500
Received: from NAM10-BN7-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 8 Jul 2020 19:09:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=nMK59Ix//FZMrJkZAShyKQpR+EVVsRPMTxIKZaPxh7yAlXWMr905sllYm9+ogkFkqD2z+fTLeclQhU3mGAGzyy3bg3a4OAdCsMQ+Xjd34n7NtEvSQL0Ib1TPsZ5VqZjKN69OucgFAprl5WDo8uSLXMfiZKKxS0BPJEps4B6rBg2A36xLrRUHnQVD7+d/jnUN1wqyxokmL3emvQXQaBNK4E5U7x4qsEIsy5R7y9/gDo3N18yopq/aAC+KSR9WraMFTiiRTvemN9jZYVRriwOzEuENXlANwkPo1SgKYKDGyaHELJetKVWbU+uhl1VBgCV+pZVKOykQ80IfyNb8y3Q+fg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2lSQdrHWGJied5Eem+74Yj8I5+JmOZeJLcwDFTe/cKo=; b=U8wplMuZFUHADPnXvZDeQNlq26q0ni6Tw9YXAwi4tg9Ih9FLy2EYoPalgSagmcYPlf/Vr+9FOb97nQdj6Y4TzEq6ZZlgEsLc1mMauE/GePJFDp12gokzCERAV1p3qheB+ZW2eQJvdUlbyNjF2SRtYrj7bIKCHQMrB/P3FmUwCKuHmlpta64AqR4zucL3aIW3xSVfVMXyfRzJH8aJeHlk5QP0+P516+vGQPNlMSHrmMz5Ck2gTRJsIOgFLphJ2gwyR6I7fF8saFSlfliXQ2+sTVYHxY8lXvRXCoiPTEY5gzEl3tjG+id2xmWVWHbsxrtzhUyTDRdjnY43zDor+CBWdg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2lSQdrHWGJied5Eem+74Yj8I5+JmOZeJLcwDFTe/cKo=; b=GBLWQnK9QZI7iYL2/idFECFAzL4fMbe2C+xzErBrzjwclYsVjP7OBkGUbpdSqqDyMvpP08rNX5jGGYMm57VnWqiH++xeWdJ3OtkVAff+O42/YUgZLb3ouj1PKOBYLaB7mIs9l+G+1BMoAClCjNlatPAcjv6XPsVX+0Nd3YheM+A=
Received: from BY5PR11MB4420.namprd11.prod.outlook.com (2603:10b6:a03:1c9::20) by BYAPR11MB2614.namprd11.prod.outlook.com (2603:10b6:a02:cc::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.20; Thu, 9 Jul 2020 00:09:11 +0000
Received: from BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::d05d:f20e:c1a4:75b]) by BY5PR11MB4420.namprd11.prod.outlook.com ([fe80::d05d:f20e:c1a4:75b%6]) with mapi id 15.20.3153.030; Thu, 9 Jul 2020 00:09:11 +0000
From: "Fabio Maino (fmaino)" <fmaino@cisco.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>, "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>, "lisp@ietf.org" <lisp@ietf.org>
Thread-Topic: =?utf-8?B?W2xpc3BdIMOJcmljIFZ5bmNrZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1p?= =?utf-8?Q?etf-lisp-gpe-16:_(with_COMMENT)?=
Thread-Index: AQHWVDTt+9bPove5Pk+rhLL2VxnaWaj8UuMAgAEWrACAAIMFAA==
Date: Thu, 9 Jul 2020 00:09:11 +0000
Message-ID: <B4A516BE-FBC8-4087-8931-AB3000F67A04@cisco.com>
References: <159410891205.8933.8044835225793109915@ietfa.amsl.com> <E53D569A-8C47-47A9-8181-3DA66C9F6B75@cisco.com> <3D34E6AE-899F-4CAE-9C22-7E7BC17CDE0C@cisco.com>
In-Reply-To: <3D34E6AE-899F-4CAE-9C22-7E7BC17CDE0C@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.38.20061401
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [75.25.137.103]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 07497703-4c6c-48c3-bc38-08d8239c4e96
x-ms-traffictypediagnostic: BYAPR11MB2614:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <BYAPR11MB2614CFF410A1BCA2FE7282D1C2640@BYAPR11MB2614.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3dwRT9deuJrPLsPjn2u3A9pgd9B/qewSopeGTTPfoy6tb8pbuS9sll0g1jAfzVxUftqdfziup5wQi2cLSI5a2VninFGnz1nGp6Vz5Ba3TT6SypW4+styiKT/edHmlJgDxsJcTjxZF7wzSZYcyd3EXsFivO9AHZKu4txCCFFsOSmiK3nVwziB2+/BiEAgHZ8TEku5ffQLQKZimNjYEKnT2SiJL6A6MzY2hMimNwZoFIBhQEeHAszR+1QT2JiYepwS+v3HW3BxV0apOHCtllSNIvVMaxgxTl/74EF70AKvtv51JPFR6JMn2VAylV1pvCInL6RUct5MIS8V46ST4QXg6tD5FpFQvjlxd35FWvUMSeFUAFWyEQYKSPKOIIygcLvJI2KmAxOUHtceoWRwbNqHiA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BY5PR11MB4420.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(136003)(396003)(39860400002)(366004)(66446008)(66556008)(2906002)(71200400001)(2616005)(6512007)(76116006)(5660300002)(33656002)(4326008)(26005)(186003)(66946007)(450100002)(53546011)(36756003)(64756008)(66476007)(224303003)(478600001)(110136005)(6506007)(966005)(86362001)(83380400001)(316002)(8936002)(54906003)(6486002)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: 9ANBCZIFDX9904AURIBGn6RPYfxDgM9b597Nt3Nx2Ex8Z+r1b4lsVxsdEGFE0wRU3/nGtnXNGP0Cl3DEjBovmMUVM1d9L2tRCcAbv7jFCn+H9krml0VUzO2CihXe3t4nHZ1Z8pMCRicRi27J21+hIKAC1d0xCxYhWEppDe8Pt4PFay0auA+H4UCJDi7dzcRN0HH4kgDSw13Z14M9Y1wNil1GZbKf26TB0rdsDpEOdY4gS7+m/c75lpocPK2oJdhcSNmODq96HPAKtWIESSm08S59L9v6/JANTeBIOZoG8okhhzSH7VswF8UmjEZouey1FaqFVyhu5I24cgZ0kzR5N/egBn6cAqdjwAsAonCOlOh4+NT/4UKxHaT1xIOhNdk2YWvpcnlz83csnxdcJ91mRaQlOInGKkHZ/Efnors4sNHaOka89ENxYzMB57D2oBpfz7vWK/3TpsavP86xv/FpUl/gRXoPjveUf5bzCnb5g1k=
Content-Type: text/plain; charset="utf-8"
Content-ID: <CA09D8297C1AD74B9F1657A8F05BFD9F@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BY5PR11MB4420.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 07497703-4c6c-48c3-bc38-08d8239c4e96
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2020 00:09:11.2437 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: EtecDzyufLF2kPEgFQJupWpt8g9Bs9d9RpqEN0R8L4cdJJm0hESk7UxFX4CmljKo7X344f4VA3qettReKeiMlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2614
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/-WEP94VFKM-4juvdbjrC_2wXHrk>
Subject: Re: [lisp] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf?= =?utf-8?q?-lisp-gpe-16=3A_=28with_COMMENT=29?=
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, 09 Jul 2020 00:09:17 -0000

Hi Eric, 
Now I see what you mean wrt the abstract/title discrepancy. 

In the next rev we will change the abstract text into: 

This document describes extensions to the Locator/ID Separation
   Protocol (LISP) Data-Plane, via changes to the LISP header, that
   support multi-protocol encapsulation *and allow to introduce new protocol capabilities.*


Thanks,
Fabio

 

On 7/8/20, 2:20 AM, "Eric Vyncke (evyncke)" <evyncke@cisco.com> wrote:

    Hello Fabio

    Thank you for the prompt and detailed reply of yours.

    About the discrepancy between the doc title and abstract, I still strongly suggest to update the abstract that is too restrictive (limited to multi-protocol extension) as GPE via shim headers allows for other kind of extensions.

    All my COMMENTs were and are still non-blocking, but, I still regret that this document is not part of the 6830bis and the use of 8-bit forcing a specific registry. (no need to reply)

    Finally, the cosmetic issue of having 0x04 for IPv4 and 0x06 for IPv6 won't break my heart too much but this would have been cool though (code points do not need to be incremental).

    Regards

    -éric

    -----Original Message-----
    From: "Fabio Maino (fmaino)" <fmaino@cisco.com>
    Date: Wednesday, 8 July 2020 at 01:42
    To: Eric Vyncke <evyncke@cisco.com>om>, The IESG <iesg@ietf.org>
    Cc: "lisp-chairs@ietf.org" <lisp-chairs@ietf.org>rg>, "draft-ietf-lisp-gpe@ietf.org" <draft-ietf-lisp-gpe@ietf.org>rg>, "lisp@ietf.org" <lisp@ietf.org>
    Subject: Re: [lisp] Éric Vyncke's No Objection on draft-ietf-lisp-gpe-16: (with COMMENT)

        Thanks for your review Eric. Please see below our replies. 

        On 7/7/20, 1:02 AM, "lisp on behalf of Éric Vyncke via Datatracker" <lisp-bounces@ietf.org on behalf of noreply@ietf.org> wrote:

            Éric Vyncke has entered the following ballot position for
            draft-ietf-lisp-gpe-16: No Objection

            When responding, please keep the subject line intact and reply to all
            email addresses included in the To and CC lines. (Feel free to cut this
            introductory paragraph, however.)


            Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
            for more information about IESG DISCUSS and COMMENT positions.


            The document, along with other ballot positions, can be found here:
            https://datatracker.ietf.org/doc/draft-ietf-lisp-gpe/



            ----------------------------------------------------------------------
            COMMENT:
            ----------------------------------------------------------------------

            Thank you for the work put into this document. This is really useful work and
            the document is easy to read.

            Please find below a couple of non-blocking COMMENTs (and I would appreciate a
            reply to each of my COMMENTs).

            I hope that this helps to improve the document,

            Regards,

            -éric

            == COMMENTS ==
            As this document is in the same 'batch'/timing as the RFC 6830 bis, is there a
            reason why this extension is not in the bis document itself?

        [FM] there were quite a few changes and discussions introduced in 6830bis. The WG thought that keeping lisp-gpe as a separate document would simplify the review process. 

            -- Section 3 --
            What is the reason why not reusing an existing 'next protocol' registry? Or
            using a 16-bit Ethernet type like field (as in GRE) ?

        [FM] the LISP header uses the last 3 octets in the first 32-bit word for the nonce/versioning features. We designed a reduced NP field to try to squeeze a limited version of those features using octets 2-3 of lisp-gpe. It turned out that the limitations imposed by the shorter field where too much, and eventually the WG decided to eliminate the nonce/versioning features altogether from lisp-gpe. Reversing now back to 16-bit NP field, would impact the early lisp-gpe implementations that have been built so far. 

            As a side cosmetic note, I would have preferred to have 0x04 for IPv4 and 0x06
            for IPv6.

        [FM] we decided to assign them incrementally. We really didn’t have enough meaningful payloads to get up to 6... 


            "the shim header MUST come before the further protocol" but, if there are other
            headers defined in LISP (I must confess my ignorance on this), should the shim
            header be just after the LISP header ? I.e. the first one of a potential chain
            (cfr IPv6 extension header chains) ?

            It is unclear whether a shim header 'next protocol' field can also have a value
            associated to yet another shim header.

        [FM] Good catch. We have re-phrased the text to make clear that there might be multiple shim headers, and they should be in front of the actual payload identified by NP 0x01-0x7F. 
        This is ithe new text:  " When shim headers are used with other protocols identified by next protocol values from 0x0 to 0x7D, all the shim headers MUST come first."

            == NITS ==
            The document title "LISP Generic Protocol Extension" is generic while the
            document is mainly about "multi-protocol encapsulation". Should the title be
            changed? As a non-English speaker, I read the title as how to make any/generic
            extension to the LISP protocol and not as a LISP extension to support the
            transport of generic/any protocol.

        [FM] one can use lisp-gpe to extend the LISP encapsulation protocol to support generic payloads (IPv6, ethernet, NSH, iOAM, GBP, ...) in addition to IP. However it is also possible to use lisp-gpe to extend LISP features. For example, one could use a shim header to implement a nonce/versioning field of arbitrary size. That's the reason we think of the draft as a LISP Generic Protocol Extension.  

            -- Section 3 --

        [FM] all the suggestions below are addressed in rev-17

            Strongly suggest to make it clear by adding a MUST in  "and ignored on
            receipt", i.e., "and MUST be ignored on receipt"

            "0x05 to 0x7D " the final ':' is missing.

            Why not writing " 0x7E, 0x7F:" ?

            "deploy new GPE features", GPE is not expanded before this first use (even if
            quite obvious in this document).

            s/octect/octet/

        Thanks,
        Fabio

            _______________________________________________
            lisp mailing list
            lisp@ietf.org
            https://www.ietf.org/mailman/listinfo/lisp