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

"Eric Vyncke (evyncke)" <evyncke@cisco.com> Thu, 03 December 2020 08:02 UTC

Return-Path: <evyncke@cisco.com>
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 563943A0AA7; Thu, 3 Dec 2020 00:02:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.62
X-Spam-Level:
X-Spam-Status: No, score=-9.62 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=gPhYnoIk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nXh9HsvF
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 nw2WRfE5XF2w; Thu, 3 Dec 2020 00:02:18 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEEB3A0A1C; Thu, 3 Dec 2020 00:02:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10318; q=dns/txt; s=iport; t=1606982538; x=1608192138; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9N2GtuUZJ4dCNkRIhzNSWNRqhJyOdeQpI4jEyC3youI=; b=gPhYnoIkHJ2+beERe7z5prfkF49N2Ez64mXd/LF3tJkmHJLwE/ABmT/U d8LNSeAUTZ+8Rb9Vo28vvFF8D6ncvrFfYb1rVUHgthE18jSokZooTz8Oz WKMliDhqyEheYIrcqrhlpLoacbLwmiebhmYn9mWMQr/IbsXZyyVrwQX+A c=;
X-IPAS-Result: =?us-ascii?q?A0BtEAA8mchffYYNJK1YCh0BATwBBQUBAgEJARWBUYFQU?= =?us-ascii?q?XxbLy6EPINIA400J4EFiRKOcYFCgREDVAsBAQENAQEeDwIEAQGESgIXgX0CJ?= =?us-ascii?q?TgTAgMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQECARIREQwBATcBC?= =?us-ascii?q?wQCAQYCDgMDAQIBAgImAgICHxEVBQMIAgQOBSKDBAGCVQMOIAEOj2eQawKBP?= =?us-ascii?q?IhpdoEygwQBAQWBR0GDEQ0LghADBoEOKgGCcoJmTkKCKYQuG4FBP4ERJwwQg?= =?us-ascii?q?iA1PoIbQgIDAYEmAQcEBwEhgxczgiyQWYJrAT6TTJAqL1cKgnKJGYJLiUZyB?= =?us-ascii?q?IUUAx+DITmJaINWkQyEY4ohj3aCdY5ICA6EOgIEAgQFAg4BAQWBbSFpWBEHc?= =?us-ascii?q?BVlAYI+UBcCDY5YgzqFFIVEdAIBNAIGAQkBAQMJAXuMYoJGAQE?=
IronPort-PHdr: =?us-ascii?q?9a23=3As8BzxhQeKZKbzO+P1dpeVuYzEtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNWJ6e9CivLbqebmVHBTqZqCsXVXdptKWl?= =?us-ascii?q?dFjMgNhAUvDYaDDlGzN//laSE2XaEgHF9o9n22Kw5ZTcD5YVCBoGC07CYfAF?= =?us-ascii?q?P5OBYmbujwE5TZ2sKw0e368pbPYgJO0Ty6Z746LBi/oQjL8McMho43IacqwR?= =?us-ascii?q?yPqXxNKOk=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.78,389,1599523200"; d="scan'208";a="607204006"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 03 Dec 2020 08:02:16 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B382GZ3028723 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 3 Dec 2020 08:02:16 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 02:02:16 -0600
Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 3 Dec 2020 02:02:14 -0600
Received: from NAM12-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 3 Dec 2020 02:02:14 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bOLhrPnUeHUAygJJ7hDiCKoAyPLod1O/D7lFAA5Pa7oOF07lbboRA8dVINBYTRCBaFYcJdxX5Y2WmmM2yBHjblM1zLjrw2LpQWodAbern48rFkIQletE0/GwN7KOp9b3noW5g4D9ZAbEkQN23C85/wqLZrGF0i16N8bGbk3p211+U2G8QkhfLeyIjZ82QmVN2KpAONpzWFRrhqate0BlE9c2TV4mQwJPNKOcAAA53MdPcAlkbJgMyIqPmRDR/+7f7AZ7IwaDrl7tyFGiTzwVFqcn9GaleD9y1soQsMypNnieOLetaaAg9y7Fncp4RIC++sgLRjTaKeNOrXbpHVxnxg==
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=9N2GtuUZJ4dCNkRIhzNSWNRqhJyOdeQpI4jEyC3youI=; b=a0ok53LEnFzdkFI6GsEhrijJCpLAFpAhHGA8oB9egi23uvJvPY4QOkfWvPVu1M5LSgpZmQWkz/qBXZcTbNzzw4vbk1AjimwiARZY3vE5JcrIUK5A4uaqK1OmGjJbzuwcRwRwD6TzMvWuqffqvpvTBkBQHYXQNbUljUDKWGNVqgymfPNVB5aFjuzW/4TTTNvTGBjgM6eogEIjblRuY4a2ga0JacMNripL71sJt3J4xa9VlfitHaw98Ay9iaa3pnIMGPUa5LQiRvVXyy1O1P2CvIcptswfVU5B+QXCsLPtmhrmNroYyCQ3lz7Kp6cEV6FydB4YXeDDsukrWejeIuqqMA==
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=9N2GtuUZJ4dCNkRIhzNSWNRqhJyOdeQpI4jEyC3youI=; b=nXh9HsvFCXhcXcdridjKr74VD6+F1Rteqtt0lLPa3bW2SGen+jOvw/TjJDIWHL4feyktooijAltUdfz3lsclvGedUOHdCNqx5g+CZMYGf1lmbaDza34CmUY6YvFwtGDhq9Mvyn5eoFufh2JsDgWgTajPOq4BS+ZOOIBdbNdBnwc=
Received: from PH0PR11MB4966.namprd11.prod.outlook.com (2603:10b6:510:42::21) by PH0PR11MB5095.namprd11.prod.outlook.com (2603:10b6:510:3b::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.18; Thu, 3 Dec 2020 08:02:13 +0000
Received: from PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d]) by PH0PR11MB4966.namprd11.prod.outlook.com ([fe80::453b:b2f5:ec29:410d%7]) with mapi id 15.20.3611.025; Thu, 3 Dec 2020 08:02:13 +0000
From: "Eric Vyncke (evyncke)" <evyncke@cisco.com>
To: John Scudder <jgs@juniper.net>
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/zoi0AuwPAKnkQDUAgADXW4A=
Date: Thu, 3 Dec 2020 08:02:13 +0000
Message-ID: <73361E94-7074-4196-BA1D-8019BDDC4522@cisco.com>
References: <160675295270.15559.9863890149053141458@ietfa.amsl.com> <D5D68900-0FAE-4D7B-B5E9-CE26164A0B73@juniper.net>
In-Reply-To: <D5D68900-0FAE-4D7B-B5E9-CE26164A0B73@juniper.net>
Accept-Language: fr-BE, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.43.20110804
authentication-results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c1:36:959a:92d8:2b8e:d99a]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: e07b038b-f39b-4205-a14d-08d89761be9a
x-ms-traffictypediagnostic: PH0PR11MB5095:
x-microsoft-antispam-prvs: <PH0PR11MB50957A33FB988688EB48F293A9F20@PH0PR11MB5095.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:8273;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 5rkS0A8bikSYUHnQOvAz4NqenNDLwETTSLs+V3Hui43W3yGIIFa3o550eRT1EkBKo45hcODlxC5FNqTooHenYKOar4FevPmvughdM+94RKSyna5d0hBNqJrSazkCIFKKvQUYq7YnnFbo7LlRXq1J23Vejd1l+DREzmwiOWNS/YsYPdd8oJsnB1y9yFVcKxhtV6Y7HneTEiy95SZgRawBafvmPwpMMxx01FgaXu2KIjng2Lqh9jKwk/7IvmniqsHXbP4LQGpS4JkSA2Wf1EGjw1+8zU13pV2X/UwNySBULXSbcYmM6zq1XyeXiaG2QqpJD4mqv7rFMRmQptYFMvcGUe1a4VTuzYTitaafm6WZrBkWH6ytcjkwzC5S35HWMVyvxLXrdKqCrfjmvjQ313s7rW1Ltzrf/5scOFolIU1zvCqd/3AdyIVEIqZd6Zn2AgkVNhaS0Cl2N6c7YiUSJh0qdA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4966.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(396003)(366004)(346002)(4326008)(54906003)(6916009)(478600001)(33656002)(5660300002)(966005)(86362001)(71200400001)(64756008)(6512007)(91956017)(76116006)(316002)(8936002)(186003)(53546011)(66946007)(6506007)(66476007)(66446008)(66574015)(66556008)(2906002)(2616005)(83380400001)(224303003)(36756003)(6486002)(45980500001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?bzJiekJ1a1VhekhZazZMcE4wdTFNUzlTU0Z1b2xaVVRDanFwQ0xIWGtHVFBx?= =?utf-8?B?N3EvUkZjTHZiRVU1WWI0czM4YnRDbExkK0w1NmhlR2RzTENDak5ZRjVLdjhN?= =?utf-8?B?N0pLVVYzZ0hGRUhWVGRtVTJ2c0V4MmszSDBENkdHMzRpOVo4RVFYSUNwMDVl?= =?utf-8?B?UytFUlBJTm9oZkVRcFZ6UTdiYUp6MFRXUHRHYnM2emQrTlNjejl5Mm9rbHpw?= =?utf-8?B?T0RUMjRYMDZ4TXp2cjdZU3FNc3RuL0FtY1ZJTjRGZ3NuQkNTUVVhQXFUSGhr?= =?utf-8?B?MGpQazdHY29oTFRDY05ieDZ4RDhFRjMwY1NRZXplQnlSOXJyOGE1ODlVZ3BU?= =?utf-8?B?aWlYVGRrczRaNHZtS2hOUWFzZUJ6cCtHZktvOEFQWDBBY1ZPK3pNQ2c5eThV?= =?utf-8?B?WlhmcnZLdk14dlRqMGd5aEg0TTRXQW81MVVaZ3BLczRsa3JySnZGR3ZpaGxr?= =?utf-8?B?RnBDNWRjd0ZwVW51V3AvN1JoNnhnN3JqUDFURjhDTVhteUE5R0NsZHpJMHBG?= =?utf-8?B?L0VPbW8rVERBQWx6NzNQK0lPOTUzV1puVTd0SWlPVDJIUzhQMk1hcFE0dDNU?= =?utf-8?B?b1lYUE10V09PWW1WbnpYaUdDRVIzWXI0WCtGUE92a1hEcEpLZ0xwdDE2VWZE?= =?utf-8?B?T2U2OXFSNXNlSUxoSU9RYXl6OWZMTGtyNjFLOXJqdW9XbzNCa3hXNnZjZDBu?= =?utf-8?B?aWc1dlk2UHNyM0VzSHZ6N2d5a2s4b3NFK3lDVDAwMzNmUm9LZEFKdTAxOEU2?= =?utf-8?B?NC9RcFA0NDVtenNtS2M1R09Od2RJSlNyclFDRzNVeDNGbThMM2ZkNXB5Wmtm?= =?utf-8?B?VUNsUWFrWW5FOXpYU2Q3RE04NDVONTZ1NndvbjBqMUpyQlFnbkRyTEt3Y2lH?= =?utf-8?B?Tm4vQXVYWlMxa3htb0p5VnpyUVN3VXBoRTdKNUVQUEVncXpqM1BIMG9na0ta?= =?utf-8?B?T2RiQzEzZkh6MnFZcEdObWQzTVNvQ3dVT00zNU1DRVVWWnhrOElLZ1VyMUsr?= =?utf-8?B?RU9CU3VQTDRGMEtGY1FwWVZ4NEZyQnh3aisxVFJORHhYRENYbWNLcnhHTUR6?= =?utf-8?B?UEduakNtbXpoSTVxa092NnBnQ29GSHNyMVpScURuaE04bHNIalRHZ0ErOXdh?= =?utf-8?B?dGVMSmFuMnNraERacWFYWTlCTU5URGplZ3V5RmcyRkhrekhXMnRiV1c5RlZ0?= =?utf-8?B?ZjJYWXIvdFAwRG1CZ1lxTEhpcWlTaVFKeE9yWVBMRDh6RDZNOThMaEorcE5G?= =?utf-8?B?SHNXL3dwVGRLd1ZsaFFIRDQrK3pKNDlORHRONjhpTWllTDlBQ2t3b3RiaEMv?= =?utf-8?B?eU5ENCtvTFVFQzhjRVZQOWdrSFV1TitCbkJ0K1Vhbm41SEFjTDFsZ0JwclVn?= =?utf-8?B?RTVvMFZWSnF2cWVvYUdUY0w3YmZBNWZVZkNJNmt3Rzd2VjJZODlnT2Y3L3BT?= =?utf-8?Q?vOlurag/?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E3BB857F9DEE7E48BB104CD30ED71336@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4966.namprd11.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: e07b038b-f39b-4205-a14d-08d89761be9a
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 08:02:13.7236 (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: pnAX2u6IOG7OUaHpkcEO+XlRdR2GEanjchtm4HzlquIvbuiYptYb8b8/6dkEII6cr/kdlKI8/4gzD2O0HeisOg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5095
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bzJviuue0D2Q6LOp8NNCArWI9qs>
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: Thu, 03 Dec 2020 08:02:21 -0000

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 ;-)

-----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>rg>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>rg>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>rg>, "idr@ietf. org" <idr@ietf.org>rg>, Alvaro Retana <aretana.ietf@gmail.com>om>, 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

    > -- 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

    > -- 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 ;-)

    > -- 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