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

John Scudder <jgs@juniper.net> Fri, 04 December 2020 20:39 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 753023A0FBD; Fri, 4 Dec 2020 12:39:21 -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=xKsYJgNj; dkim=pass (1024-bit key) header.d=juniper.net header.b=Txi0tVId
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 ussOlXkXY45p; Fri, 4 Dec 2020 12:39:20 -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 205CF3A1182; Fri, 4 Dec 2020 12:38:48 -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 0B4KVIjl003281; Fri, 4 Dec 2020 12:38:44 -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=W+UJjsy0iA80JzkrgDiQ0Mk9XJBzS9IrK5JSZK60Tds=; b=xKsYJgNjB9M7wubHRQsvNFs0JsGz/AaSHDy1AhflMt++4L0HBu1zSEbdPzP6U0X/3ft6 OZt7qkKxyH82yJ55UXl7+RSOEZoTVPEc7+iPaxMRjSVXZMBLqcLh/H5EjbRK2OtB3REn Fq1NRx8jYcLv0Slon3CIt+kSmEDciK68BO03J/ZLELn/WdTF//Da6Qc05pEiG54jQbs6 pvkonek/s5ik4QVeI3BjIHj3RFZ8kMwPAh4jARVFq64seOfws0BKRxbIlLqpmnsQO7gb FYXGjaKYSL+TZG85YVZj4lj5/RqqcB6Tz72VFfbMwD3jRrYn1jogh5OB3K/fdJRBqL4u wA==
Received: from nam04-bn3-obe.outbound.protection.outlook.com (mail-bn3nam04lp2059.outbound.protection.outlook.com [104.47.46.59]) by mx0a-00273201.pphosted.com with ESMTP id 355vjdeg97-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Dec 2020 12:38:44 -0800
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HxlFhTpZaaBkD7K9USH79dAMQXDO1t9VrV3ZjVcFna3aUwoPZTXzBZkWb/twh0bE/1Rm1TC2bUYJglpy+17zvqKp2VDXiX1FnykZ3iPTEcGqHK9s7P//vnGVwRP4KTiibf0X4CXPrScfggUg2kDbrBDSTMHBZjLU9K7IhA+ZSmfpJXe6dd4s/jDAqQLGvJdARZ9DdTstw/daqyVQsgedrkgbQ5uGxTyTfjc0wVxEViRZDF3Tmdg77Al5oj6ts0jBF1mDRsxy6jXrzxQlAzaZeNNG6+9OzlPDdj3od2pidK479eQtT3A3kEGHxOFa8PNgg8QXJMGQ6crZuU+tC3YuuA==
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=W+UJjsy0iA80JzkrgDiQ0Mk9XJBzS9IrK5JSZK60Tds=; b=It6KsDyrFk1Tqv2LFf5N73ZowknV2Arfmef9TFKNIw8EsdDEhoklihzVqxEyDYKd8Uufve4DOM54AUGwK9bMYIKKgdMbEOdxEcTN8qDWsZQAHZto2BjVeTEWu6JQPVhIHN0vv9tLxSSi1DSkj3QwAxOjowWpC+cdVtW20Pon6MAjVqXH+s3DNpEFuQJwAMUkkbD2pUcG47xyS99nc4DPTkDSJ2+c3OLGfV+jRft459ZpZhrE0D1+p75p0icTF5x2HPt3pa/t96BjhwWPxC7jPBcf7uw30PKZYM0l2k4Xqnoz926cGHTtzCB/iySxfHD7eyHj/H//oRY4u7F69Mqe2w==
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=W+UJjsy0iA80JzkrgDiQ0Mk9XJBzS9IrK5JSZK60Tds=; b=Txi0tVIdT/6GrXePILiAJJ5XIgs1U+xxW8QZS7xbyKZRZmi511SBKM/d3iiXs5Ab6vdHJNDRIgXWle4wO+Z2DW8/7DWIbk7A88bkjRfECcDsE6vb5JRzj1eX+IW6czG1lzbfLJmmcsXH0sLMZpvqxwgWKAqN/BxuPsfnYlDeM2E=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by BLAPR05MB7249.namprd05.prod.outlook.com (2603:10b6:208:29c::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.7; Fri, 4 Dec 2020 20:38:40 +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; Fri, 4 Dec 2020 20:38:39 +0000
From: John Scudder <jgs@juniper.net>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>
CC: "idr@ietf.org" <idr@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "idr-chairs@ietf.org" <idr-chairs@ietf.org>, "draft-ietf-idr-tunnel-encaps@ietf.org" <draft-ietf-idr-tunnel-encaps@ietf.org>, Hares Susan <shares@ndzh.com>, "aretana.ietf@gmail.com" <aretana.ietf@gmail.com>
Thread-Topic: Magnus Westerlund's Discuss on draft-ietf-idr-tunnel-encaps-20: (with DISCUSS)
Thread-Index: AQHWyWJjMseT+/0WmEGJNrlCAwQXqqnl5pOAgADbSwCAAKZBgA==
Date: Fri, 4 Dec 2020 20:38:39 +0000
Message-ID: <EA46DF01-A4C4-4E9E-883F-14C397F796DE@juniper.net>
References: <160699274176.32616.2646384288138693459@ietfa.amsl.com> <011B5202-4AA9-413F-B16C-C8BF9E43A0CA@juniper.net> <ad54d8b05747127c593aab0337f1496e4ee25dbd.camel@ericsson.com>
In-Reply-To: <ad54d8b05747127c593aab0337f1496e4ee25dbd.camel@ericsson.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: [163.116.133.120]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ca5ea084-38b6-464a-ebd2-08d898949541
x-ms-traffictypediagnostic: BLAPR05MB7249:
x-microsoft-antispam-prvs: <BLAPR05MB7249E4F40B8360B9A426B909AAF10@BLAPR05MB7249.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: xdn+rVqTx10xTveyJB3mqrGu/+7x7NFhXDZQm4JKF7Kg8m0HVwcawDacXvCrrdKaeOVXJO0WwZF/hbigraU8LpsNzkxPzYBsWw9GwqH0YRqcpAn4X8IUk9SNAXKFanO/lQ92Vx+SPdjNLuvaGJeL6Ju9FAozMxG6F5733ENU3hutwovaAzFGg7N7Ea2LoW48W5VKQNe9i4wz1pZi5EqHFwkNg15l6zJSsw/oSDARSY7trgetG6tJEQTCBh2qSW3ay645AevG5saH3fQ9x05atd4yXZ3X+kKIP3OfFLn1i42boSaSNIUr7mpwYRgWpngrsPYZBRIMSrPsCh+16AOflA/fok5E47jZTU9n7/7sHPP+VaqLWt11iDNdJPDv1slM
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)(39860400002)(366004)(136003)(396003)(376002)(83380400001)(54906003)(2616005)(8936002)(66446008)(4326008)(26005)(6486002)(186003)(6512007)(2906002)(478600001)(66556008)(53546011)(33656002)(6506007)(5660300002)(76116006)(64756008)(316002)(86362001)(6916009)(36756003)(66946007)(71200400001)(66476007)(8676002)(91956017)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Rnl2a0plYWcvNW1UMmVUQXVhamhGY0NDY1RhZmZVVSttZEF3cXBQcm9sd2w3?= =?utf-8?B?ZUZ3djliYkdJeGludzk1V0lMYzVPUnpFMnoxZG5LYndXWWplKzFsV25SY0tC?= =?utf-8?B?YjBoeG9mRE5XQUhUM3hCUXk3dzJQN2FSUW5KblBWSitnZHRRL2Z2WmpUcWtW?= =?utf-8?B?bS9nMXkzNXlHK3orNjRsU05pS0JyNXdIMnQwenFKL2x5K1dQaUJUcFNOd0Nl?= =?utf-8?B?WXlCUW1BeVhvbDRTMkQ1YWN1SW5CWUN3VEZ4elNsRlZBZGJ3cEYxRVBpSUF3?= =?utf-8?B?OWxCRGc4d01VK1FBdGdkbUlOdTl1a2NDbEVMc2cySTlHSnp0eHc1WTg0OEEy?= =?utf-8?B?enVuV0ZTbk1CUWhaNU5HVnozUnRKVy9JbVpkVElVSklzNkg3NXkzVmhFTnMr?= =?utf-8?B?N0p6TlJOR016MUozNU1rVHI5OHhtVXIzOG9lWUdYLzhDZm85b0NHb1lDK1BV?= =?utf-8?B?Sm0zK21sVDZ3bEpGdjczdGlGQ0Y1M1NRektRNnA2WW1QcU1sbW1HS1hvdVhW?= =?utf-8?B?UDZPbzhBZ1lPOGJWN2hnYm1zQ0tTcHc2Z2JaSDNjbkRQc3JRTWs0Nm93K3dj?= =?utf-8?B?eVlmUWZVR0loOU5UcXJEOU9aQVY2WW1DMlBLV2dEVU9FdVNDVzlIWmRTVXpC?= =?utf-8?B?OFp3ZGQ2MmxzM1M1SE5lYUZmSmx5aThjNVFJUVQvdzlGdWNkWkR0UkZnR2hw?= =?utf-8?B?MCtPRFRvWTI2MEN2TTZIQTROMDFZenNEaWNDMnZyZFZCM1pxT2RCSy9lVWF2?= =?utf-8?B?SnhEUWNocnFmWmF4SjZMTkJWZFJ4aFFiWUlrZmtrQVBzQVJDOW5ydFFUdEpD?= =?utf-8?B?SENGaTg4YlpMdHNQVUZtWXZLMXVWeVV6NllqdGZ2dGcxcUd6Y2RxSVBxeG5h?= =?utf-8?B?bFJ5dGNxSGdQbVp3K2pxK012VkljTFZPZGpKMEZoTDFOOXZEc1N0aU1ZdytM?= =?utf-8?B?QnpVZjZoZVdqSGx2ZTI4enlYVU4xcW02cTBlTDZtR203NFVqZUtMN3NSMU1a?= =?utf-8?B?bmJCSVVLS0IwbUhSQVM4N3NzYTNJOE5Uams1TDkxRWo1eEJtdXZNOEg0dkc4?= =?utf-8?B?Zkk3RGpBUEtOVEQ1RWVUSkthVXhCMkhxY2FMS2NPcWpJRVhQVFpoZ2xIOTE2?= =?utf-8?B?UjB0Ti9zQ0diNEZhbE5MQkVSTzRPVVgrVFhxUko2dUVma2pqT0ExMXdGd2Ni?= =?utf-8?B?eEFlR1N3eUx1SXU1cU5LSWNVK043eHoyeVB1d09uTWNmRUFFZzBOZnRScS83?= =?utf-8?B?eTRKV2hvSjlRa0wrWXlwZE1SMkR1ZURJRjRvNWFQaHV2OWxDTXFBK1BZL3li?= =?utf-8?Q?2oTSvQwyHTp0IjBek+nXFKhn2HY/XHE3Ey?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C605D06F25FDA546B80224607F9F20FB@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: ca5ea084-38b6-464a-ebd2-08d898949541
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Dec 2020 20:38:39.8333 (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: fdFJUof+t6NoPbYti4QlEpY3teDxYLEwjAyKe4fF2PLdUKebfFahc+QPdo91gJdK
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLAPR05MB7249
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.312, 18.0.737 definitions=2020-12-04_09:2020-12-04, 2020-12-04 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 priorityscore=1501 mlxlogscore=730 bulkscore=0 clxscore=1015 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-2012040117
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/RPfVJINjPw30LWUkKtLxW3blWzw>
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: Fri, 04 Dec 2020 20:39:22 -0000

Hi Magnus,

For now I’d like to talk just about your zero-checksum point (quoted below but I’ll top-post my comments). It seems to me that the expected deployment model for tunnel-encaps, detailed in Section 11 and further strengthened after my discussion with Roman, exactly corresponds with "single administrative control” or "closely cooperating network administrations”. Here’s the Section 11 text from the current candidate version 21, after the modification:

   The Tunnel Encapsulation attribute is defined as a transitive
   attribute, so that it may be passed along by BGP speakers that do not
   recognize it.  However the Tunnel Encapsulation attribute MUST be
   used only within a well-defined scope, for example, within a set of
   Autonomous Systems that belong to a single administrative entity.

Whether it would be nice to add a “should we use UDP checksums or not” sub-TLV anyway, as an additional bell and whistle, is up for discussion. But I don’t think it’s mandated by RFC 7510.

Thanks,

—John

> On Dec 4, 2020, at 5:43 AM, Magnus Westerlund <magnus.westerlund@ericsson.com> wrote:
> 
> My impression for example when it comes to zero-checksum for IPv6/UDP is used
> widely with little consideration about the potential issues. However, this work
> is done in a WG for inter domain routing. Thus, the general context is inter
> domain routing, and that pushes the zero-checkum usage from within a single
> domain into multiple ones. Thus, the risk for errors that checksum would detect
> is different and also the potential impact of failure to verify is different.
> Thus, there might actually exist a configuraiton need for this if one intended
> to pay attention to what might be written into the user plane specification.
> Here actually we do have an issue with RFC 7510:
> 
> So your document states: 
> 
>   MPLS-in-UDP [RFC7510] is also supported, but an
>   Encapsulation sub-TLV for it is not needed since there are no
>   additional parameters to be signaled.
> 
> While if you go read Section 3.1 of RFC 7510 it states the following in regards
> to zero-checksum:
> 
>   The UDP checksum MUST be implemented and MUST be used in accordance
>   with [RFC768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless
>   one or more of the following exceptions applies and the additional
>   requirements stated below are complied with.  There are three
>   exceptions that allow use of UDP zero-checksum mode for IPv6 with
>   MPLS-in-UDP, subject to the additional requirements stated below in
>   this section.  The three exceptions are:
> 
>   a.  Use of MPLS-in-UDP in networks under single administrative
>       control (such as within a single operator's network) where it is
>       known (perhaps through knowledge of equipment types and lower-
>       layer checks) that packet corruption is exceptionally unlikely
>       and where the operator is willing to take the risk of undetected
>       packet corruption.
> 
>   b.  Use of MPLS-in-UDP in networks under single administrative
>       control (such as within a single operator's network) where it is
>       judged through observational measurements (perhaps of historic or
>       current traffic flows that use a non-zero checksum) that the
>       level of packet corruption is tolerably low and where the
>       operator is willing to take the risk of undetected packet
>       corruption.
> 
>   c.  Use of MPLS-in-UDP for traffic delivery for applications that are
>       tolerant of misdelivered or corrupted packets (perhaps through
>       higher-layer checksum, validation, and retransmission or
>       transmission redundancy) where the operator is willing to rely on
>       the applications using the tunnel to survive any corrupt packets.
> 
>   These exceptions may also be extended to the use of MPLS-in-UDP
>   within a set of closely cooperating network administrations (such as
>   network operators who have agreed to work together in order to
>   jointly provide specific services).  Even when one of the above
>   exceptions applies, use of UDP checksums may be appropriate when VPN
>   services are provided over MPLS-in-UDP; see Section 6.
> 
>   As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as
>   specified in [RFC768] and [RFC2460] for tunnels that span multiple
>   networks whose network administrations do not cooperate closely, even
>   if each non-cooperating network administration independently
>   satisfies one or more of the exceptions for UDP zero-checksum mode
>   usage with MPLS-in-UDP over IPv6.
> 
> So this indicate to me that there is a significant likelyhood that for the
> intended usage of these tunnel encapsulations would not qualify for the
> exceptions and should use checksums. If that needs signalling or not is the next
> question. That comes back to how the configuring node knows about capabilities
> and how one can resolve lack of a capability when signalled.