Re: [Idr] Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)

John Scudder <jgs@juniper.net> Thu, 03 December 2020 21:38 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 503B23A0CEF; Thu, 3 Dec 2020 13:38:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, 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=ZxFKzYzI; dkim=pass (1024-bit key) header.d=juniper.net header.b=iVbuX7gW
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 GXer7MFaDCt8; Thu, 3 Dec 2020 13:38:52 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 389B83A0CEE; Thu, 3 Dec 2020 13:38:52 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 0B3LXqfC023250; Thu, 3 Dec 2020 13:38:48 -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=9tV8HicDghsXAs3cR9Ix0GpcOzCDNDAsaf+QOzPJgBU=; b=ZxFKzYzIIHQx964p/kTlyrRWSH4CAdKMvCtuw5/DKHYVKDHHZNjLnCNysYaQrm8p6V19 ZjmNp6phQpgLZzhN3qzJoGSFU5tCMMtN3xCnsWDW/4xlJO4U+audOCruPpsXY38YzHbE 35cnH1KlT3HiNS4EZP6dsgbsMdFvxGPjxm4+55vJ/s8HlC+Mz7X7IAma3VQgXQUXArZP upiApL7EU9mHP2GjgJ/Gzw/8RP82AHHNfwSlCsGg+vF+330i7ydllIClb7FHGDDYPA4i mK45r+r3OgFQWlfpDL/CHzNg+Z9bmZdsGDiHSiN6dDw5mhh/8iqNQgJox6q6O0ixuzte MQ==
Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2049.outbound.protection.outlook.com [104.47.66.49]) by mx0b-00273201.pphosted.com with ESMTP id 355vhyvk51-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Dec 2020 13:38:47 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HiF3bgHzIQL7TyUNulJkZFKkaKrUuc8FJVZhIcl0UO+Xa2iaJALi4dpS5+kR6CV0BMoId9VmUJdOeuJ+j9dzpdqujY3gz2PcTzhQPslKzFT5Yi7GkKC5K/zg7u70PjFiUd5+9p6RZCn/cAw6bqYgBpEGjz7wnoBhkwIXNYmdwvJh+rjefgAJi10/MHQpyTDCLANca39EY9fE6DsQ4T7SDsPXZzT7G8V8SIS9U/CuyHifonBCNOqFnr/wTcbzXVcWe3N1PaPvWyTKEjDWGlT/c+f600HwNKXjyMwNrdGoimGFYN1OrWOuuyFpF6B5We3/22mhqxGcWXfW/Gd6aGsgdg==
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=9tV8HicDghsXAs3cR9Ix0GpcOzCDNDAsaf+QOzPJgBU=; b=Cl4ZwVWDtVKAa1BsCO2CdtKxE/4IA9+T1phDuGDxqfndaGtKhSt7MJWgA2wyjdnqH12Jgflc6jidqI0xqVtx08mXl6am1zb9+yH7WVPcTnXnttHA0z1UyabmJXobi1TWq1oEpWDSJsE/96g/dzaq9ilpiTFpXx1+y4UxY86ULCeGlD0u2DzpFp96MB9qswVw3cq4NfJoktf73MlXMd4YK5iztiQNSzgq3BGcRPkfYoDlBIwNB16Ut8+Kc6nn1dT1SAj9c1o4X5AXcqYHqUHckx6Fvu1Mc/ZrXkgYgzurRVeHICxia1VAspO+jqVUh5X/Lhn9qYdGQb2MkhO2lcR0Qg==
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=9tV8HicDghsXAs3cR9Ix0GpcOzCDNDAsaf+QOzPJgBU=; b=iVbuX7gW2XdqVdzQu/RMv4tk8CvablgT2H8ZgrfmUV5lO2YVAlqE9QZ3hR2dyjVtUxL/fwtPeiidFSJz8/dy803ce9rFB5EtVh3PoJ2IoGZpgTF6e9RuPE77uUk/eqqdHCkbLydL90FOkYsX9LFrE7JW4to3TPN8288r7YQkZ9M=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6062.namprd05.prod.outlook.com (2603:10b6:208:c5::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3632.7; Thu, 3 Dec 2020 21:38:44 +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:38:44 +0000
From: John Scudder <jgs@juniper.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.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: Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)
Thread-Index: AQHWyWJjMseT+/0WmEGJNrlCAwQXqqnl5pOA
Date: Thu, 3 Dec 2020 21:38:44 +0000
Message-ID: <011B5202-4AA9-413F-B16C-C8BF9E43A0CA@juniper.net>
References: <160699274176.32616.2646384288138693459@ietfa.amsl.com>
In-Reply-To: <160699274176.32616.2646384288138693459@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: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.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: 79344710-e01b-44c2-096e-08d897d3cf42
x-ms-traffictypediagnostic: MN2PR05MB6062:
x-microsoft-antispam-prvs: <MN2PR05MB60620669D9943C053ACD5E9AAAF20@MN2PR05MB6062.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: u02BUPE3JY0WlP32Sqs5DH60UlsOkFRO6zi48tktcg4Rw1MmWRcOQnXlR7ahdvET1CPUFK/ClI3/FG8x8ZaUby44jcaygX0jEtkWQHloKdUZzAR5Swb7tEXb5Vc/DQgPcnljQVAMSa0RlanO8bUzB7XSnK4iQRgl6fspurc4R7kmOJchoOkINC5XLII/qDO61UyCJDZaYptihShg2WfdTFolPcb+fyi9dhxyg0HldtarbdoCfuXrxVR3WWLctobQqSQc286zFRdaSKf5PaR5mcmFJoajKoE5nHE51YeCrFsfY+YxWfXEgmY504we42msyCCRFObGjXXCHz6s0Ur/T+SWiiJzW6Gg4h7hF8JMuifOVVk3AK2/SKpAxoATlDHN0koDAMT3M9HhpQjK4jWqzWtwjDjFMd7dw78S3XxegnZpaf4TdsJz0nx8lZb4Pc0SWzallgaCjx2rSbzvwLOTpA==
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)(346002)(366004)(39860400002)(376002)(136003)(396003)(54906003)(186003)(966005)(71200400001)(5660300002)(478600001)(8936002)(316002)(33656002)(2906002)(6506007)(91956017)(53546011)(26005)(86362001)(6486002)(4326008)(6512007)(8676002)(2616005)(6916009)(36756003)(66556008)(66946007)(66476007)(66446008)(76116006)(64756008)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?WFRiWGtvM2xseHczR1ZXKzRoR1NON1Y5bTh4OE5zZUIvcld4NVZPZyt0QlIw?= =?utf-8?B?ZGVoUWVGaWhzUDRieWc0TWFYSWZhc0JPS3BESWFRSmFSbEQrSWh4NUFjd3FG?= =?utf-8?B?UURJc3hWZHkzT2ZscmlNZUU3ZkthUmxSUERUd2F2bnNlcWJQbEZOTFNEOXZt?= =?utf-8?B?eGxNNlM1OVJ5WlJLb3NXelJBdFlndEFuNFhnNUw5U3RJTDRPUmVqUnY0ZGVO?= =?utf-8?B?em5Zd1BORGcyVW10WU9Fa1dja3BsOUdUY1FWZ1lkNGFab0JNS0ozd2N3UjJJ?= =?utf-8?B?eUdVbEhLUlZBVFJqTklndW9NM3BYaGVzSDJMR3NxdHVPVnhBbXZEdEpRa04w?= =?utf-8?B?QVRxQ2VlV1ZwRGo0NnUwMHhzZi9FNUhkVmhtbTZzeTI4OWE1OURZemhOeXZx?= =?utf-8?B?eGNBdGZOWGdhTG83NzRWYWdHNEpEaFB6V3pQYUJmR3dSVkp6Vnl3cWZOMzFQ?= =?utf-8?B?RThFZ2Q4dUZENmRTSUVyT3NyVmtaZ3p5Z3VoZzdtWnBpRzMvNWhUWllyN2Uw?= =?utf-8?B?VWIvVzN5bTRNRWdOcFR0VWhQYUUwdlc2OEowZS83UWd0QldDcWZjdk5KWFdJ?= =?utf-8?B?L3psT0lXVWxvc3doaW5oNk1QMUxlQW9IRkJ4bUZFVHhyaFNrMC90Z1pDM0J0?= =?utf-8?B?b25xb2tyYTdTNkpycS83cmNvT2x0blFzaWJ4Y0RSblYvNWpqbGZRUWhtaVlT?= =?utf-8?B?Q2FrWk1GMEEzbmE4UlhobW9ObzJuaFhXbmM3bnMxczIzVUVTT0E4c3VLTHhP?= =?utf-8?B?c1FqNjFwbytuN2ZNM0EwWU82dUY1U0ZkcjFBY0MwalJWTzBWVVhIamRXRFNk?= =?utf-8?B?cXdaWURHWU0rRFl6YmJUYUFzcE1QY24xTm1JazBSa1R3K2JOSDA0QTFyOU9s?= =?utf-8?B?Sm9KbnpBNHlQeGZ6RWR3VENBaEpwU2JVV0M1Q0JPSEdZS1hXRjNNVjYwSkg5?= =?utf-8?B?V3JDOHM5eUorSktTTG96ZGptenpvUk9RUnRDcWJmVzQ1VEFENGE1K20zRk95?= =?utf-8?B?RWRKZEdQV2tzWVZxWmNjMjd6WDB3YkJjL3BTL256OVN6SkdUeXIzTXZxcHFx?= =?utf-8?B?Ymx1Sy9jeFJJYWMyS05oQ3ljRXdBYUFXVnc5eFZ2QTZXeXNjdXN5akY3UTRo?= =?utf-8?B?aWJQZmYySFYxZ1ZKZzdGc3VZeEZmTGVhd2lPOWpaSVVxaGJlVk1wdi92amQr?= =?utf-8?B?S3RqeHpmVlQ1dlZhVDVWVW1XaWFDZmg1dXdTcVdyY1dLYWtxdHFnaGx0ZDll?= =?utf-8?B?anVYSUwyb3k2MXZEZ0lsMjVBSEkvUVhwREZ5dHZWTE8rVHh3VGUzZEJxbGpS?= =?utf-8?Q?YQMWdwOHZMcwL2vE8olVkW0vQwmIWLpuvf?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F6486EEAA03DD74A8238409356DD50E0@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: 79344710-e01b-44c2-096e-08d897d3cf42
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Dec 2020 21:38:44.2261 (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: yOW9NFe/h6ONb9Ji+p27NMBi8MsclcDZfSU1eWntOaTblSoFYKBC2Ag9ZkTELPpo
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6062
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 suspectscore=0 clxscore=1011 mlxlogscore=776 adultscore=0 malwarescore=0 phishscore=0 bulkscore=0 impostorscore=0 mlxscore=0 priorityscore=1501 spamscore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012030124
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/0OBfynsDCepDyVzaYNiaU3xxSgw>
Subject: Re: [Idr] Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)
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:38:55 -0000

