Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

Balázs Varga A <balazs.a.varga@ericsson.com> Thu, 10 December 2020 15:17 UTC

Return-Path: <balazs.a.varga@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FC4D3A0FD0; Thu, 10 Dec 2020 07:17:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level:
X-Spam-Status: No, score=-2.102 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 Cjmf6qo7Cy-F; Thu, 10 Dec 2020 07:17:36 -0800 (PST)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2044.outbound.protection.outlook.com [40.107.20.44]) (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 9CA823A0C29; Thu, 10 Dec 2020 07:17:35 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Gs1MABc+Nlef6AlNUeMenpgaZyvuUei0dLxcETezf9Kis9aVuHln4BvDTDSZxRmpSxdPo6kS/jiZkT8n7iapx5S8EfaFjNmDWIMZ5rGYxeWqX29vdv36sdSI7MpoXh1QauQaew+9AEpmnNIzpkLDniGC8U6N9ikYU3l2TgiVAjNpwNc7n62ySYpFRhStso73wZnZySHqNxl/CRVS6yJC/IY4xF1W5d2G8ZT9Vwqr50fq5ca2atuXxLx2w2nhNOzQY6GUoOr+HyhYlXokDjJEt7aza2qvrk0o2doOwBlsUQiJ5sE8FRSuEWcNOfSM1m0fGWGIj9vRar17d64PtZ50+A==
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=uptkjMuIrzCoZ06BWYgiXxSI1a+J3UH1r53SO0EwKAg=; b=E53n/mPHyG3PQpc2/p7xi8AVPeHxtwnnH8Fj+kK7BGpkui+Fs2xMKibmCSOPDt3X8SykdaPuDDK1zl6rYLKXyNxnSnotDIabGnNmDOZefMYUfPlS32xCs2UKeo2970nuId1Hd7cWHniOqjoWr5LCWkV74vxQJokCDsAvUxbw55lfunHhaM4xVDva9euJS6qfCsIRsRfPo4McJKqzUr1wtDOleHnyBqpwx7RS3TrinVWKxrBJ+hn9x0Q2zR2kVnIsKcM4UKn7NVSHiVrPxfAaRbcOc6lkfp40CuZi4Axg2Wge/iQGtq11IN/VokZjJnbja63nEFy4ngugxFqBArEDWg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uptkjMuIrzCoZ06BWYgiXxSI1a+J3UH1r53SO0EwKAg=; b=hJY1q/1yh8dQWl95a6CCSTMSRDx3AW1D28SYYF/tGKCr91R9vyo48XpF0olCYpDUFJ0ulamjKe1Y/38ZFbi6nlxOhjhjCRVGzGGGhauwuwsA6yCK+QDKewXLwysX9dIgWnMF9ZdPW3p+DEvkJsC4PgjCmQaOz/njGNnSOXifNa0=
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com (2603:10a6:208:22::25) by AM8PR07MB7474.eurprd07.prod.outlook.com (2603:10a6:20b:249::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3654.12; Thu, 10 Dec 2020 15:17:33 +0000
Received: from AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::e94e:dc9f:5924:3fda]) by AM0PR0702MB3603.eurprd07.prod.outlook.com ([fe80::e94e:dc9f:5924:3fda%2]) with mapi id 15.20.3654.015; Thu, 10 Dec 2020 15:17:33 +0000
From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= <balazs.a.varga@ericsson.com>
To: Magnus Westerlund <magnus.westerlund@ericsson.com>, "iesg@ietf.org" <iesg@ietf.org>, "David.Black@dell.com" <David.Black@dell.com>
CC: "detnet@ietf.org" <detnet@ietf.org>, "draft-ietf-detnet-mpls-over-udp-ip@ietf.org" <draft-ietf-detnet-mpls-over-udp-ip@ietf.org>, "detnet-chairs@ietf.org" <detnet-chairs@ietf.org>, Ethan Grossman <ethan@ieee.org>
Thread-Topic: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)
Thread-Index: AQHWyM4iusr8yJjv6Uie/S6yyS98T6nkC9YggABaxQCAALDbgIALZAzw
Date: Thu, 10 Dec 2020 15:17:33 +0000
Message-ID: <AM0PR0702MB3603EAFE400DC5473C291699ACCB0@AM0PR0702MB3603.eurprd07.prod.outlook.com>
References: <160692402637.11206.9329606236693711643@ietfa.amsl.com> <AM0PR0702MB3603B5136717E3A0A6123934ACF30@AM0PR0702MB3603.eurprd07.prod.outlook.com> <MN2PR19MB404587BFFC59E419FE36B2EB83F30@MN2PR19MB4045.namprd19.prod.outlook.com> <1df47a40bd5f7fddd5ec1051c3cba751455fa80b.camel@ericsson.com>
In-Reply-To: <1df47a40bd5f7fddd5ec1051c3cba751455fa80b.camel@ericsson.com>
Accept-Language: hu-HU, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: ericsson.com; dkim=none (message not signed) header.d=none;ericsson.com; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [94.21.191.182]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f128d51b-21e4-45c4-de2e-08d89d1eb805
x-ms-traffictypediagnostic: AM8PR07MB7474:
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM8PR07MB7474B8C9C134441C6CE1A00BACCB0@AM8PR07MB7474.eurprd07.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: BjjHnx5VYFhElT2SqBBu96ZTlbxlcwGzG7TMybsntPVjkDl1g0YfgwsPy5BJwvc8C5m2rlYwqnCl5dqyBH12xpT9bpnK/a8EPrL+5TG+Own2J7e4zIHU9/k00vRlOq8NDt7AHkpTAVfoJsvIVhBQL9D3mjUy2NuB74Skse9PjjPO45u7oZU0Fl8nE1TeSaxgL3lZ8WoAO455kgK4dBy9KVWrf27tYjbMu0DPPtA9T+Er3kGfzOY6+sAIDs3T6GiuDJKRPsx2GVBJfeFztftiidBFK867sAlF0HpRRvzZXAXDQsOjF3PbxCo9HC2DTfglvHkmf5oygWA8cUID7DKly8Uxavl7tlcTGXixGAObRa2WOeMdXMcqXPb8OYDZehFVMD+1OeeEtwvNXKsOK9ed7g==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR0702MB3603.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(346002)(396003)(366004)(376002)(136003)(39860400002)(26005)(76116006)(186003)(71200400001)(86362001)(8936002)(966005)(2906002)(478600001)(99936003)(4326008)(33656002)(66556008)(66946007)(52536014)(85202003)(66476007)(64756008)(53546011)(66616009)(66446008)(8676002)(6506007)(110136005)(5660300002)(316002)(66574015)(85182001)(7696005)(55016002)(9686003)(83380400001)(54906003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: =?utf-8?B?aGpKN0Y1ODVvNHphSlZhNUF4bGtValZqOXZuSUl1VlppeU9ZVmFhNklZdllM?= =?utf-8?B?WUtQb0hLTysreTRZWHZGKzlWdzBBWjFBYllrbXR6aVBuY24xUUt3YnB3WWll?= =?utf-8?B?QjNkVTZDOWl2WUV3T2VrR3hIUU9NOWFVWEgyMUVOL2wvbjZ5eWwrR0tHUzJQ?= =?utf-8?B?UVFSZFNDeTVjK2xZbm1BN1N3TGh4L3h1eExHZUhWWjFuZlVmaUlHSCtmSmJt?= =?utf-8?B?MTJHL1laRFg2QU1VWlpxeUNKVnV2N2JzWXRqdW1INGJmWFdiUWhobHN1WGJ2?= =?utf-8?B?VElOQ2x3a0Nia3NMZ3BiNlhJV01jOTF5a3VmWWxjQnE5M09oVGNvdVVXaVY4?= =?utf-8?B?Q2hiYUpRUlJJYzZTTkQ5ajNscXE4aGtpVkRnMUgwV2pkL3RVU1lGcmZpZlFw?= =?utf-8?B?UndOMHVyZisyMkxhZkpSaU4zK2xMR2dVUzBTQ1o5SUw3Tk84Zk1oOW5sVUZ3?= =?utf-8?B?M0VCdWdKTUlDbWxaNXNPRDQwZ1ZteUUvcHFCcllXRHo4OWlFQ3o2RjJSUVlK?= =?utf-8?B?RG9tTGRVQ015R0FTTjVCcXlBbkRTY1pBQlk2dXc4SEZWYkhFdVFsekV5cGdS?= =?utf-8?B?TU5Tay9Ka1o1aFlpSDloOWMrQmF3UU54OVlPSTJSTHdzNXIwVW9VVDFjNHpQ?= =?utf-8?B?NkRSM3cvMnFTcVJ4RCtmN0krd2J0MjM3bE9Id2VINzYvbjJQWUhqMy9sOSsv?= =?utf-8?B?T1JSWmU2OE9TVWxKdGFVWGs5ajhKK1JzOXhBdFhSV2VJQjNVVnZIRWRxUUkw?= =?utf-8?B?cE5XSmgxZGFublVJamk1VUZkOFdudXpXeGFtenRxbEtGSmYyRFd0VWszZE1u?= =?utf-8?B?V2gwTStnR1BqZUdpVHcrTm90Ulg0VWVKb0d2eEh0NUNVeEZQcmFRdDhwU2VR?= =?utf-8?B?cG1jWm5TeVVtMkNzZzhmaFNUY1V1clBpNnhLYTZBc3R4WnI0aVllVTV2UDQr?= =?utf-8?B?V2lKRWlzQk5lTU5tZ0RQNUVCN1I2K082a01ray9NSmxYenBIOW9EeTY0S0sw?= =?utf-8?B?ZlJad045eFJKcDBlWFZKeXpJcnBrVDBMYmxWbWRzYnRCaTVsOUQvK0Jsa0g3?= =?utf-8?B?NXM4eUJXckRxc1prcVMva2FucGVObTNSK3k1SVNSZDJBaElOV3JGMmhucmlw?= =?utf-8?B?bkI5dXNYZkRtV203TjFkTGhtek5NeWhMK3VobnNzUXlzb3p5K3RMM2o4MHNX?= =?utf-8?B?TUxBS0dlV0RYWUNzNUdvNE9ZR0JDekVaMmowRlVyUGFQcHczVFE2MnovMWRW?= =?utf-8?B?bjkzZVNRNi96KzZHNHBWNWJzT09QRkJyRWtZeUIycHFRTVBodURhbEtucUFn?= =?utf-8?Q?jLG37VcEPVcoI=3D?=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0067_01D6CF0F.F66547A0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR0702MB3603.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f128d51b-21e4-45c4-de2e-08d89d1eb805
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Dec 2020 15:17:33.4197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: nN8vk25h+yarMiPhJ8GIc44tIuIM/ZZViOeZWTU1zC00/Vl5rM0HViad9BHNtuG9z4IxRNKIN03Ot2KzXCYM+dVEmEhhQhL9gr+oi2+Tb/Q=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM8PR07MB7474
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/nwQ6TMCvC-gHnVMfATasapDnVxs>
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Dec 2020 15:17:39 -0000

Hi Magnus,

We have discussed the update with the authors + DavidB with the result below.
One more bullet added + clarification text to the paragraph after the list.

OLD TEXT
5.  Management and Control Information Summary
   The following summarizes the set of information that is needed to
   configure DetNet MPLS over UDP/IP:
   o  Label information (A-labels, S-labels and F-labels) to be mapped
      to UDP/IP flow.  Note that for example, a single S-Label can map
      to multiple sets of UDP/IP information when PREOF is used.
   o  IPv4 or IPv6 source address field.
   o  IPv4 or IPv6 destination address field.
   o  DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class
      Fields.
   o  UDP Source Port.
   o  UDP Destination Port.
   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller [RFC8655] or management
   plane.
 
NEW TEXT
5.  Management and Control Information Summary
   The following summarizes the minimum set of information that is needed to
   configure DetNet MPLS over UDP/IP:
   o  Label information (A-labels, S-labels and F-labels) to be mapped
      to UDP/IP flow.  Note that for example, a single S-Label can map
      to multiple sets of UDP/IP information when PREOF is used.
   o  IPv4 or IPv6 source address field.
   o  IPv4 or IPv6 destination address field.
   o  DSCP Field in either IPv4 Type of Service or IPv6 Traffic Class
      Fields.
   o  UDP Source Port.
   o  UDP Destination Port.
   o  use/non-use of UDP checksum.
   This information MUST be provisioned per DetNet flow via
   configuration, e.g., via the controller [RFC8655] or management
   plane. Not using the UDP checksum has to be evaluated on a
   case-by-case basis for a given network scenario based on the
   exception criteria’s defined in [RFC7510], particularly when 
   IPv6 is used.
END

I hope that has resolved your concerns, please confirm.

Many thanks
Bala'zs


-----Original Message-----
From: Magnus Westerlund <magnus.westerlund@ericsson.com> 
Sent: Thursday, December 3, 2020 10:13 AM
To: iesg@ietf.org; balazs.a.varga=40ericsson.com@dmarc.ietf.org; David.Black@dell.com
Cc: detnet@ietf.org; eagros@dolby.com; draft-ietf-detnet-mpls-over-udp-ip@ietf.org; detnet-chairs@ietf.org
Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-over-udp-ip-07: (with DISCUSS)

Hi,

David's suggestions is definitely the direction I was considering to resolve
this.

Cheers

Magnus

On Wed, 2020-12-02 at 22:40 +0000, Black, David wrote:
> Hi Balazs,
> 
> Digging in a little deeper, I concur with Magnus's underlying concern that
> this draft ought to say something about UDP checksums with IPv6.  There's a
> useful starting point at the end of the Introduction (Section 1):
> 
>    As specified in [RFC7510]: "MPLS-in-UDP MUST NOT be used over the
>    general Internet, or over non-cooperating network operators, to carry
>    traffic that is not congestion controlled."  This does apply to
>    DetNet networks as this document focuses on solutions for networks
>    that are under a single administrative control or within a closed
>    group of administrative control.
> 
> That suggests that the first two exceptions (a & b)  in Section 3.1 of RFC
> 7510 (both of which involve single administrative control) are more likely to
> apply to DetNet than the third one (c, based on higher layer recovery and/or
> error tolerance).  It could be helpful to say that in an added paragraph on
> UDP checksums (for both v4 and v6) at the end of Section 4 in this draft.
> 
> I would also suggest aligning the text quoted above (from the end of Section
> 1) with the text used in exceptions a. & b. in Section 3.1 of RFC 7510, as I
> think roughly the same scope is intended.  In particular, it appears to me
> that this draft's notion of "closed group of administrative control" would
> fall under the notion of "single administrative control" in RFC 7510 (FWIW,
> I'm an author of RFC 7510).
> 
> The suggestion to add use/non-use of UDP checksum to the list of management
> and control information in Section 5 is a good idea - that addition ought to
> cite Section 3.1 of RFC 7510 for the conditions under which the UDP checksum
> may be disabled for IPv6 (per RFC 7510, UDP checksum for IPv6 "MUST be
> implemented" for MPLS-in-UDP).
> 
> Thanks, --David
> 
> > -----Original Message-----
> > From: detnet <detnet-bounces@ietf.org> On Behalf Of Balázs Varga A
> > Sent: Wednesday, December 2, 2020 12:25 PM
> > To: Magnus Westerlund; The IESG
> > Cc: eagros@dolby.com; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-
> > ip@ietf.org; detnet-chairs@ietf.org
> > Subject: Re: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-
> > over-
> > udp-ip-07: (with DISCUSS)
> > 
> > 
> > [EXTERNAL EMAIL]
> > 
> > Hi,
> > 
> > Chapter 5. of draft-ietf-detnet-mpls-over-udp-ip provides a _non-exhaustive_ 
> > list of
> > control and management plane information.
> > DetNet does not changes rules of rfc7510: if the exceptions listed in 3.1 of
> > rfc7510
> > applies, then using zero checksum is allowed; otherwise not.
> > 
> > A possible solution can be to add an additional information element to the
> > list in
> > chapter 5, which allow or not the usage of zero-checksum.
> > 
> > Thanks & Cheers
> > Bala'zs
> > 
> > 
> > -----Original Message-----
> > From: detnet <detnet-bounces@ietf.org> On Behalf Of Magnus Westerlund via
> > Datatracker
> > Sent: Wednesday, December 2, 2020 4:47 PM
> > To: The IESG <iesg@ietf.org>
> > Cc: eagros@dolby.com; detnet@ietf.org; draft-ietf-detnet-mpls-over-udp-
> > ip@ietf.org; detnet-chairs@ietf.org
> > Subject: [Detnet] Magnus Westerlund's Discuss on draft-ietf-detnet-mpls-
> > over-udp-
> > ip-07: (with DISCUSS)
> > 
> > Magnus Westerlund has entered the following ballot position for
> > draft-ietf-detnet-mpls-over-udp-ip-07: 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://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-detnet-mpls-over-udp-ip/
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> > 
> > So there might be something missing here in regards to zero-checksum in UDP
> > when using IPv6. So Section 3.1 in RFC 7510 discusses this for MPLS over UDP
> > and
> > have some considerations that needs to be done if one are intending to use
> > zero
> > checksum. To me it appears that DETNET flows can not be guaranteed to always
> > fulfill these, and in case you think you can motivate it should probably be
> > stated
> > explicitly and normatively allow it. So if it can't be guaranteed to fulfill
> > these
> > requirements then the next question exists: Do the possibility to use zero-
> > checksum
> > for this flow become something the control plane needs to signal it?
> > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet
> > 
> > _______________________________________________
> > detnet mailing list
> > detnet@ietf.org
> > https://www.ietf.org/mailman/listinfo/detnet