Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)

John Scudder <jgs@juniper.net> Wed, 02 December 2020 20:11 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC143A1476; Wed, 2 Dec 2020 12:11:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=KONRdEiY; dkim=pass (1024-bit key) header.d=juniper.net header.b=Do9hvAGn
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 Bj5VNPVqJ3Po; Wed, 2 Dec 2020 12:11:32 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 840313A145B; Wed, 2 Dec 2020 12:11:32 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B2K9bje029380; Wed, 2 Dec 2020 12:11:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=i4RIcP4fGhtjmWtotITDmcboAhFs2rQunwoiz3cgCBU=; b=KONRdEiYXOPS9hPiO25cIYPEioZp513HpHJ61KaP4pHN4JM+NpxOiyA1YXosspV6VClY sQoi+xdmVCEjKsdVK8VteN+OSz82+BFAQOlrukFqKS+iX1dm/6HBqwlqYOtKlJaA3jOD gS0cbdGzxMn0E3Gt9hoAcp8zQTxlXJ5YM0+FdtsZ5q0Z8lrJeab/YcI9wLmHO9zteUZN IrfBmDCAF4Fqd4QVqb2E8fiK+lBVtZeWGqnSvd+9B7FMBqnDoI/yzN2JCcmI3tpz+lMc FHj/sYqE0ZDXiCM6W2wvYeWYGOWa3HFxhbldrmAVppCxtHGlW0Xd5VeanEql12iWveLO dQ==
Received: from nam12-dm6-obe.outbound.protection.outlook.com (mail-dm6nam12lp2176.outbound.protection.outlook.com [104.47.59.176]) by mx0a-00273201.pphosted.com with ESMTP id 355vhra7qq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Dec 2020 12:11:29 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FJldz59aH45n+qsqfGNVPj+9VsZrz3uEnzk63VWfLbGAIJVI00zKb9T6UGLn7tPLga8na8xU3s9tGPPIaEkvtJgHqxE26BvlhY9uI6Ax2VtWj86kfCF/oD/aphmasCMaGEYXZjxgISKHncU/zQNOi3OKJ8qymof1iicttBxOKQeHI9v5MLK8TN1wUG8LY1JHFroTVzqErAbgAUOpm3FCO/Mk84dstAgrQJQUco+IjkRC2CddFDIk1oBRlwJF4EIfeNEG7xn18zfrnwtOqqLEbpvWV/RfiiuZQ3ZuncT8V3PIsVE7kwDmL5Yc2Deu2pn3O+S4A1crsR7//XLToTTHtg==
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=i4RIcP4fGhtjmWtotITDmcboAhFs2rQunwoiz3cgCBU=; b=hAMAAAuqITL36yhtxeI8oZpwnF5OM7w9ZGSprwL22J1cJa07yLQVBpwouwpVLoXvv/SUe/irH9Sl41qahKmz8C2PmxZZO8BSyueYm5Z/HccUGfquB2mIrZbBzlLnQf4hZMymCANLLwyhm3L94MsQ2U7ZrtTxmESBX1OccJKOUtVrL8Usv9wD1bgyiQ3/sg8fHUSEWGyVqWS3ipVFwPze3YfDInhMOSW9e/svD9y4YqH4I1Olr+64jxuCcDHZEn8AM1tszrvkiAwuS2cQCYU2h92nIkB/++3x6qGhaT61wh5UQNe6opzE9ySx9p7MRZzy3V1vHGZDrXa26KwT2ksqGw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=i4RIcP4fGhtjmWtotITDmcboAhFs2rQunwoiz3cgCBU=; b=Do9hvAGnFn1gZzQiPiePp6XCNfjlXMDX61WDiWwyXt0oT+GtDDuNm9D++6f1ipI9gDUWdkWEcXNErYALw3urwvi69CBlhQneqQANUtOoLDg8Qlm75USceht/qIBc3u92LuwAjVXAofnYsMHlm8bEBww6znwM3tAow1T0X9T1aZw=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6672.namprd05.prod.outlook.com (2603:10b6:208:e4::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.15; Wed, 2 Dec 2020 20:11:26 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::f91f:55f3:3130:d318%5]) with mapi id 15.20.3632.016; Wed, 2 Dec 2020 20:11:25 +0000
From: John Scudder <jgs@juniper.net>
To: =?utf-8?B?w4lyaWMgVnluY2tl?= <evyncke@cisco.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "idr@ietf. org" <idr@ietf.org>, Alvaro Retana <aretana.ietf@gmail.com>, Hares Susan <shares@ndzh.com>
Thread-Topic: =?utf-8?B?w4lyaWMgVnluY2tlJ3MgTm8gT2JqZWN0aW9uIG9uIGRyYWZ0LWlldGYtaWRy?= =?utf-8?Q?-tunnel-encaps-20:_(with_COMMENT)?=
Thread-Index: AQHWxzQY77Js9w2KmUS/zoi0AuwPAKnkQDUA
Date: Wed, 2 Dec 2020 20:11:25 +0000
Message-ID: <D5D68900-0FAE-4D7B-B5E9-CE26164A0B73@juniper.net>
References: <160675295270.15559.9863890149053141458@ietfa.amsl.com>
In-Reply-To: <160675295270.15559.9863890149053141458@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.4)
authentication-results: cisco.com; dkim=none (message not signed) header.d=none;cisco.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [163.116.133.115]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: a5c4ca57-279c-44ae-a7cd-08d896fe7277
x-ms-traffictypediagnostic: MN2PR05MB6672:
x-microsoft-antispam-prvs: <MN2PR05MB66727C2CF6FD67A9E93FA06FAAF30@MN2PR05MB6672.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: u6ULyykiDovhMnDg52NPHgGcKDQbX03vmCCSh9CE4yijiXr8rbZDnqeXkMN+qVjd8036dPOLWSMGCwSR/rKfNHlj87g5bS2H0AuU5up32d/v/cjIsarGiKJDni0hI/F0TAp48wiW3iHq96zkFOi2Z4seL/J0Ha06hnKjkLij1VavG2+kQEah/KbMcs89Yqm7bAdKYtp7NNSjrqxCGo3OMYpPh6ONC4NcRu6l05cvzizGttpNme6orxGOgKiiQ6/ypJR+Y5awX+0nKqOHQIzz03yyQJkjd4UGuUU9XGk1jcBu2uDl4t0epau2QXWYv/hNF1Ok+Pm0er4cPT/dRvZJgdC2EaK34ZpCdb9jRm9ylg1N5vZF8eKXbutSQgaZMEi+BVak0vUhmNf5RCx9iG2hFgBfloelS2+qNd93NVSBsw1reVBN+V6X1akCenEured1TfVnViZTNAI2BrrONSo7iQ==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(396003)(376002)(136003)(346002)(39860400002)(366004)(91956017)(26005)(66574015)(66946007)(6486002)(64756008)(4326008)(6512007)(33656002)(2906002)(66556008)(66476007)(76116006)(2616005)(66446008)(83380400001)(966005)(224303003)(6916009)(316002)(54906003)(8936002)(36756003)(53546011)(478600001)(71200400001)(5660300002)(6506007)(186003)(86362001)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?QVlBcUhGeXFiWk8wdkhPb2g4VUlkRFBXWmI3VnNWRU1pNkI3MXo5ODBISE0w?= =?utf-8?B?VUt5UVg2YmNmSEFPOVNWb2E5Ti80a1JaeUFzRFFUY1Y5Um5JYnQ1TGNIdC92?= =?utf-8?B?VE5GTkRBTWtCNmVIV3FKMlBPTkI0clRZZ3BnWCtnYzd3Y2hVNmtzSmhxWERP?= =?utf-8?B?aldBdVRYTmhjQlBDRmY4S1p1MVdyVlZOcEtjZEJwYlBuaU5jUlM3MVZBRUNh?= =?utf-8?B?c2FxdkRCdEFPL2JUaC9zZ3E2bkp0V0dtcmJiTTE1NVowZzhicEVvZGc0c1Vh?= =?utf-8?B?cElwNjZPZkIxVy9iclhYRXJkRzYrLzZ5VzVlelRlZzU5Um4wUjgvcUp6YTYr?= =?utf-8?B?Zi9mc291M3hqTWRxRUpSYWpobmNZV2NKOGNOZDVVZ24ySWhWNTJCUTNmVE0r?= =?utf-8?B?MGMwK0NDZnVCdHF2MU45L0FqZ2tjellaWmV4a0pSczV3QkpKbk5hM1FoSDJI?= =?utf-8?B?djBpMHh3TkRjcDBiMFZsUFhMM09rUkZrQmhKcXpuZ2xVMFVsanNEdW9YdWph?= =?utf-8?B?dFk0RnpFRGM2Z1FPK09kSFFhQzNEVjQwUVQ0QTgwWW5Vb2oxb05hcytPY1dw?= =?utf-8?B?ak5CSHJYOVV0UTJHWkFESFdzL1hEMTZCSHllaU0xV2I5TGpwaXFxQ1hrejFz?= =?utf-8?B?WnFOV1MrNWswWUFJdE5GclhjZlYzcmwzYmtnTktHSm91U1ZXaXA2dDBQMEc1?= =?utf-8?B?bkdVNGNkRG50MWZJVVM2VjMwTUZmMzVBYXBYMFQ5NkVwbnJ2SEswcE1aeVJP?= =?utf-8?B?alp0Vk5lVFh3RjJ5eUo1QmM5bGRuNjQ0UG1vUjlLVk4yaWNNM21nMk55dHZY?= =?utf-8?B?b1BCNGJaUzU1a1hGdHZxSXpYRGFXM2lwY2RxRjJ1Wnhod3I0WGVIN2lVdUV2?= =?utf-8?B?c3hFVUZ0K2lIaG8xbGU5eHhra2pMcGxDV3ErNHh0MFRTQzVQcUNQb0VXb3pU?= =?utf-8?B?dkI1UmdHVTl1R0ozVW1EZHJBRWlOSTVPVFlGNHdHQ0lBUU1vVkdKeUdtS1Vt?= =?utf-8?B?UHpUdCt6SE9nU2dtdTdieXRSOFcwTGlYTkpkQUg1eFp2N2FxbnhrekRFSHhO?= =?utf-8?B?cEZ6NER5amk1Qk9PdloxTGRKMFY2ZWZxcG80RC9lcDJjK1hHVDZ1SERoZml5?= =?utf-8?B?eFBqOEV4YUs5WGo2cENJUXNhNGRoemVWTldqZjJTSmphbUZ2TVBBbjlzK2Fh?= =?utf-8?B?dnJESzAyUDVMcnJFV29ZL0tyVkh4RDRZUWFJekRUL3NpNEQ2SFRkazAvZW5D?= =?utf-8?B?MnUvaEFWOVVuQzV1NEx5M0R0KzFESHBQb1Z5bldZTENuRHU2dnlhaDlIVUxH?= =?utf-8?Q?xzWgxXDgGcgiq6uQ1AoqEvaz8vKZWG7/v2?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <4EF441933057844EAE09CF7524175D3B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a5c4ca57-279c-44ae-a7cd-08d896fe7277
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 20:11:25.8439 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: dS3BDX8OQfYG2QHfq1zMec0X0abR7scgfoFXIHzEMs6or9hj1wcAbt9wJfpc6IXw
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6672
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_12:2020-11-30, 2020-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 adultscore=0 phishscore=0 malwarescore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 bulkscore=0 spamscore=0 mlxlogscore=999 clxscore=1011 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020120
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/X6wlGpR_xFY4xgeuRqaFJVHo484>
Subject: Re: [Idr] =?utf-8?q?=C3=89ric_Vyncke=27s_No_Objection_on_draft-ietf-?= =?utf-8?q?idr-tunnel-encaps-20=3A_=28with_COMMENT=29?=
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Dec 2020 20:11:35 -0000

