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

John Scudder <jgs@juniper.net> Wed, 02 December 2020 21:37 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 281553A159A; Wed, 2 Dec 2020 13:37:09 -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=ISsG1arj; dkim=pass (1024-bit key) header.d=juniper.net header.b=fE37gYEY
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 ixyoSDb0HZ40; Wed, 2 Dec 2020 13:37:07 -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 949643A1634; Wed, 2 Dec 2020 13:33:46 -0800 (PST)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B2LTmFR014879; Wed, 2 Dec 2020 13:33:45 -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=stSih31gtVn+hqOxNmB6ElX0/KjzoriLSYdK0sjh5Jg=; b=ISsG1arjF7sEFRfEYYBtzuNC11BFBulQ//m37ibrebzHBNcnAT9iOV6CnEKJTeVEbMwm /9Oj5HbOE1UNH/om/BB20ahEZgqIyFLxyhFzitjYqblVnzHEvnqnlzL4l9tvAv/1iR+R zQYbvCeVuNEvJKoFydl4ETSOs7N7bUVhvqqUHC9qJ6YfojsgaQoggl/eUGo6d8QxF41L qbl4Mta8KGujY0qENNDNvEvG/KlRCv0RSl5ziTkEib1AYFnqP0SjI8L/TMhN9zUhloRL YfiaQvwEw4Ht88QWy8c5iLXXzRQ82jxbUZjL8B16bU9mkJjoSGwnQh6BGn3AwhVOqxkN 0A==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2173.outbound.protection.outlook.com [104.47.56.173]) by mx0a-00273201.pphosted.com with ESMTP id 355vjdabpj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 02 Dec 2020 13:33:45 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=maIBgbHPgm/cGUQUIIi4YrGp9ODpiVh0QfHG4SGtatYhKDFxLwO9+KTXuKlf6vWrd2tHyayFmw651t664ggEV1bOqEYHHbdi0/2F3da/TdfB3nn89Gqo7WZU3OVN/hKlOFuiCZTFv7ZEm5JmvS06FD4Zy45qH4b5K78jAWT4vhvL9VK5dwWsxgGS+55Hr5pSlwEkmBrFn0POkynfWBSzPqQABrqreuFcJIIV7guXxl5yD4aLxrcVYgrcBQnKdZsWZMe5nBdQzSNioJbUs3hNCL6yZT+LTPq6gKz9zAjdGT6QNUu7rKp0zMl5PJboUQtA8wkqXnCtfNdryGvNkVKNEA==
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=stSih31gtVn+hqOxNmB6ElX0/KjzoriLSYdK0sjh5Jg=; b=KmoejOJSVRP7+OpXbtFXnKhpJOuQeoqqSdVMkuorQRrKri5L12c0UjD+74hfSSTntgqFWVz8xbBujl8RzNSu0bQ4rtFGhcBkxV+uINNcjyrfKVXFznbNROr99NlNpyODpHTZ6anLu50BpMpGlHUUWblD9Bm5hMBMH05deFUNV/EzcfhKEYF3WyM9aqYkjsyKS6uWirSO51ao8/VGVAasWa5dYqkTgCcHnAIAviUOIEwYoPKOhRHoKAke8RTITXhy1/tPTc3+ZMmsfS+1kblNxE84ZOVtVvAJVEGGO1ap8E7tx7cnlbckbDji+wNbevipOI2q8d4kYP7p7Nu828VSDw==
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=stSih31gtVn+hqOxNmB6ElX0/KjzoriLSYdK0sjh5Jg=; b=fE37gYEYdWdccdpy36aIDls1ua7UtoUwP2dLT6rVyvDLVulhL3sNTiEgPulAjRVmnqO5Pt22YwrE6FDF48HGVWxFLehwD5lQIh7CL3UMGoV4PRJekSdSwlXdvNRv9v44+w9mOt5wz2eB1GloPAAOBKx3rrP58hzVqrFT3c7blYw=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by BL0PR05MB7187.namprd05.prod.outlook.com (2603:10b6:208:1c2::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.6; Wed, 2 Dec 2020 21:33:41 +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 21:33:41 +0000
From: John Scudder <jgs@juniper.net>
To: Martin Duke <martin.h.duke@gmail.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>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>, Hares Susan <shares@ndzh.com>
Thread-Topic: Martin Duke's No Objection on draft-ietf-idr-tunnel-encaps-20: (with COMMENT)
Thread-Index: AQHWyChPTy8jPD53Pka68zbNSs6Mp6nkVUqA
Date: Wed, 2 Dec 2020 21:33:41 +0000
Message-ID: <E8F93968-8792-4DEC-97D2-6D5EB86DD509@juniper.net>
References: <160685784560.16683.7961255811483668049@ietfa.amsl.com>
In-Reply-To: <160685784560.16683.7961255811483668049@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: gmail.com; dkim=none (message not signed) header.d=none;gmail.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: 27d005d3-0150-464d-8361-08d89709f04a
x-ms-traffictypediagnostic: BL0PR05MB7187:
x-microsoft-antispam-prvs: <BL0PR05MB7187A780D20F6A6818E4CCF7AAF30@BL0PR05MB7187.namprd05.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: pKWPFgxDmvFOtWF92OGiLK9ts36MbvOhbdwjahH/COO0KDYXb7EbAxO9SLNN6LqFV004mQre08UccbGpkN1QK5dQbwo957dM9dTeMKFUdl42UMHlQhhBzawU9k7vmY5vqLKcAARmI2amVXH72WM3sWFUq/C2S48xZ03jHjVWXiwCfXeIESemjhg2C8On7EasF2b84qtN55NhlfZyYepYDFS98EAwB7rYouKvfuL7auKvHL+W1yOKm/ogM1FoB0zH0kjpwCDOwMKAdSc9AhRCUveqTeXFJuyWYoBZeD49FU0oGesrjLeM7qkf3BXYr7XTgNdEgYV6Skziba0FXm2qfQSc7CiA+qQUp/niGFsRdekL1o5hhYHJ2vUMbU0Rc9ZIWbX1VDMQfdTwAXoDCSMfK97ng0unde6R6IS50t0Zh3FcDpFNnIkpE4me4/yPPPSVdTxpticssJET+NoO7ORT5A==
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)(136003)(376002)(346002)(39860400002)(366004)(6506007)(53546011)(91956017)(64756008)(6916009)(316002)(4326008)(76116006)(66446008)(83380400001)(26005)(186003)(66946007)(66476007)(66556008)(71200400001)(966005)(86362001)(2616005)(5660300002)(33656002)(478600001)(8676002)(2906002)(36756003)(6486002)(8936002)(6512007)(54906003)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?eVd4TmlySWNybmE2d3RWcU9aQnVHZnNoV09VL2lzc2NjMURPKzRJY0ZjcVg0?= =?utf-8?B?d05mQmdKdWJYdmVqUTViVEpLcVNTcm5vUDVzcWV3cGl1WWtCYUwxNzE5enJy?= =?utf-8?B?VElqOEl1OUhJTHlFSnZqcElTbCt3SUJBdTFKOHZRZW9wZ1ZoUVE5cFFZZm1x?= =?utf-8?B?aCtLTllybXVlMmJwc2hqU3VpbjNyZlFRdzBDY040Um1RNzZUQmkzZFJLRlJa?= =?utf-8?B?emZmdHlCZ1ZJbmcvK2JCQ2RDbEozT3pDQ2FCNnE4emwwQTdJZVVRcVJMZWt5?= =?utf-8?B?SEZhOGJWQStOWWhrYjhLdlhJRlNTSUUyYWp3UkVkeFp3cnQwOGNha20vTTVR?= =?utf-8?B?UnpoMWRzY29Sb0JkWGNQYnY3MXlleFB6bytKZlE2ZkdEWUdHNkRNbVdmSEox?= =?utf-8?B?MkdjQ0RiVU91aXVQNFJJMnFqWWllZkxGUEhoeUgwcFhnMnF4UWxKNkp6LzN3?= =?utf-8?B?ZlFtVktNN0Y4a3Exc3Jia1FPYTJTbGR1SitsYVVZYVBEc2twd3p2NGxkd1RS?= =?utf-8?B?MGZKaGdFSTl0Z1lQbCs2eDdVcmlqeFA0dlNZczVkVWQzdzFURDJaM1FSVFl6?= =?utf-8?B?TWV4NzdHSTZmcU94VlVvQ3RoMUV0dVdBME5IVjNFR0ZaNUl2ZS9QOG1JMkww?= =?utf-8?B?clQ3YmUvc082bEJIMXF5cHoycm0xOW1hY3VTclVaR2pBZlg4MEMzMVVoV014?= =?utf-8?B?T0lzL1QrRWtqVE5FbENHalZGRXJQYlVMWi9kRnc5QUhQT1BOMXVDaFNvRkdQ?= =?utf-8?B?M080KzFuM3RZN3RXc2VuSUYzQmE4eUR4NWN3aGIxaTZ6MXloMWZrUUNlbTUr?= =?utf-8?B?VzI1U2JTeDdrLy9TdHowbEZickxzMTNsRi9WNjJrK3VDVERpQXBDTDcrSEpQ?= =?utf-8?B?Ym1Rc1UrMzM2UlVtMEZGeE5jczBUYlBqNGM4SStwczZVK0VuQlpiYzBiZC9U?= =?utf-8?B?V2d2ODhJNGh4dWJaaTdYRkF3Y0dMd0FBdVhLbUNSNTJnMFN1WE5kUjZvRFBO?= =?utf-8?B?VFhlZkZ1WnYzZm5CYkdpK1NzTlRJalhVQ3hpN1FHdXJtWThCY1g3cG5CUTBX?= =?utf-8?B?YkdFM1p4dlJxSUxwMnJQKys5NVBYWlBVZW80UmllenBJb1ZKbHo0dzUxS3BK?= =?utf-8?B?ZTVreDNiTm5rbXBKYUM1YjFQY2RCejJoZm9CMkhhN1poL0xvMm9FK2gxMUlj?= =?utf-8?B?OWFlZGhwbjRpTWYwRmNOdlVCY2NWVE4ra1YwNHNCZ3pnN3dUMkdtbVQ3RSsx?= =?utf-8?B?dVcvSVRtcldYOHJHbXIzTG90bXY2NHdIbnF1bWlGSnozdzF5NFpoaGFSQVlW?= =?utf-8?Q?9OwCtC7GOomSIDADYr3d+Cek/ZX5gS7xR1?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <AE14A9388FEF5F449ABCE1DF88AA1631@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: 27d005d3-0150-464d-8361-08d89709f04a
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2020 21:33:41.3331 (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: YOBjjgSFnwj1PiFTsoRoEZRU88K98Gi5+DjI2AVgGJm57yq0rEuZJOM1s3TjL+37
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL0PR05MB7187
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-02_13:2020-11-30, 2020-12-02 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 priorityscore=1501 mlxlogscore=999 bulkscore=0 clxscore=1011 mlxscore=0 adultscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 impostorscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012020130
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/KujgrA7xOjL_zn6f14th9IaoXzE>
Subject: Re: [Idr] Martin Duke'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: Wed, 02 Dec 2020 21:37:09 -0000

Hi Martin,

Thanks for your comments. My reply below.

> On Dec 1, 2020, at 4:24 PM, Martin Duke via Datatracker <noreply@ietf.org> wrote:
> 
> 
> Martin Duke 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!QklZWO1xCRxZ4O7wK1p08p_1D6hWjTNv8NPa5CIWIg77_enYzU0Ibeo9MLhzGw$
> 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!QklZWO1xCRxZ4O7wK1p08p_1D6hWjTNv8NPa5CIWIg77_enYzU0IbeqaXPvvBA$
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I support Erik's DISCUSS.
> 
> Thank you for Section 1.3; it was extremely helpful to understand what this
> spec is trying to accomplish.
> 
> In Sec 3.1 it says there MUST be exactly one Tunnel Egress Endpoint sub-TLV but
> describes an error if there are zero sub-TLVs. In Sec 13 this is correctly
> specified as anything other than 1 sub-TLV. Please update 3.1 to match.

Before I edit anything, let me make sure I properly understand your comment. I agree there’s a small, but real, disconnect between 3.1 and 13, but I don’t think it’s exactly as you’ve written.

Here’s the text from 3.1:

   When the Tunnel Encapsulation attribute is carried in an UPDATE
   message of one of the AFI/SAFIs specified in this document (see the
   second paragraph of Section 6), each TLV MUST have one, and one only,
   Tunnel Egress Endpoint sub-TLV.  If a TLV does not have a Tunnel
   Egress Endpoint sub-TLV, that TLV should be treated as if it had a
   malformed Tunnel Egress Endpoint sub-TLV (see below).

The “and one only” is at variance with this paragraph in Section 13, which says:

   The following sub-TLVs defined in this document MUST NOT occur more
   than once in a given Tunnel TLV: Tunnel Egress Endpoint (discussed
   below), Encapsulation, DS, UDP Destination Port, Embedded Label
   Handling, MPLS Label Stack, Prefix-SID.  If a Tunnel TLV has more
   than one of any of these sub-TLVs, all but the first occurrence of
   each such sub-TLV type MUST be disregarded.  However, the Tunnel TLV
   containing them MUST NOT be considered to be malformed, and all the
   sub-TLVs MUST be propagated if the route carrying the Tunnel
   Encapsulation attribute is propagated.

That says that you can actually stuff as many Tunnel Egress Endpoint sub-TLVs as you like in, and the receiver is just supposed to disregard the extras. Now, since the extras are disregarded, we can argue that there’s still “one only” for practical purposes, but I’ll grant there’s a shadow of difference.

Then later in 13 we have:

   In general, if a TLV contains a sub-TLV that is malformed, the sub-
   TLV MUST be treated as if it were an unrecognized sub-TLV.  This
   document specifies one exception to this rule -- if a TLV contains a
   malformed Tunnel Egress Endpoint sub-TLV (as defined in Section 3.1),
   the entire TLV MUST be ignored, and MUST be removed from the Tunnel
   Encapsulation attribute before the route carrying that attribute is
   distributed.

   Within a Tunnel Encapsulation attribute that is carried by a BGP
   UPDATE whose AFI/SAFI is one of those explicitly listed in the second
   paragraph of Section 6, a TLV that does not contain exactly one
   Tunnel Egress Endpoint sub-TLV MUST be treated as if it contained a
   malformed Tunnel Egress Endpoint sub-TLV.

Taken together, those paragraphs say exactly the same thing as what’s in 3.1 — 3.1 says “one, and one only” and the above paragraphs say “exactly one” but I think we can agree that’s the same thing. And 3.1 says “treated as if it had a malformed…” whereas the first of the two paragraphs quoted above says what action to take in that case, namely to ignore and remove the containing TLV. 

So I think we have a few problems to fix:

First, the redundancy between 3.1 and 13 is annoying and a source of potential confusion. I may have previously defended keeping the 3.1 text (it’s nice for an implementor to have useful information like “there’s exactly one of these things” right next to the definition of the sub-TLV) but now I’m increasingly convinced that it’s more of a liability than a benefit, and propose removing it from 3.1 and just supplying a forward reference.

Second, there’s a contradiction between the first paragraph I quoted from 13, that says multiple occurrences of the sub-TLV are handled by ignoring the repeats, and the third one I quoted, that says multiple occurrences are handled by the much more draconian procedure of dropping the offending tunnel TLV altogether. I think we should pick one, probably the more draconian version, and make the section consistent.

Thanks for calling attention to this dissonance.

—John