Re: [RTG-DIR] [Detnet] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Thu, 30 January 2020 07:07 UTC

Return-Path: <Alexander.Vainshtein@ecitele.com>
X-Original-To: rtg-dir@ietfa.amsl.com
Delivered-To: rtg-dir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9E21200C3; Wed, 29 Jan 2020 23:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.492
X-Spam-Level:
X-Spam-Status: No, score=-1.492 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=IVWnubNS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=q9b70ycB
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 BddFlHVI7ceZ; Wed, 29 Jan 2020 23:07:52 -0800 (PST)
Received: from mail1.bemta25.messagelabs.com (mail1.bemta25.messagelabs.com [195.245.230.8]) (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 0C0B512006B; Wed, 29 Jan 2020 23:07:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1580368069; i=@ecitele.com; bh=AnBnSpG+Xv9hR/TSA+m83HUX2WOcIYrzz43gE9x69Gs=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=IVWnubNSQ1KjQPHoFtENww/V8SlQuFjU6WUnY+hr1pQfFYZpR15mHmkf3c0kA8hw7 /4PMDWNPmEx+mkIefP/hsYKwAQUWNgvcDSrsaBis+VIcDIAmeUNIg/4132036IMUD8 SpO67dINSnfblRb+eeBtGGmH41kdnJUU6UROqiD8=
Received: from [46.226.52.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-8.bemta.az-a.eu-west-1.aws.symcld.net id F2/F1-26121-4C0823E5; Thu, 30 Jan 2020 07:07:48 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0wbZRjHeXvX3oEtOcq6vjRj0m4KQw9bRFe NJFOXBYMkTJNphq0r5UY72lKvBdqZABMM48e0MHQDWlon+EfH7xrFaVArc4VonZgpP+bmXAmM ZSLgYD+c8a7H5vznyed5vs/7PN978x6OiL2YDKccdoq26EwKQRwqvtY0QH5TnalV/uyXqgOHB wTq0B0XX317uQNVdwwO8NXnen7C1GPuG4ja1zOL7cBybl0/J8ipHb3Gz+nqusnL+XOoRpCP7u UbLYWljn18Q03dCM/q+h11/HishlcNmqbRBhCHA6IbgZFgPdYAYpnkWxSeen8jJwQADJ1pwdg EJXoR+NvKZcAmYsLFg1N9fTz2iJi4COBQcCfLAiIbDp38VcDyBuJB2Bq6E92BEDM8+KV3EmGF RGI//LRvns81FcP6+ndRjjPh0VBblFHiIXgrPB/1JCI0MOyrQbnNPQicHp6Mbo4ltsOjfWHAG d8I18Z7onWEkMLpiDfKkCBg1xc/IBxL4JXL//C5/kJ4cfYDwNXl8PgFN8ZxMpzwNjJ1nOEt8O N5DVfOg51nZ9Zb0uHiQivKsQl6whN8jlNh7VLnOm+Cn/ln1tnP3Gm3hrssPQy5V9bPbob+I5d QF1C23+eaYwvs8Iyg7dHPT4BjbRGGcaa+DfafeoxrkcPWxksYx2nwbbcHu7/uA5gfqAtpY7HB btYZTaRKqSRVqkxS9VQWw6oM3UFSl0GVkRWUzU4yaYUtw+Y0601FGRbKPgSYF1hkDVLD4HTvY kYQJOE8hUTkrMzUiuMLS4ucBp3N8DpdZqJsQbAJxxVQhFQxWgJNFVOO/UYT847vyhAXKjaItK wssll1ZpuxmJPGwSu464rnBIL/cfNDJo75u5i4FI1r0Vg3yMapRTaOerpPIGLUUmqhZFLRKju OYMcZyiz3lt39byZAsixRBGJiYsRCK0Wbjfb/6wtAigNFomiZnSI0Wuz3PC0wdnmM3VWdkrVr 1/0nyap52x+XP9nY8lJlIk8fnJt8L8tTIWn/S3vI5yzx0e3Z32GPHGkeqzpLFr0Zn5rrJreN7 34ur4efN1MpeSLwd/Gx5dzzpUkm4Y0XSs7sOpyWMpIvp1/MxPaYP1pKiD1dNeGl9m5Ncvc6JV c1+cNAlZJ2sDwSOXDeEp/87K7AO3Jpw5wxNxzxff9L0VWkRtCieb53t/Dh45jVadcsHiJH1w5 sxreSjw70xWal162ufDVbCZSSrxefeU1Oh0o89AX+loqm5oLyV1P6r7sl8tpQdlp5p/7zudrm PTQWdLj0nbLVKeV8QQgP9+9Txu0w7ny6YGDwtjb3rU9OqlLfeDnQFnY9oEBtBp0qHaFtun8B/ iLOdrIEAAA=
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-22.tower-267.messagelabs.com!1580368064!1646283!1
X-Originating-IP: [18.237.140.176]
X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass
X-StarScan-Received:
X-StarScan-Version: 9.44.25; banners=ecitele.com,-,-
X-VirusChecked: Checked
Received: (qmail 25676 invoked from network); 30 Jan 2020 07:07:46 -0000
Received: from p01a.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.176) by server-22.tower-267.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 30 Jan 2020 07:07:46 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OJoyf5aI9lMuZhKGbBFYxQ2Sdsz9SLzRSWqq63gOVb1PC4PC+7WLxIYCXn7Fd2Kmad0NpZDNYdJCwi5JqTYjU0OtWyByyr+/zpwrdBumLpzxV2g6h/E/ebm9Jkwa0EdOOh1eHvDM6JqeI/Jrl5isS2Hk5Rft3uShAuw/pzYeWM7rrMJlF4pufpEdsPeq52Q1DJCr87f/ecKenuieT2X+opVXJ5PKfVQXTdemqqYsU7EexGK1i3me+ydaea5QXOR0zjA5BUFncrXwR8uKJfenhT/4SZ/Z/VOgZ599T5qoJ9NhmBMwSMWyzGx3htI/hHz4Rp8/V9ADuC6gdlSn6Xtj/w==
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=H7uUIAzCvaRhO/lgFi5dxVh0GNb09T1NtWsM0SEh3e4=; b=Anb05ioLJ0YRV4A+wZWkRNZuOMwid1eQ+m1DrG4kAOXDlmLc7WFBNFtN/wYngnAQ/iyUfEH1tQqmQ8w/jpGOyFL/ebZD/ag6nrnOUaI7bDdXMs2m4FP8SiVe/la6CMv03R/hicWUM/lBeNxsbgjuQFArmiJ/QC0zosoTbAcvuV9mPV1q0HUP/AaDAoUITo2NnA5mHAnYo/hZwThufv9NzgE0Wqsjeo9XXE9iftACmJRcIxDP9/wUbNSQJ7bGGJxWgCLSmR9g9nSXc8kcYbZMXByG34CG5Azu0Vm/T8OKYmOFqeDkcMvyELFnl7mPjpLDJnxP1XYYZ+sK99i4NhHcVA==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ecitele.com; dmarc=pass action=none header.from=ecitele.com; dkim=pass header.d=ecitele.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector2-ECI365-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H7uUIAzCvaRhO/lgFi5dxVh0GNb09T1NtWsM0SEh3e4=; b=q9b70ycBwSZ7gVT2ypMCzGKUDCGtNzaC5r1Om/wCimLpzmA6YBdZCuoN4WXUIYsVo0bdzSLfSABAbafqa+o3IckBn7q+Ny83NgUykbxdIoDUm+jMtm5Drz7A/5LK+WMN4VCrxiu0M+rgPY47BENvn4K9Az/qmv1/9QOb/URWL3c=
Received: from DB8PR03MB5865.eurprd03.prod.outlook.com (10.255.16.31) by DB8PR03MB5787.eurprd03.prod.outlook.com (20.179.250.223) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Thu, 30 Jan 2020 07:07:40 +0000
Received: from DB8PR03MB5865.eurprd03.prod.outlook.com ([fe80::4db4:42fa:5ee2:8de3]) by DB8PR03MB5865.eurprd03.prod.outlook.com ([fe80::4db4:42fa:5ee2:8de3%7]) with mapi id 15.20.2665.027; Thu, 30 Jan 2020 07:07:40 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Don Fedyk <dfedyk@labn.net>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "'Yemin (Amy)'" <amy.yemin@huawei.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>, 'Balázs Varga A' <balazs.a.varga@ericsson.com>, "draft-ietf-detnet-data-plane-framework.authors@ietf.org" <draft-ietf-detnet-data-plane-framework.authors@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: [Detnet] [RTG-DIR] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03
Thread-Index: AQHV1tebd51iQA4x6Um88u9IwU+NY6gCydew
Date: Thu, 30 Jan 2020 07:07:40 +0000
Message-ID: <DB8PR03MB5865F69F32ABBDB5C95D89329D040@DB8PR03MB5865.eurprd03.prod.outlook.com>
References: <DB8PR03MB5865E272423112C88345259A9D2B0@DB8PR03MB5865.eurprd03.prod.outlook.com>, <VI1PR07MB53898C6166A375B54A023BC4AC3F0@VI1PR07MB5389.eurprd07.prod.outlook.com> <DB8PR03MB586535529B4F1608434F51449D3F0@DB8PR03MB5865.eurprd03.prod.outlook.com> <015701d5ca62$538357a0$fa8a06e0$@labn.net> <DB8PR03MB58656C10879405CC2AA933549D0D0@DB8PR03MB5865.eurprd03.prod.outlook.com> <00c301d5d6d7$5de8aca0$19ba05e0$@labn.net>
In-Reply-To: <00c301d5d6d7$5de8aca0$19ba05e0$@labn.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.234.241.1]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1557bab6-d692-4bb9-f13e-08d7a5531836
x-ms-traffictypediagnostic: DB8PR03MB5787:
x-microsoft-antispam-prvs: <DB8PR03MB5787241AD2AF9A8365492EB49D040@DB8PR03MB5787.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 02981BE340
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(346002)(396003)(39860400002)(366004)(136003)(376002)(189003)(199004)(54906003)(4326008)(7696005)(9686003)(66574012)(6916009)(478600001)(55016002)(8936002)(8676002)(81156014)(316002)(2906002)(81166006)(186003)(33656002)(66446008)(66556008)(76116006)(64756008)(66946007)(66476007)(86362001)(26005)(6506007)(5660300002)(53546011)(30864003)(71200400001)(52536014); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8PR03MB5787; H:DB8PR03MB5865.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: dcNiJ7a2kDTMrTyzvfGFLmyp68pgguHRsr77QrxusZBPM1l2KvLHLI0y/Wm//66x+AXxBwoy6lPDuaUBEQvMpiUwSYuy5CkYRJpOhShEAoZNnT0+JA4OC7bI0JToCkN0IaTYpSypx1hVb1uIYoSsBpH8JZw6qhvrcyXhg7DIV6C8dEkA1AcS+oPuuZMRshWGiEKg1VTRJD1SKFl+xh+KpKL3hKVNiQPaDI7uVJvogS+VlWFiHEELjEnqpWBtc8Ku1+zlWrS9aF51z2wZUYXvnITfbEiKP6NyyV6wy8WzrhpblIX0Ecy5Fi9WOCcL21MkpJ3CVqyT/ldvT9OJ8aW0xjzZCzGroa0+uo+CHwwUJwWwwxdAztczJ0sjP3muSuVeAl3QeHkUBU2dQ9xPWEfoUmqR0KKaUfs1i8vT4w76JGYCLfkKciDIM5cUwrVpJFeIKz3607mFJ2hOu5T4+SKO2xGupPp97ERXAeIS6tvHklsnJqaKxKZIbM+WO2MQ1v6Q5bP3nVcJxoDGHwjvvZ4YAzP4QrtsR7NSCuPRUZY4NQCG8VPQSVP9y1Ay+b2bVXn5QPwY7nHl9TPYuSCioALOE5cwC4gtdMD/7rBSNPkppR5nMFdP0yPfwBwmw1TBgGPs
x-ms-exchange-antispam-messagedata: Zu8qTxGaizwQvJF3kmY0vPuHgkrr0yN+ys4q4DHaHX5aMGGUmxpc4ImmnDUQh8ygiqpNGbQssWtlToInqsGk0N/TwoX2MoijQ4uhqwnfpnIRBjrh2lpSnJdBnxc7KJeHcbzzu7WTFemjT6sowSwJDA==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_DB8PR03MB5865F69F32ABBDB5C95D89329D040DB8PR03MB5865eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 1557bab6-d692-4bb9-f13e-08d7a5531836
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Jan 2020 07:07:40.2727 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /O6miZPrDOxQH0IUepFznTOSune0oElzYOtjyratmT9Fbgb+S83Z+kBSLmv34suJDZg/O8J4DoFxyFWMx99yVQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB5787
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/vp3L-8SiElSJVu0EzJA2v4rAptY>
Subject: Re: [RTG-DIR] [Detnet] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jan 2020 07:07:55 -0000