Hi Éric,

Thanks for your review. My comments in line below.

> On Nov 30, 2020, at 11:15 AM, Éric Vyncke via Datatracker <noreply@ietf.org> wrote:
> 
> Éric Vyncke has entered the following ballot position for
> draft-ietf-idr-tunnel-encaps-20: 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://urldefense.com/v3/__https://www.ietf.org/iesg/statement/discuss-criteria.html__;!!NEt6yMaO-gk!ViCzn0BhxT8HlczCnDBqvHT7je-ahPfaepKEQClZ2sThFTwDBjpY825mI4QQyg$
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-tunnel-encaps/__;!!NEt6yMaO-gk!ViCzn0BhxT8HlczCnDBqvHT7je-ahPfaepKEQClZ2sThFTwDBjpY827N1viI6A$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points, and one generic nit.
> 
> I hope that this helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> == COMMENTS ==
> 
> -- Abstract --
> A very generic comment about the abstract that is mainly about RFC 5512. I find
> it a little surprising as it describes the protocol that this document
> obsoletes... I would have preferred an abstract describing what this document
> does w/o citing RFC 5512 (except of course at the end of the abstract).

Agreed, thanks for bringing this up. How’s this for a rewrite?

   This document defines a BGP Path Attribute known as the "Tunnel
   Encapsulation Attribute", which can be used with BGP UPDATEs of
   various SAFIs to provide information needed to create tunnels and
   their corresponding encapsulation headers.  It provides encodings for
   a number of Tunnel Types along with procedures for choosing between
   alternate tunnels and routing packets into tunnels.

   This document obsoletes RFC 5512, which provided an earlier
   definition of the Tunnel Encapsulation Attribute.  RFC 5512 was never
   deployed in production.  Since RFC 5566 relies on RFC 5512, it is
   likewise obsoleted.  This document updates RFC 5640 by indicating
   that the Load-Balancing Block sub-TLV may be included in any Tunnel
   Encapsulation Attribute where load balancing is desired.

