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. ___________________________________________________________________________
- Re: [RTG-DIR] RTG-DIR last call review of draft-i… Alexander Vainshtein
- Re: [RTG-DIR] RTG-DIR last call review of draft-i… Balázs Varga A
- [RTG-DIR] RTG-DIR last call review of draft-ietf-… Alexander Vainshtein
- Re: [RTG-DIR] [Detnet] RTG-DIR last call review o… Don Fedyk
- Re: [RTG-DIR] [Detnet] RTG-DIR last call review o… Alexander Vainshtein
- Re: [RTG-DIR] [Detnet] RTG-DIR last call review o… Alexander Vainshtein
- Re: [RTG-DIR] [Detnet] RTG-DIR last call review o… Don Fedyk
- Re: [RTG-DIR] [Detnet] RTG-DIR last call review o… Alexander Vainshtein
- Re: [RTG-DIR] RTG-DIR last call review of draft-i… Alexander Vainshtein