Don,
Lots of thanks for taking care of that.
I will look carefully at the differences and provide a detailed response a in a few days.

Regards,
Sasha

Office: +972-39266302
Cell:      +972-549266302
Email:   Alexander.Vainshtein@ecitele.com

From: Don Fedyk <dfedyk@labn.net>
Sent: Wednesday, January 29, 2020 9:08 PM
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Cc: rtg-dir@ietf.org; 'Yemin (Amy)' <amy.yemin@huawei.com>; rtg-ads@ietf.org; 'Balázs Varga A' <balazs.a.varga@ericsson.com>; draft-ietf-detnet-data-plane-framework.authors@ietf.org; detnet@ietf.org
Subject: RE: [Detnet] [RTG-DIR] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03

Hi Sasha

Sorry, now I had some travel.  I’m attaching the pdf of the diff (since html I attached failed).  (The PDF seems to lose the color highlighting).  I attached the modified file and you can do your own diff.
Note that my comments are still of the Jan 13th date.  I will address your points where noted below.  And then provide an updated draft and diff.
So you may want to wait for the update.

Comments/clarifications below. [Don]
Also I have snipped out agreed sections for brevity.

Thanks,
Don

From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On Behalf Of Alexander Vainshtein
Sent: Tuesday, January 21, 2020 6:42 AM
To: Don Fedyk <dfedyk@labn.net<mailto:dfedyk@labn.net>>
Cc: rtg-dir@ietf.org<mailto:rtg-dir@ietf.org>; 'Yemin (Amy)' <amy.yemin@huawei.com<mailto:amy.yemin@huawei.com>>; rtg-ads@ietf.org<mailto:rtg-ads@ietf.org>; 'Balázs Varga A' <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>>; draft-ietf-detnet-data-plane-framework.authors@ietf.org<mailto:draft-ietf-detnet-data-plane-framework.authors@ietf.org>; detnet@ietf.org<mailto:detnet@ietf.org>
Subject: Re: [Detnet] [RTG-DIR] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03