> -- Section 1.4 --
> 
> It is a little unclear what "these deficiencies" are ? Perhaps add a reference
> to previous section 1.2 ?

This was caused by the insertion of the new Use Case section as 1.3. It was a toss-up whether to exchange positions of 1.3 and 1.4, or adopt your suggestion, but I ended up doing the latter (“… addresses the deficiencies identified in Section 1.2…”)

> -- Section 3 --
> Would it be easier for the reader to either have a summary table of all sub-TLV
> types or repeat the type code in all sub-section headings?

You mean instead of having the type codes in the prose, as in “… whose type code is 6”? I’m not dead set against having a table in the front material of Section 3, but I think it’s probably better for an implementor to refer to the actual IANA Registry, which is also tabular, and is guaranteed to be up-to-date. An earlier reviewer (Alvaro) expressed a marked preference for having the code named in line with the relevant section, and that makes sense, so on the whole I think it’s better to stick with the current structure. I think your alternate suggestion is to identify the code in the relevant heading, as in "The Tunnel Egress Endpoint Sub-TLV (type code 6)”? I’m OK with that but it would make the headings (and ToC) busier, and I’m not sure it really helps the document’s readability. I’m open to further input but at the moment I’m leaving it as written.

> -- Section 3.2.1 and 3.2.2 --
> While the assumption of a 48-bit MAC address is correct in 2020 (barring
> FireWire, IEEE 802.5.14), it also limits the usability of this document to a
> set of data-link layers.

