Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
John Scudder <jgs@juniper.net> Thu, 03 December 2020 21:55 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 827513A0D74; Thu, 3 Dec 2020 13:55:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.119
X-Spam-Level:
X-Spam-Status: No, score=-2.119 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_DNSWL_BLOCKED=0.001, 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=AhPO+yuQ; dkim=pass (1024-bit key) header.d=juniper.net header.b=eHYlSpy9
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 ZmzmNgbFigIp; Thu, 3 Dec 2020 13:55:42 -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 2377A3A0D03; Thu, 3 Dec 2020 13:55:41 -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 0B3LsCsK016917; Thu, 3 Dec 2020 13:55:39 -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=lfccKAqpEhrV1mRkSPQymhApQh1Mokoeo6huuwzrRYg=; b=AhPO+yuQshfwX/md7TnIDknNaY1mrjFDR3ef3j63pHBo0CIX0VzreQY3ZviwgzCBmYy2 S8FqbV51RBJzDirB2J8W4bVa3JsUkI0qmCeqijOlwSXxQkGhZT4WatJx+TB7Ac4N47m2 tl1u1JuQ+NVKddocyH2zpJEMvQ6hKqPGLRNH5EtswbZrFVqP/wsqTPcGX+S2HH/icCVk RLYxV9kf5r8Jo/TQVkSiR8lwnKPTChg/tuv/dIFAF3UqpEFNHQE2DYa0jTKR7r1G9EEo RA5ns6RF1JUPIaSdhhnfqXBY5xES1EfnbzRbLZWG5gxoRbdBmtYkqKiifTN+3EU+zUMy hg==
Received: from nam10-bn7-obe.outbound.protection.outlook.com (mail-bn7nam10lp2102.outbound.protection.outlook.com [104.47.70.102]) by mx0a-00273201.pphosted.com with ESMTP id 355vhrcmst-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Dec 2020 13:55:39 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BV5nWad37N79hToA9f0TFqjElhK6Brw6NPemMqbloKgvNx9JF5ogGvcMOh90J60xCjWgQ70DC4mz6lq2/TeSTaQF5wQBciOgOZztI2zcePog0Dl1SAOjvK2HtJnenC9cmAx5hVhdbkk6/0vu+xTNoh2a70mK6pXVYat54mNgW+f4alQe1OQcu1D4dK2G0WdYXt5ZV64E4OWK+tLKe3A/V+qtLT6Xnw+OT5LuA6ZfnedUwWQpIqIQdsKjZp+rZ+dODLJGnqJljcBmc08c//CAxcbJXhac7O7g4llx9s/mK/td60gW9xYafPbiGUNM6jOEWO6Ezmqu09OxxwVNHcMk4A==
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=lfccKAqpEhrV1mRkSPQymhApQh1Mokoeo6huuwzrRYg=; b=gJzWy6xgv9CLmKNl0deHWoK5sMdVSGZRl+EdlAXs+qw7iUYSravm69bo/t0hVrFfY8lF7BNFg7SV9EC9wj9jL7vJXho7IuZtI34GmQUbgFfwiMfKZ+XkTNSCRWGN+UTJWuQ9Px2L3lGKr/00DhvDEjbRRDqUUUvizvupNh2zgued8MR0b17MijIwo88UDB0A0bRIFBf7p6S+aoFVzX4e6HFK1LLGv5rUL7YSX7ml2cDMabHKP5EUPcsM9dMIZqBkkib37UdtjQSkddfdb5JN/JavxWEpvWmMk2ZfG+UOsvnD1S9leoUf4ISs33ZgpVEenntcoZQgqyUDB01Lbg0hwA==
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=lfccKAqpEhrV1mRkSPQymhApQh1Mokoeo6huuwzrRYg=; b=eHYlSpy9SFkTZFOYRMeX4A97RwByVg53wUqGM/U6lWg6CXMWbcnGVSH9v3V09Sxs+UOsCUIaTK1xTjn0yJjOizC4TUFO5/OQgkv+k2oF0sBG1AJCb2WMzkevwMPXBOcRRLXWHSJvTUOTbal0yJhNLO8w/Izq5CNjIwe1eYEmtrU=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6222.namprd05.prod.outlook.com (2603:10b6:208:c8::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Thu, 3 Dec 2020 21:55:35 +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; Thu, 3 Dec 2020 21:55:35 +0000
From: John Scudder <jgs@juniper.net>
To: "Eric Vyncke (evyncke)" <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: Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
Thread-Index: AQHWxzQY77Js9w2KmUS/zoi0AuwPAKnkQDUAgADXW4CAANgUAA==
Date: Thu, 03 Dec 2020 21:55:34 +0000
Message-ID: <2BD33807-8342-4F4E-A931-248388369C3F@juniper.net>
References: <160675295270.15559.9863890149053141458@ietfa.amsl.com> <D5D68900-0FAE-4D7B-B5E9-CE26164A0B73@juniper.net> <73361E94-7074-4196-BA1D-8019BDDC4522@cisco.com>
In-Reply-To: <73361E94-7074-4196-BA1D-8019BDDC4522@cisco.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: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 0d6dc047-a03e-4748-74be-08d897d629a5
x-ms-traffictypediagnostic: MN2PR05MB6222:
x-microsoft-antispam-prvs: <MN2PR05MB6222213B54C7ED4351F5EF59AAF20@MN2PR05MB6222.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8882;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: xva91CnjSWr+toWcjavVF9Hnqc9pzjJH/Wc6t02DudgGGz1TIpMk52m0OQdYMVOOfNgWSDAp+wnZ6TJBZP343EMf2vYuetJj2T7LV2IB271RYVrJo69FqHdW/v62DDyDJ1evaImQp9CfCj7o+QxNaBAvDj1U4aksflKgk8OYx8Zqcqd4r5ft8GzR76lxWuK2viVtRQ6QhIzDrbGzb+c7u3eS0TO2LTBz7sTYd2SrHZxcZVWrn58fjTBU/RyHwqPpaCAwDb/m22968jKMTZClPBX5JZALyB/gAzm/8ki3RbxG+SaT+7hLtPug/r+zdWxCHxDamISya7zhBrfZW164L240P7ruvYL3ZpWQjLL0KCs+g+cnTWlJdeTbfJSwnPvFwdEzbNimLk5ZDLJ2nI7aLpQDtWWtUUa1SN5dgnnERpGsNHYLV5/4GutMfS2Yam1M+p0uT5YC1Iw5C4sDwx8VXg==
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)(376002)(366004)(136003)(396003)(39860400002)(346002)(66946007)(2616005)(83380400001)(66476007)(64756008)(91956017)(66446008)(66556008)(6916009)(76116006)(186003)(8936002)(2906002)(71200400001)(26005)(6512007)(478600001)(54906003)(966005)(316002)(53546011)(36756003)(224303003)(5660300002)(6506007)(66574015)(86362001)(6486002)(4326008)(33656002)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: CIGkxVDkZFXM3l+VqfauEcE4DCWaHwLEMn43mcQhDTGrJbobMI2a7k6Oc60VAvNvJa/BTcnx0UiEBkIEmdL/QrxYwrf+TKm1YcT76oYW8QI84/8UW3TBEtLPgUKjacHe8NuBcFMise7CT2c58wuZJe6JeTSefusO98SNalSvfkHQKg4Br5AwxiKGm7MqH+jpOBVoXSw3rvDa5ATXIqnf2o0WNfZ/3IK00Y/rOhmbU3k4YRkBNWHnN7l3WGWuxdQwjl87WLdkghyxXTW9wSiGGNmFWyEddMnV7xTmQzUaV3LqRcUnIQwVlokMGSs7j/jDL6+Wq7yysU6acrA6MTr3fGj0nrTtsMP7gpb3zVC+9/2yU7W7gGMQZcCvCzsN+SVHMUvcIkFKc96fb3k/FrqJwaZwM07rOtVbv0Rb490v6WlRO4EcvmjYXRxuDNuX28w3Y+Ycyy6h0EdHRjpWlesraMGtwGZaacDQqSUxeKbR9k10UstjPHK0ctXHrDdanScaDe82zMqf20qG7IYODpW2bAr6yw9BjJT8dzjfjyhRlvjnJv0N4gMtH0Ex4Dhxub/mXubSgAgc4gK2JOBnCGti8hOYj/F0HKQfadq5i8XH1xKT/RE+RsHuyXgvT239dd+qfHXF/Ne4HvVEbW43prnBnrHM4Z1t/TTXHMg38b9wcshZ6pfoSHjGfJDArOhfe0LgCgbvuBaeOWmACRx0kWpL/l9Z+ilGgmc1rZ0sp4EnzVAJ5QqUX0D1c/IdO5UxGuU6jnhwGCKpUQnRvOnJZ9EHC1wDTeNs7NtKmlwFkkgTdSnponHSwSJoWAinRn1qNkBgy7bxljcALvvYC7cVQqENs7+PRTMhoUBOEr5oPImbuS2agFfVfowMGTGJqnmgnihvvb0Il02KrVmpUvvgM4+4pmyo7ziP8x0AvF8ZfupGKWhUfVmmXji5fhIg+RxrI7oxei0aAPdP/7rNqBYQHz6ViYxy/fjS/Psul1zLB97VZYVkKj3Iz88CSxIX7k54MTMx
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E631D2407BDAF34982DDECF8B89AA9BC@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: 0d6dc047-a03e-4748-74be-08d897d629a5
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 21:55:34.8331 (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: sj30ZMeTl1GtMPiKjk3wydgl2ts3To27xPZU27dq3EQSR4ByFPCdB4SYEbtX+h2N
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6222
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-03_12:2020-12-03, 2020-12-03 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=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012030125
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/fTv9DCVhWEzc4KF7ajdxV2Uk7B8>
Subject: Re: [Idr] Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
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: Thu, 03 Dec 2020 21:55:53 -0000
Hi Éric, A few more replies in line. > On Dec 3, 2020, at 3:02 AM, Eric Vyncke (evyncke) <evyncke@cisco.com> wrote: > > [External Email. Be cautious of content] > > > Hello John, > > It seems that we agree on everything except perhaps a couple of places where I added some text prefixed with EV> > > Regards > > -éric > > PS: thank you for using Éric rather than Eric ;-) You’re welcome. I try to get people’s names right when I can. I’m sure I often fail, but I do try. > -----Original Message----- > From: John Scudder <jgs@juniper.net> > Date: Wednesday, 2 December 2020 at 21:11 > To: Eric Vyncke <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> > Subject: Re: Éric Vyncke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT) > > 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. > > EV> It sounds good to me Adopted. >> -- 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. > > EV> Still have a preference for having the code in the heading but it is really a matter of taste. Up to the authors Adopted — so now the type codes are in the headings and removed from the prose, it seems unnecessary to have them both places, except in the case of the Encapsulation sub-TLV where it seemed helpful for clarity to mention the type code in the prose as well. >> -- 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. > > EV> So now, all fish are cooked ;-) Great, now I’m hungry. :-) —John
- Re: [Idr] Éric Vyncke's No Objection on draft-iet… Eric Vyncke (evyncke)
- [Idr] Éric Vyncke's No Objection on draft-ietf-id… Éric Vyncke via Datatracker
- Re: [Idr] Éric Vyncke's No Objection on draft-iet… John Scudder
- Re: [Idr] Éric Vyncke's No Objection on draft-iet… John Scudder