Don,

First of all, apologies for a much delayed response.

[Don] No worries



Unfortunately I could not open the diff you've sent.

If you can re-send it in some commonly readable other format, it would be great (HTML or even PDF would definitely be the best).

Otherwise please send the new version of the draft as plain text.



Meanwhile please see some preliminary comments to your answers inline below.

It seems that most issues I’ve raised in my review have been successfully resolved.



Regards, and, again, apologies for the delay,

Sasha



Office: +972-39266302

Cell:      +972-549266302

Email:   Alexander.Vainshtein@ecitele.com<mailto:Alexander.Vainshtein@ecitele.com>



<snip>



[Don] Two authors are now contributors. [[Sasha]] As I have said, this is between the team of the authors/contributors and the ADs, I am OK with the proposed resolution.

[Don] Agreed



<snip>

2.            After reading both  RFC 8655 and the DetNet Data Plane Framework

draft I have failed to understand whether the “Packet Ordering Function

(POF)” is expected to actually reorder (or try to reorder) packets that have

been received out of order, or could simply discard such packets:



a.            On one hand:



                                                  i.     The DetNet Data

Plane Framework draft says in Section one that “The service sub-layer is

used to provide  DetNet service protection and reordering”



                                                 ii.     Section 3.2.2.2 of

RFC 8655 says that “The POF uses the sequencing information to reorder a