Hi Magnus,

Thanks for your comment. My reply below.

> On Dec 3, 2020, at 5:52 AM, Magnus Westerlund via Datatracker <noreply@ietf.org> wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Magnus Westerlund has entered the following ballot position for
> draft-ietf-idr-tunnel-encaps-20: Discuss
> 
> 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!R160ShLm3-ilXKD-spxJGlwrvP9vjZX5gkLJJWWbNNKe-2FiwsoZbD19wDsUXw$
> 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!R160ShLm3-ilXKD-spxJGlwrvP9vjZX5gkLJJWWbNNKe-2FiwsoZbD2i6NtMNw$
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> So this is really to start a discussion of how the framework approach of this
> document may not be explicit enough on what combination is actually viable
> combination and have existing specification for how to deal with a number of
> behaviors for tunnels. So my view after having read this one is that the
> signalling is specified in a two tier fashion, with an outer encapsulation that
> can be IPvX, IPvX/UDP for example and then a tunnel protocol like GRE, VXLAN,
> L2TPv3. So I don't believe all combinations of outer encapsulation and tunnel
> protocol is actually defined. This document does not provide a table with the
> reference for where the actual data plan specification for combinations are
> provided. I think it would be good if there actually existed such a table/list.

It’s not the goal of the spec to provide an all-encompassing evaluation or framework for tunneling as a data-plane technology. It would be a worthy effort to do that work, but I don’t think IDR is the right place to do it, nor do I think this document is the right document for it. The goal of the spec is restricted to signaling; more discussion below.