Since 3.2.1 and 3.2.2 are specific to VXLAN and NVGRE, and since VXLAN and NVGRE are restricted to 48-bit MAC addresses, this seems appropriate. I guess if some child-of-VXLAN spec were to be written that used 64-bit addresses, or variable-length addresses, or whatever, then a new sub-TLV would have to be introduced that properly expressed that. So yeah, the document per se is limited to a set of data-link layers, but it’s extensible for new data-links.

> Should the length of the "Reserved" field be specified ?

You’re right, it should. I updated the figure. That made me notice a similar deficiency in a bunch of the other figures, I fixed those too. There are just a couple that don’t now have explicit lengths, and those are given either in the adjacent text (DS Value), or in the reference which is the authoritative source (MPLS Label Stack).

> -- Section 3.3 --
> Should the value of IPv6 Flow Label or any IPv6 extension header (e.g., hop by
> hop or destination headers) be specified ?

I think if someone would find these useful, they can and should publish a draft to extend this spec. It wasn’t our intention to cover every possible application. (Something about “boiling the ocean”…)

> -- Section 3.6 --
> If not mistaken, RFC 8669 is only about SR-MPLS. So, I wonder whether the
> authors also think to add a similar feature for SRv6 ?

Similar response.

> -- Sections 5 & 12 --
> Unsure whether this paragraph is really useful, isn't it implicit ? (I am of
> course fine in either case)

Both of these were added because other reviewers thought it wasn’t clear enough, so I guess some people don’t think it’s implicit. So, I guess we’ll let them stand.

> == NITS ==
> 
> I find the choice of "encapsulation sub-TLV" a poor choice as it can easily be
> confused with "encapsulation TLV" (section 2) but I guess the train has left
> the station ;-)

Yes, it has. :-) I do see your point, though. Sorry.

—John