DetNet flow's  packets that are received out of order”



b.            On the other hand, neither of these documents mentions the need for

additional resources (buffers and timers) that are required for reordering

of packets received out of order, and impact of this operation on the packet

delay variation (a.k.a. jitter). What’s more, allocation of these resources

(if they are used) would have to be done at the DetNet service sub-layer,

and this seems to contradict RFC 8655  where allocation of resources is

associated just with the forwarding sub-layer (see Figure 2 in Section 4.1.1

of RFC 8655 that is also reproduced verbatim in the DetNet Data Plane

Framework draft).

c.             For comparison, the PWE3 documents that deal with sequencing and

reordering clearly differentiate between reordering and discard of packets

that have been received out of order:



[Don] Ordering is at the server [[Sasha]] Did you mean “Service” here? sub-layer. Resources - buffers for

reordering are at this layer. Updated

[Don] Yes Service Updated text delineates where buffer resources are used.





Section 1., paragraph 5:



OLD:







    DetNet flows may be carried over network technologies that can



    provide the DetNet required service characteristics.  For example,



    DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive



    Network (TSN) [IEEE802.1TSNTG] sub-networks.  However, IEEE 802.1 TSN



    support is not required and some of the DetNet benefits can be gained



    by running over a data link layer that has not been specifically



    enhanced to support TSN.







