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

Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> Tue, 14 January 2020 08:10 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 EBA6E12009E; Tue, 14 Jan 2020 00:10:13 -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, 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, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ecitele.com header.b=MHJcbCrS; dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.com header.b=LggJUKzR
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 rVuc52Rw2SwD; Tue, 14 Jan 2020 00:10:11 -0800 (PST)
Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (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 32E9112007C; Tue, 14 Jan 2020 00:10:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ecitele.com; s=eciselector10072019; t=1578989408; i=@ecitele.com; bh=LoJzThJKnoP+AdcW4mVy6IXdd9Ipl42VZ2sV5fRnxn0=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=MHJcbCrS5/l9VhE1H9Nu5241jOoIyYoZm+G9RRfy1W7ypQoKsbFP/lEr39RWPqeUa 5YMM2C0SGRytV+nSu1Hu4aIYLtoSbK/Odrw3vtVkAbgBVGCmYwMmHHp4o0SQsK5kEt P3k63mezIxvNH4UD8+WCOdbBbKVmoYutHw7wJUK8=
Received: from [85.158.142.200] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id 87/9C-12462-F577D1E5; Tue, 14 Jan 2020 08:10:07 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAJsWRWlGSWpSXmKPExsUi9LZno25cuWy cwdd/1habOzawWZz4O4HV4ven2SwWszduYLW4uuYyu8XJOT+YLRasecruwO7x6+tVNo+WI29Z PZYs+cnk8WFTM1sASxRrZl5SfkUCa8a7qaEF8+8wVax+tZCtgfHOdaYuRi4ORoGlzBIHVt+Cc o6xSCzb/IcNwtnMKHHi+CR2EIdFYC2zROOzacwgjpBAP5PE7MevgDKcQM59Ron5s0NAbDYBW4 lNq++ygdgiAvISU078ZQGxmQVuM0nMnCYMYgsLpEk8uPaQCaImXeLvgnYWCNtNYvH6RcwgNou AqsTzqf/B5vAKxEoc334FavE6Jomb55rBGjgFzCUmX5kMNohRQEzi+6k1TBDLxCVuPZkPZksI CEgs2XOeGcIWlXj5+B8rRH2SxP2nCxkh4ooSM+7NYYewZSUuze8GinMA2coSW17EQoR9Jdbcm sMGYWtJXD+yhgXCzpFo/PMDKq4u0fJxHiuELSPRf3YGK8jNEgKbWCR23XnCCAmsZIkTcz5DNc tJrOp9yDKB0WAWkrNnAa1mFtCUWL9LHyKsKDGl+yH7LHBQCEqcnPmEZQEjyypGy6SizPSMktz EzBxdQwMDXUNDY11TXSMDY73EKt0kvdRS3eTUvJKiRKCsXmJ5sV5xZW5yTopeXmrJJkZg8kop ZD29g3HWp7d6hxglOZiURHmvhUrHCfEl5adUZiQWZ8QXleakFh9ilOHgUJLgtSqTjRMSLEpNT 61Iy8wBJlKYtAQHj5IIb1wpUJq3uCAxtzgzHSJ1itGbY8LLuYuYOd79XAwkT65aAiTbN4LIzX OXAskjIFKIJS8/L1VKnHceyAgBkBEZpXlwC2AZ4RKjrJQwLyMDA4MQT0FqUW5mCar8K0ZxDkY lYd7dIFN4MvNK4O54BXQiE9CJXJclQU4sSURISTUwrTq04MzO2V9ltI2XerxW7jQuNNZRCORg rmz6weITsjzmVPhuw8vBrx0uvsncLfN3QlrJfKu7Ky/Fxhas4GWfwn8uc8vdS2rG0qL9sqE7b kmxKVtPa/lw7EbWM6ub4WIrLAW4LpsVzBPTff1uY9XP9jjGZWLs4dULp753/LbJLOL1jqdzHO R6zz7es+Kt5VVf0bYt1x8bKGQW6DWreL+WVXGJfRD9jS3ruAAvQ79uoebdLntz7VBppbWicy6 p15nmRci9TTm3/ERl3F1m3wMx6Vs+qnZmdW7rrP9YdvXXk9V694UefCs7k3LKR9job5rThD7z t2kpq+SMfy9gcnZbncbO4nDN90A4F599vKcSS3FGoqEWc1FxIgDR7Lx8gwQAAA==
X-Env-Sender: Alexander.Vainshtein@ecitele.com
X-Msg-Ref: server-15.tower-245.messagelabs.com!1578989404!3908!1
X-Originating-IP: [18.237.140.177]
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 10974 invoked from network); 14 Jan 2020 08:10:06 -0000
Received: from p01b.mail.dlp.protect.symantec.com (HELO mail.ds.dlp.protect.symantec.com) (18.237.140.177) by server-15.tower-245.messagelabs.com with ECDHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 14 Jan 2020 08:10:06 -0000
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N5pAv185/Etfqc3heanQVpAACgCRrYXg60rNvjDevAEXnQrZvkYNZjgiFXYZeA2v3XQ+AAyD4FgvhpmwLCo2huvcdCvrqfWyc+UbjUMMFbCMFgkcl5w9AIJs+jCgzhyuaT0tWX2mEG74wOv6oJGpHXAdkk6cDkLujBIPNNm2++kAtxoJfbKJFZNRkfA0KR6eLpCl69W1U6Xvlgi55Bi0q8fUbhBcmDbTmA9Wdneg3VrXEzYtOpTUTGkOQF9nHmFVAEzJ892Kr2jORpZ1ylMEW3Ud1nKoo/o2qmsPySbBgiAgw5rOUtSU93IIqlMD/DTCjA6NIVbht/WNN33UawNH5g==
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=Id0OKnwgNJcFNzSVKix0s2aKdL63jqpq+vFAgb2gNIg=; b=S+nM4dndxXcRpgEaqlXdwxeyzCZjndvuSFgVyOvu8pYpF0hEJDRJIPM9mJ6yTePmr8BJidFkkccSZpteDjnGCwanPmigKhA03zYgcjairBylebv+JBXbW/d7QnpQW9qzBwQQMix1X4UxE4ZAlWuvOCGGDK8Fb0Q5xRci19jEELzNkGJ0AOwEEXmi1XjZ7gjh2BJzLrQ+i9O1JhsOvz5CRi/RYZhbG6rt8pARlzn3R9urIl//uewRGEAI1icRpNZASA5tqsO7STWpMPbsH9cutiFwR2N6erdUZPAOeXO8735no2OGbCsqvFH+CA9kwpBQpjsFNlO6/BIbhP05mnHr8w==
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=Id0OKnwgNJcFNzSVKix0s2aKdL63jqpq+vFAgb2gNIg=; b=LggJUKzRYz1PhbMHk590ut/jRrYkRy0eVlUzPHkqf6f3lYLNTkIwzaBjsALnAtH+AZ/g1Y8nq10h7QMm6moaa13GiupCRENO7WYcPdZ7s+6Ev9dxg89RxEgNJFaLmkVbaANFVNILvkz4f+oMVGHCs5gzOup2VJjLWTzHTQLyPaY=
Received: from DB8PR03MB5865.eurprd03.prod.outlook.com (10.255.16.31) by DB8PR03MB5851.eurprd03.prod.outlook.com (10.255.16.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2623.13; Tue, 14 Jan 2020 08:10:01 +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.2623.017; Tue, 14 Jan 2020 08:10:01 +0000
From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
To: Don Fedyk <dfedyk@labn.net>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>, "'Yemin (Amy)'" <amy.yemin@huawei.com>, "draft-ietf-detnet-data-plane-framework.authors@ietf.org" <draft-ietf-detnet-data-plane-framework.authors@ietf.org>, 'Balázs Varga A' <balazs.a.varga@ericsson.com>, "rtg-ads@ietf.org" <rtg-ads@ietf.org>
Thread-Topic: [RTG-DIR] [Detnet] RTG-DIR last call review of draft-ietf-detnet-data-plane-framework-03
Thread-Index: AdW7xh0d4qjobuHaTbarNnzXAVFyrgJnP5PAAAQ4bPMBO5VlAAAT24ow
Date: Tue, 14 Jan 2020 08:10:01 +0000
Message-ID: <DB8PR03MB5865A4368E492C883544579F9D340@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>
In-Reply-To: <015701d5ca62$538357a0$fa8a06e0$@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: 741cb8be-856d-452d-42c0-08d798c92799
x-ms-traffictypediagnostic: DB8PR03MB5851:
x-microsoft-antispam-prvs: <DB8PR03MB5851832275652F62BC97670E9D340@DB8PR03MB5851.eurprd03.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 028256169F
x-forefront-antispam-report: SFV:NSPM; SFS:(10001)(10019020)(366004)(346002)(376002)(136003)(39860400002)(396003)(199004)(189003)(71200400001)(5660300002)(86362001)(52536014)(8676002)(66574012)(54906003)(316002)(186003)(6916009)(30864003)(478600001)(66556008)(26005)(64756008)(66446008)(66476007)(4326008)(66946007)(7696005)(9686003)(6506007)(53546011)(2906002)(33656002)(81166006)(81156014)(8936002)(76116006)(55016002)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:DB8PR03MB5851; H:DB8PR03MB5865.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: F+DIeJIibjtRg7s0M2ErjgCfAfRlicaMSDCnlqzWMh+YuXAxk8YIQK5m3epXTM9QZX+l0f7tPtHN7Lw9kaeTa7piIafJJ2ZNSRq4q2wZQEbLZDJAGr9u8bqpVItABI2na4YVyb8XJ4MQc/c1U80VSTJ/nYj3V67kb6yaj1eqeG8eBhU8rLNIhd1YY9QGjJh2xiV/PjGJEvThNVt81kQyQHbwatNHewpQSIJmmw6tkeqPCE8FENQv0lNgex4q5qpAzeFhoo7/3shXSjn9/NBiPZSArkkWmEwRajTNkhcDF5IUSNoJX2fPzxEgbZRh5bSvuoy4uSrY1o4HE6bC0lcUmvS8ZLw+1Zt2J/8C+R7+xHGtiJmW32pwQOfDDJzxY5bBtL8AYyJbaP5h5Pmm8lLQ0udIv7Ma94rxSU743DI8eHXT/q2RXNWawazEraQ8rc9e/y3MzEI7Zf3sFrpR7N0MbHESQOvVNPSeXN7AoSCk3WyefaxdZ2EJ2/WZ3RIOBuL73lZ1tL/44H6Shq0v+nAYg+7/RV5+SkEY5Oydh5rHsoKd7D5PIE4a6qKozV2nMbnVRKFT1TnpAzHuUD0xCBlsY3Tpx/3moxUDmFTeuDVpH+SBbq5sADFRcYqmFC8cy2K8+d1vYGqKTp4R9rwrPSaz07S+Uyi1BWx5OkiB5q+zmXI=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ecitele.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 741cb8be-856d-452d-42c0-08d798c92799
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jan 2020 08:10:01.4979 (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: qNYO3BdyfTK2PWe7crOJY+tFsOmBA0V8cyQUVZroGLQVpTYXWYZ4qGjV0IVOrIdxFxHC3KOH7AiBExY5cg9K1w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8PR03MB5851
X-CFilter-Loop: Reflected
X-DetectorID-Processed: d8d3a2b3-1594-4c39-92fb-b8312fe65a8a
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/8iXXNumfgJc3eb_cVe-I9ryq6kI>
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: Tue, 14 Jan 2020 08:10:14 -0000

Don,
Lots of thanks for a very detailed response to my review.

I will read it carefully and provide my feedback, but it will take some time.

Regards, and apologies,
Sasha

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

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

Hi Sasha 

 

Thank you for your thorough review. I have attempted to answer your

comments one by one see[Don] with old/new.  If there are additional changes on your items it might

be good just to break off any item in a separate follow-up. I have included a

full side by side diff so you can examine the changes in place. (hopefully this will make through the mail filters).

If not I can send the complete proposed updated draft text – just let us know.  

 

Cheers

Don

 

From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com <mailto:Alexander.Vainshtein@ecitele.com> >
Sent: Thursday, December 26, 2019 5:30 PM
To: rtg-ads@ietf.org <mailto:rtg-ads@ietf.org>
Cc: rtg-dir@ietf.org <mailto:rtg-dir@ietf.org> ; detnet@ietf.org <mailto:detnet@ietf.org> ; draft-ietf-detnet-data-plane-framework.authors@ietf.org
<mailto:draft-ietf-detnet-data-plane-framework.authors@ietf.org> ; Yemin
(Amy) <amy.yemin@huawei.com <mailto:amy.yemin@huawei.com> >
Subject: RTG-DIR last call review of
draft-ietf-detnet-data-plane-framework-03

 

Hello, 

I have been selected as the Routing Directorate reviewer for this draft.
The Routing Directorate seeks to review all routing or routing-related
drafts as they pass through IETF last call and IESG review, and sometimes on
special request. The purpose of the review is to provide assistance to the
Routing ADs. For more information about the Routing Directorate, please see
<https://clicktime.symantec.com/3HoggwpVJ3tAkafdde3M5kS6H2?u=http%3A%2F%2Ftr
ac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir>
​https://clicktime.symantec.com/3VVqmKSjruaw9PhzaZVyfUd6H2?u=http%3A%2F%2Ftrac.tools.ietf.org%2Farea%2Frtg%2Ftrac%2Fwiki%2FRtgDir 

Although these comments are primarily for the use of the Routing ADs, it
would be helpful if you could consider them along with any other IETF Last
Call comments that you receive, and strive to resolve them through
discussion or by updating the draft. 

Document: draft-ietf-detnet-data-plane-framework-03.txt 
Reviewer: Alexander (“Sasha”) Vainshtein 
Review Date: 26-Dec-19
IETF LC End Date: Not known 
Intended Status: Informational 

Summary: 

I have some minor concerns about this document that I think should be
resolved before publication.

 

Comments:

The draft is one of a group of DetNet documents. 

One of these documents has been already published as RFC 8655
<https://clicktime.symantec.com/3G9XdBmhXdcKZ9XbdXGkvRB6H2?u=https%3A%2F%2Ft
ools.ietf.org%2Fhtml%2Frfc8655> , while several others are in different
stages of the IETF process. 

These documents seem to be closely related, and this makes reading and
understanding the DetNet Data Plane Framework draft complicated (at least
for somebody, like me, who is not deeply immersed in the topic).

Specifically, reading RFC 8655 seems to me a mandatory prerequisite for
understanding the data plane framework draft.

 

I would also like to notice that there are 7 authors listed on the front
page of  the draft. 

I defer to the WG chairs and the ADs to decide whether this is acceptable,
or any changes are required.

 [Don] Two authors are now contributors. 

 

Section 7., paragraph 3:

OLD:

 

8.1.  Normative References

 

NEW:

 

    The following people contributed substantially to the content of this

    document:

 

       Don Fedyk

       Jouni Korhonen

 

I have privately discussed my original comments with the authors prior to
posting this review, and received highly relevant feedback that has helped
me to resolve some of my concerns and to clarify some of the remaining ones.
I also believe that we have reached a rough consensus regarding disposition
of the majority of my comments. I would like to express my gratitude to the
authors of the draft for their  responsiveness and cooperation.

 

Major Issues: No major issues found.

 

Minor Issues: 

1.	As mentioned above, RFC 8655 looks to me a mandatory pre-requisite
for reading and understanding this draft. Therefore I suggest making it a
Normative reference (currently there is just an Informative reference to the
draft that already has been published as RFC 8655). This issue has been
discussed with the authors, and, as I can see it, there were no objections
to such a change.

[Don]Normative Reference. Done

OLD:

 

8.2.  Informative References

 

NEW:

 

    [RFC8655]  Finn, N., Thubert, P., Varga, B., and J. Farkas,

               "Deterministic Networking Architecture", RFC 8655,

               DOI 10.17487/RFC8655, October 2019,

               <https://clicktime.symantec.com/3VEZfYn6w8e4XTFbD3uUbAw6H2?u=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc8655>.

 

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 sub-layer. Resources - buffers for
reordering are at this layer. Updated

 

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.

 

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.

    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.  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 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.

3.	Elimination of replicated packets is yet another important function
of the DetNet data plane that seems to be under-specified. From my POV
ability to perform this function depends on the (worst case of the)
differential delay between the paths taken through the network by the
multiple copies of the packet, but I have not found any discussion of such a
linkage in the draft.

[Don] See above change. And new section.

OLD:

 

3.6.2.2.  Ring Service Protection

 

NEW:

 

3.6.2.2.  Path Differential Delay

 

    In the preceding example, reordering of packets is dependent on the

    number of out-of-order packets that can be buffered and the delay

    difference of arriving packets.  DetNet uses configuration of the

    number of maximum number out-of-order packets and the maximum delay

    that out-of-order packets can be held before being delivered.  If the

    differential delay between paths is large enough or the arrival rate

    of packets large enough packets may be dropped instead of being

    reordered.  Likewise elimination uses the sequence number to

    eliminate duplicate packets and large differential delays combined

    with high numbers of packets may exceed the ability of the

    elimination function to eliminate all duplicate packets.  Network

    engineering of DetNet services needs to take these factors into

    account.

 

 3.6.2.3.  Ring Service Protection

 

4.	The DetNet Data Plane Framework draft mentions in the Introduction
that  TSN as a possible (but not mandatory) underlay for carrying the DetNet
flows, and says that “some of the DetNet benefits can be gained by running
over a data link layer that has not been specifically enhanced to support
TSN”. It would be really nice if the draft would also specify which (if any)
of the DetNet goals could not be achieved if it runs over the data link
layer that has not been enhanced to support TSN. Specifically, I would like
to see:

1.	Whether the DetNet data plane is expected to provide any equivalent
of the frame preemption function defined in IEEE802.1Qbu

[Don] Clarified 

Section 1., paragraph 3:

OLD:

 

    The DetNet Architecture models the DetNet related data plane

    functions decomposed into two sub-layers: a service sub-layer and a

    forwarding sub-layer.  The service sub-layer is used to provide

    DetNet service protection and reordering.  The forwarding sub-layer

    leverages Traffic Engineering mechanisms and provides congestion

    protection (low loss, assured latency, and limited out-of-order

    delivery).

 

NEW:

 

    The DetNet Architecture models the DetNet related data plane

    functions decomposed into two sub-layers: a service sub-layer and a

    forwarding sub-layer.  The service sub-layer is used to provide

    DetNet service protection and reordering.  The forwarding sub-layer

    leverages Traffic Engineering mechanisms and provides congestion

    protection (low loss, assured latency, and limited out-of-order

    delivery).  A particular forwarding sub-layer may have capabilities

    that are not available on other forwarding-sub layers.  DetNet makes

    use of the existing forwarding sub-layers with their respective

    capabilities and does not require 1:1 equivalence between different

    forwarding sub-layer capabilities.

 

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.

    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.  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.     The relevant text
in RFC 8655 only says that all the TSN techniques are currently defined for
Ethernet and Layer 2 bridging, “they are all, except perhaps for packet
preemption, equally applicable to media other than Ethernet and to routers
as well as bridges”

                                                 ii.     Personally I
believe that preemption is closely related to usage of specific media, but
this may be due to my admitted ignorance in these matters

b.	What could be the impact of NOT supporting frame preemption in
DetNet on its goals, especially on jitter?

[Don] Hopefully above text changes cover this.

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.

5.	The term “d-CW” appears several times in the draft without either am
explicit definition or a clear reference to such a definition. 

1.	The definition of d-CW seems to be in Section 4.2.1 of the DetNet
Data Plane: MPLS
<https://clicktime.symantec.com/3saUg5oC3fvZTGYHgpTVTz6H2?u=https%3A%2F%2Fto
ols.ietf.org%2Fhtml%2Fdraft-ietf-detnet-mpls-04>  draft

[Don] Definitions 

    CW            Control Word.

    d-CW          DetNet Control Word.

 

i.	If this is correct, then an explicit reference to this draft should
be added IMHO

[Don] will add reference. 

Section 3.1.2., paragraph 1:

OLD:

 

    DetNet encodes specific flow attributes (flow identity and sequence

    number) in packets.  For example, in DetNet IP, zero encapsulation is

    used and no sequence number is available, and in DetNet MPLS, DetNet

    specific information may be added explicitly to the packets in the

    format of S-label and d-CW.

 

NEW:

 

    DetNet encodes specific flow attributes (flow identity and sequence

    number) in packets.  For example, in DetNet IP, zero encapsulation is

    used and no sequence number is available, and in DetNet MPLS, DetNet

    specific information may be added explicitly to the packets in the

    format of S-label and d-CW [I-D.ietf-detnet-mpls] .

 

Section 3.5., paragraph 3:

OLD:

 

    In cases where metadata is needed to process an MPLS encapsulated

    packet at the service sub-layer, a shim layer called a control word

    (CW) [RFC4385] can be used.  Although such CWs are frequently 32 bits

    long, there is no architectural constraint on its size of this

    structure, only the requirement that it is fully understood by all

    parties operating on it in the DetNet service sub-layer.  The

    operation of this method is described in detail in

    [I-D.ietf-detnet-mpls].

 

NEW:

 

    In cases where metadata is needed to process an MPLS encapsulated

    packet at the service sub-layer, the d-CW [I-D.ietf-detnet-mpls],

    [RFC4385],can be used.  Although such d-CWs are frequently 32 bits

    long, there is no architectural constraint on its size of this

    structure, only the requirement that it is fully understood by all

    parties operating on it in the DetNet service sub-layer.  The

    operation of this method is described in detail in

    [I-D.ietf-detnet-mpls].

 

                                                 ii.     I am not sure if
this would make  the DetNet Data Plane: MPLS draft a Normative reference to
this draft, or it can be left as an Informative reference (as today)

 

[Don] Left as informative.

b.	I find it somewhat surprising that the  term d-CW d is not used in
Section 3.5. “DetNet MPLS Data Plane” of the DetNet Data Plane Framework
draft. Instead, it only mentions “a shim layer called a control word (CW)”
followed by a reference to RFC 4385.  

[Don] See above changes.

7.	In Section 4 the draft describes the DetNet data plane requirements
to the DetNet Controller Plane without providing any explicit definition or
a reference of the latter: 

1.	It seems that the relevant definition appears in Section 4.4.2 of
RFC 8655

[Don]

Section 4.1., paragraph 1:

OLD:

 

    While the definition of controller plane for DetNet is out of the

    scope of this document, there are particular considerations and

    requirements for such that result from the unique characteristics of

    the DetNet architecture [I-D.ietf-detnet-architecture] and data plane

    as defined herein.

 

NEW:

 

    The Controller Plane corresponds to the aggregation of the Control

    and Management Planes discussed in [RFC7426] and [RFC8655].  While

    more details of any DetNet controller plane are out of the scope of

    this document, there are particular considerations and requirements

    for such that result from the unique characteristics of the DetNet

    architecture [RFC8655] and data plane as defined herein.

 

2.	IMHO adding this reference explicitly (or even reproducing it
verbatim) would help the reader to understand why, say, allocation and
distribution of S-labels and F-labels are required from the DetNet
Controller plane in the draft

[Don] added reference. see above.

7.	Section 3.6.1.4 “Network Coding” says that “Network Coding, not to
be confused with network programming, comprises several techniques where
multiple data flows are encoded”. 

1.	No further explanation or reference is provided
2.	I freely admit complete ignorance in all matters dealing with
Network Coding, therefore I did not understand why this section appears in
the draft. 
3.	One of the authors has pointed to the IRTF Coding for efficient
NetWork Communications Research Group (NWCRG)  as the possible source of
information about Network Coding, and this was really helpful to me. I think
that adding at least this pointer (and possibly some others) as Informative
Reference(s) to the draft,  would be helpful  to other readers as well. 

[Don] added reference.  

Section 3.6.1.4., paragraph 1:

OLD:

 

    Network Coding, not to be confused with network programming,

    comprises several techniques where multiple data flows are encoded.

    These resulting flows can then be sent on different paths.  The

    encoding operation can combine flows and error recovery information.

    When the encoded flows are decoded and recombined the original flows

    can be recovered.  Note that Network coding uses an alternative to

    packet by packet PREOF.  Therefore, for certain network topologies

    and traffic loads, Network Coding can be used to improve a network's

    throughput, efficiency, latency, and scalability, as well as

    resilience to partition, attacks, and eavesdropping, as compared to

    traditional methods.  DetNet could utilized Network coding as an

    alternative to other protection means.  Network coding is often

    applied in wireless networks and is being explored for other network

    types.

 

NEW:

 

    Network Coding, [nwcrg] not to be confused with network programming,

    comprises several techniques where multiple data flows are encoded.

    These resulting flows can then be sent on different paths.  The

    encoding operation can combine flows and error recovery information.

    When the encoded flows are decoded and recombined the original flows

    can be recovered.  Note that Network coding uses an alternative to

    packet by packet PREOF.  Therefore, for certain network topologies

    and traffic loads, Network Coding can be used to improve a network's

    throughput, efficiency, latency, and scalability, as well as

    resilience to partition, attacks, and eavesdropping, as compared to

    traditional methods.  DetNet could utilized Network coding as an

    alternative to other protection means.  Network coding is often

    applied in wireless networks and is being explored for other network

    types.

 

Section 7., paragraph 19:

OLD:

 

    [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.

               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1

               Functional Specification", RFC 2205, DOI 10.17487/RFC2205,

               September 1997, <https://clicktime.symantec.com/3XxTcXqWT3hkMHngS4hHBKn6H2?u=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc2205>.

 

NEW:

 

    [nwcrg]    IRTF, "Coding for efficient NetWork Communications

               Research Group (nwcrg)",

               <https://clicktime.symantec.com/37UcmCXykNagWaH6EXciECB6H2?u=https%3A%2F%2Fdatatracker.ietf.org%2Frg%2Fnwcrg%2Fabout>.

 

    [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.

               Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1

               Functional Specification", RFC 2205, DOI 10.17487/RFC2205,

               September 1997, <https://clicktime.symantec.com/3XxTcXqWT3hkMHngS4hHBKn6H2?u=https%3A%2F%2Fwww.rfc-editor.org%2Finfo%2Frfc2205>.

 

 

 

Nits: 

I did not run the nits check on the draft. So I just included two sentences
that looked problematic to me. However, I am not a native English speaker,
so please consider these with a grain of salt.

 

1.	Something seems to be wrong with the grammar in the following
sentence in Section 3.6.1.1: “Misbehaving DetNet flows must be detected and
it have to be ensured that they do not compromise QoS of other flows”

[Don]

Section 3.6.1.1., paragraph 1:

OLD:

 

    Reservation of resources can allocate resources to specific DetNet

    flows.  This can eliminate packet contention and packet loss for

    DetNet traffic.  This also can reduce jitter for DetNet traffic.

    Resources allocated to a DetNet flow protect it from other traffic

    flows.  On the other hand, DetNet flows are assumed to behave with

    respect to the reserved traffic profile.  Misbehaving DetNet flows

    must be detected and it have to be ensured that they do not

    compromise QoS of other flows.  The use of (queuing, policing,

    shaping) policies can be used to ensure that the allocation of

    resources reserved for DetNet is met.

 

NEW:

 

    Reservation of resources can allocate resources to specific DetNet

    flows.  This can eliminate packet contention and packet loss for

    DetNet traffic.  This also can reduce jitter for DetNet traffic.

    Resources allocated to a DetNet flow protect it from other traffic

    flows.  On the other hand, DetNet flows are assumed to behave with

    respect to the reserved traffic profile.  Misbehaving DetNet flows

    must be able to be detected and ensure that they do not compromise

    QoS of other flows.  Queuing, policing, and shaping policies can be

    used to ensure that the allocation of resources reserved for DetNet

    is met.

 

2.	The next sentence in the same section “The use of (queuing,
policing, shaping) policies can be used to ensure that the allocation of
resources reserved for DetNet is met” IMHO should be rephrased e.g., like
“Queuing, policing, and shaping policies can be used to ensure that the
allocation of resources reserved for DetNet is met”. 

[Don] Don Please See above. 

 

 

Hopefully, these notes will be useful. 

 

 

Regards,

Sasha

 

Office: +972-39266302

Cell:      +972-549266302

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

 


___________________________________________________________________________

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.
___________________________________________________________________________

___________________________________________________________________________

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.
___________________________________________________________________________