It’s also not the goal of the spec to support every conceivable combination in which you might construct a tunnel, it’s pragmatically oriented to things people actually wanted to ship and deploy. See also my responses to a few of the others, where I took the position that if other feature support is desired (for example, flow label), it’s up to those wanting that support to specify it.

> The next aspect of this discuss is the difficulty in determining if the
> provided sub-TLVs are sufficient. I will mention a number of potential ones
> that I wonder if they are necessary to configure these combinations.
> 
> To build on Erik Kline's discuss. So are for all these combinations when IP is
> the outer encapsulation is the egress ECN behavior to correctly mark or drop
> inner payload well defined. If the egress is not guaranteed to do the correct,
> then I think a configuration option is required.

I’m afraid I don’t follow this point.

> When using UDP encapsulation combined with IPv6 there is the question if one
> can safely use zero-checksum. Per RFC 6935 and RFC 6936 some consideration is
> needed to determine if the inner payload is safe to combine with zero checksum.
> So this requires the combination of tunnel protocol and inner payload to
> determine this. So I think some of these tunnel protocols have text on this,
> but I don't know which combinations have this specified. And also here arise a
> question if some of these will also need a configuration option as there exist
> some inner payloads that could not be safe and thus a different tunnel with
> checksum enabled may be required.
> 
> When using UDP encapsulation I am wondering over source port usage. To my
> knowledge some of these protocols like VXLAN do defines that source ports are
> picked randomly to ensure header hashing will provide different values for
> different inner flows. So is there a need in any of this cases to identify a
> single source port?

None that’s been raised to date.

> So I at least are unable to determine if this specification are containing all
> necessary attributes when it doesn't have identification of what combinations
> it expect to work, and what behavior on the above aspects is just working.

I guess it depends on what you mean by “necessary”. The spec has been found sufficient for at least three implementations to be shipped, so it’s demonstrably solving a real-world problem. (See the IDR wiki implementation report.) It’s been found sufficient for a number of other specs, largely in BESS, to base their functions on. (See the shepherd report.) I’m certain that if you compared the functionality that’s been implemented and/or depended on by other specs, with the complete matrix of potential functionality, you would find the surface has barely been scratched yet, which I think is fine. In that sense, I think of this spec as a framework (the attribute itself, and the TLV/sub-TLV structure within it, and their generic processing rules) plus a number of applications within that framework (the sub-TLVs). In my opinion, it would be problematic if the framework were deficient, but there is no expectation on the part of the authors or WG that every possible application has been covered, and again, that’s fine.

I expect there will be a great many extensions specified in the future.

> So lets start discussing what needs to be addressed here if any.

Thanks,

—John