NEW:







    DetNet flows may be carried over network technologies that can



   provide the DetNet required service characteristics.  For example,



    DetNet MPLS flows can be carried over IEEE 802.1 Time Sensitive



    Network (TSN) [IEEE802.1TSNTG] sub-networks.  However, IEEE 802.1 TSN



    support is not required in DetNet.  TSN frame preemption is an



    example of a forwarding layer capability that is typically not



    replicated in other forwarding technologies.  Most of DetNet benefits



    can be gained by running over a data link layer that has not been



    specifically enhanced to support all TSN capabilities but for certain



    networks and traffic mixes delay and jitter performance may vary due



    to the forwarding sub-layer intrinsic properties.



[[Sasha]]  The change above seems to address my other question (impact of non-support of TSN frame pre-emption inn other forwarding technologies.

[[Sasha]] I still wonder however, whether “typically not” is strong enough, or we can state that frame pre-emption is a unique capability of TSN?

[Don] Well I am aware of other technologies that used preemption and internet search say  RFC2686 and RFC2687 is one example.  The wording was intentional on my part.

Also we do not want to preclude other data planes that may have the capability.





Section 4.2.3., paragraph 1:



OLD:







    As discussed in Section 1, this document does not specify the



    mechanisms needed to eliminate packet contention, packet loss or



    reduce jitter for DetNet flows at the DetNet forwarding sub-layer.



    The ability to manage node and link resources to be able to provide



    these functions is a necessary part of the DetNet controller plane.



    It is also necessary to be able to control the required queuing



    mechanisms used to provide these functions along a flow's path



    through the network.  See [I-D.ietf-detnet-ip] and Section 4.1 for



    further discussion of these requirements.







NEW:







    As discussed in Section 1, this document does not specify the



    mechanisms needed to eliminate packet contention, packet loss or



    reduce jitter for DetNet flows at the DetNet forwarding sub-layer.



    The ability to manage node and link resources to be able to provide



    these functions is a necessary part of the DetNet controller plane.



   [[Sasha]]  The new text seems to begin here.


    It is also necessary to be able to control the required queuing



    mechanisms used to provide these functions along a flow's path



    through the network.  See [I-D.ietf-detnet-ip] [[Sasha]] Can you please provide a reference to the specific text in this draft? and Section 4.1 for

[Don] Will add a section reference.



    further discussion of these requirements.  Some forms of protection



    may enforce packet loss or change jitter characteristics in the cases



    where packets are reordered when out-of-order packets are received at



    the service sub-layer.



                                                  i.     Section 4.2 of RFC

4385

<https://clicktime.symantec.com/33EPoJPGK3P16uEhFVxEQPF6H2?u=https%3A%2F%2Ft

ools.ietf.org%2Fhtml%2Frfc4385>  provides a clear definition of PWE packets

received in and  of order. It then says that “If the packet is found to be

in order, it MAY be delivered  immediately” and “Packets that are received

out of order MAY either be dropped or  reordered.  The choice between

dropping or reordering an out-of-sequence packet is at the discretion of the

receiver”.  I.e., ordering can be achieved by simply dropping packets that

have been received out of order



                                                 ii.     Section 7.3.2 of

RFC 4197

<https://clicktime.symantec.com/37VT1KAX7zdhNmeuVcyLo5c6H2?u=https%3A%2F%2Ft

ools.ietf.org%2Fhtml%2Frfc4179>  (that deals with TDM PWs) says that

packets received out of order “SHOULD be reordered if not judged to be too

late or too early for  playout”



d.            From my POV the DetNet Data Plane Framework draft should clearly

define the expectations from the POF regarding handling of packets that have

been received out-of-order, and the impact of reordering (if it is used) on

the goals of the DetNet services.



[Don] add a text to clarify. (also above change).



Section 3., paragraph 7:



OLD:







    The service sub-layer provides additional support beyond the



    connectivity function of the forwarding sub-layer.  An example of



    this is Packet Replication, Elimination, and Ordering functions see



    Section 4.3.







NEW:







    The service sub-layer provides additional support beyond the



    connectivity function of the forwarding sub-layer.  An example of



    this is Packet Replication, Elimination, and Ordering functions see



    Section 4.3.  The ordering (POF) uses sequence numbers added to



    Packets

[[Sasha]] Are sequence numbers always added to packets in DetNet?

[Don] Nope

Quoting from the detnet-ip draft<https://tools.ietf.org/html/draft-ietf-detnet-ip-04>, section 4.2:


   As noted earlier, service protection must be implemented within each
   link / sub-network independently, using the domain specific
   mechanisms.  This is due to the lack of unified end-to-end sequencing
   information that could be used by the intermediate nodes.

This suggests to me that DetNet over IP data plane does not add any sequence numbers to the packets.

[Don] DetNet over IP does not add a sequence number but the DetNet architecture states that sequence numbers at higher Layers may be utilized for example IPsec.

And the detnet--mpls draft<https://tools.ietf.org/html/draft-ietf-detnet-mpls-04> in Section 4.2.1 includes the sequence number space of 0 (zero) bits as MUST to support (along with 16 bits and 28 bits space), effectively making it possible not to add a meaningful sequence number.

[Don] Will look to see if there is something I can clarify but if you have specific text please point it out.





  enabling a range of packet order protection from simple



    ordering and dropping out-of-order packets to more complex reordering



    of a fixed number of out-of-order, minimally delayed packets.



    Reordering requires buffer resources and has impact on the delay and



    jitter of packets in the DetNet flow.



<snip>



5.            The draft states, in Section 4.2.4., that “DetNet applications

typically generate bidirectional traffic”.



1.            I have looked up RFC 8557

<https://clicktime.symantec.com/3S5RkymWb9AHCmyh98pDnNf6H2?u=https%3A%2F%2Ft

ools.ietf.org%2Fhtml%2Frfc8557>  and, especially, RFC 8578

<https://clicktime.symantec.com/32QD67HM2j2fhREf17yZBwp6H2?u=https%3A%2F%2Ft

ools.ietf.org%2Fhtml%2Frfc8578> , but did not find there any justifications

for this statement. In fact, some of the application listed in RFC 8578

(e.g. all applications related to audio and video) seem to be inherently

unidirectional.

2.            I think that some clarification, preferably with references to

specific DetNet use cases that require bidirectional traffic, would be

useful



[Don]



Section 4.2.4., paragraph 1:



OLD:







    DetNet applications typically generate bidirectional traffic.  IP and



    MPLS typically treat each direction separately and do not force



    interdependence of each direction.  MPLS has considered bidirectional



    traffic requirements and the MPLS definitions from [RFC5654] are



    useful to illustrate terms such as associated bidirectional flows and



    co-routed bidirectional flows.  MPLS defines a point-to-point



    associated bidirectional LSP as consisting of two unidirectional



    point-to-point LSPs, one from A to B and the other from B to A, which



    are regarded as providing a single logical bidirectional forwarding



    path.  This is analogous to standard IP routing.  MPLS defines a



    point-to-point co-routed bidirectional LSP as an associated



    bidirectional LSP which satisfies the additional constraint that its



    two unidirectional component LSPs follow the same path (in terms of



    both nodes and links) in both directions.  An important property of



    co-routed bidirectional LSPs is that their unidirectional component



    LSPs share fate.  In both types of bidirectional LSPs, resource



    reservations may differ in each direction.  The concepts of



    associated bidirectional flows and co-routed bidirectional flows can



    also be applied to DetNet IP flows.







NEW:







    In many cases DetNet flows can be considered unidirectional and



    independent.  However, there are cases where the DetNet service



    requires bidirectional traffic from a DetNet application service



    perspective.  IP and MPLS typically treat each direction separately



   and do not force interdependence of each direction.  MPLS has



    considered bidirectional traffic requirements and the MPLS



    definitions from [RFC5654] are useful to illustrate terms such as



    associated bidirectional flows and co-routed bidirectional flows.



    MPLS defines a point-to-point associated bidirectional LSP as



    consisting of two unidirectional point-to-point LSPs, one from A to B



    and the other from B to A, which are regarded as providing a single



    logical bidirectional forwarding path.  This is analogous to standard



    IP routing.  MPLS defines a point-to-point co-routed bidirectional



    LSP as an associated bidirectional LSP which satisfies the additional



    constraint that its two unidirectional component LSPs follow the same



    path (in terms of both nodes and links) in both directions.  An



    important property of co-routed bidirectional LSPs is that their



    unidirectional component LSPs share fate.  In both types of



    bidirectional LSPs, resource reservations may differ in each



    direction.  The concepts of associated bidirectional flows and co-



    routed bidirectional flows can also be applied to DetNet IP flows.

[[Sasha]] After re-reading 4.2.4 I understand that the most relevant part of it is para 3 (beginning with the words “DetNet's use of PREOF”.

With this understanding in mind the new text looks stuffiest.

[Don] stuffiest = to suffice?  Stuffiest makes me chuckle though. 😊


<snip>

___________________________________________________________________________

This e-mail message is intended for the recipient only and contains information which is 
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this 
transmission in error, please inform us by e-mail, phone or fax, and then delete the original 
and all copies thereof.
___________________________________________________________________________