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