Re: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Mon, 22 October 2018 12:33 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3CB130E05; Mon, 22 Oct 2018 05:33:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8rlepTIi1UD; Mon, 22 Oct 2018 05:33:16 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A84D1200D7; Mon, 22 Oct 2018 05:33:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5752; q=dns/txt; s=iport; t=1540211596; x=1541421196; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=3wTBVDqDafI4hIDTG4zAezUn7sflhujkt/jXJox4nAQ=; b=RpyqY0GvO+LuY72VTdEXU0rt39sHiiKNVP932bbrJKNJfFg9Di6Ezn8D 97BDcYjNT0z86bOGVvF+GC+cGb0q5kb3DFrcupHgsycO+TUrnaR4vAjOM ImctaAUzCz2jcglD2IaGUKyFmcTSMMY6zC3V7YdXzVMU3iU6//8aOqOqU c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AHAADIws1b/5hdJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVoqZn8oCoNriBiMGoINgz+TVhSBZgsBASOEA0YCF4R9ITQNDQEDAQECAQECbRwMhToBAQEBAyMRRQwEAgEGAhEBAwEBAQICJgICAjAVAgYIAgQBDQUIgxqCAQ+Ic5tNgS6KEAWBC4pHF4FBP4MlfoMbAgGBQAEBBi+CbIJXApQ5ig8JApBoH4FShHOEK4U+jz+GdwIRFIEmHTiBVXAVgyeDOgEHh1eFPm8BiUeBH4EfAQE
X-IronPort-AV: E=Sophos;i="5.54,412,1534809600"; d="scan'208";a="189080825"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Oct 2018 12:33:15 +0000
Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id w9MCXFv5009070 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 22 Oct 2018 12:33:15 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 22 Oct 2018 07:33:14 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1395.000; Mon, 22 Oct 2018 07:33:14 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: János Farkas <janos.farkas@ericsson.com>, "Joel M. Halpern" <jmh@joelhalpern.com>
CC: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-detnet-architecture.all@ietf.org" <draft-ietf-detnet-architecture.all@ietf.org>, DetNet WG <detnet@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Genart last call review of draft-ietf-detnet-architecture-08
Thread-Index: AQHUUg+YYeqIV0gtu0ONxPpT2TRbqaUl8v4AgAF7gICAAAH7AIAADWaAgAPjr/A=
Date: Mon, 22 Oct 2018 12:32:53 +0000
Deferred-Delivery: Mon, 22 Oct 2018 12:32:18 +0000
Message-ID: <7e953a51fcfe44e6b8689c874785caac@XCH-RCD-001.cisco.com>
References: <0cf9f2ac-f813-8f30-9889-4c1e5fc95b7b@ericsson.com> <a773d59b-92e0-8acc-348c-b79b3b6048a6@ericsson.com> <ce26f203-2429-1eaf-4b5e-c81c2b76bed4@joelhalpern.com> <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com>
In-Reply-To: <8ade689d-ceb2-7d21-26af-a20276c596ba@ericsson.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.70.30]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com
X-Outbound-Node: rcdn-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/b6-ACDEzTznGW9SsjsKXenFxc0E>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-detnet-architecture-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Oct 2018 12:33:19 -0000
Hello János I's change reasonably to strictly. The whole point of bounded in detnet is that it is not a vague boundary but a hard, guaranteed one, regardless of any other activity in the network. All the best, Pascal > -----Original Message----- > From: János Farkas <janos.farkas@ericsson.com> > Sent: vendredi 19 octobre 2018 22:06 > To: Joel M. Halpern <jmh@joelhalpern.com> > Cc: gen-art@ietf.org; draft-ietf-detnet-architecture.all@ietf.org; DetNet WG > <detnet@ietf.org>; ietf@ietf.org > Subject: Re: Genart last call review of draft-ietf-detnet-architecture-08 > > Joel, > > Please see in-line. > > > On 10/19/2018 9:17 PM, Joel M. Halpern wrote: > > Thank you Janos. Two clarifications under retained text, with the > > rest elided. > > > > Yours, > > Joel > > > > On 10/19/18 3:10 PM, János Farkas wrote: > > ... > >> On 9/22/2018 2:59 AM, Joel Halpern wrote: > > ... > >>> Minor issues: > >>> Section 3.1 states that worst case delay for priority queueing > >>> is > >>> unbounded. That does not match my understanding. I know that > >>> DelayBound > >>> DSCP behavior tightly (although, I think, not as tightly as > >>> Detnet) limits > >>> both the worst case delay and the delay variation. > >> Strict priority is not good enough for DetNet. A high priority packet > >> may need to wait until the transmission of a lower priority packet is > >> finished at an outbound port, which can cause too much uncertainties > >> in the network. > > > > I understand that strict priority queueing is viewed as insufficient. > > I wasn;t arguing about that. I was arguing with the use of the word > > "unbounded". As far as I can tell, with suitable priority queueing > > the worst case delay is bounded, simply not well enough bounded. > > We can make the sentence clearer: > > OLD: > In general, a trivial priority-based queuing scheme will give better average > latency to a data flow than DetNet, but of course, the worst- case latency can > be essentially unbounded. > > NEW: > In general, a trivial priority-based queuing scheme will give better average > latency to a data flow than DetNet; however, it may be that the worst-case > latency cannot be reasonably bounded for DetNet. > > > > > > ... > >>> In section 4.1.2, I realized that the Detnet Transit node > >>> terminology had > >>> mildly confused me. The text says "DetNet enabled nodes are > >>> interconnected > >>> via transit nodes (e.g., LSRs) which support DetNet, but are > >>> not DetNet > >>> service aware." Reading this, and the definitions in section > >>> 2.1, it > >>> appears that a Detnet Transit node is a node that is providing > >>> transport > >>> behavior that detnet needs, but is not actually modified for > >>> detnet. > >> Based on last call comments: > >> https://www.ietf.org/mail-archive/web/detnet/current/msg01791.html, > >> the phrase "DetNet enabled nodes" is removed from the document and it > >> has been made clear what type of DetNet node is meant: > >> The text is updated to: > >> > >> A "Deterministic Network" will be composed of DetNet enabled end > >> systems, DetNet edge nodes, DetNet relay nodes and collectively > >> deliver DetNet services. DetNet relay and edge nodes are > >> interconnected via DetNet transit nodes (e.g., LSRs) which > >> support > >> DetNet, but are not DetNet service aware. > > > > Any chance you could simply say "transit nodes" instead of "DetNet > > transit nodes? As far as I can tell, they are existing nodes that > > were designed and implemented (and even configured) potentially before > > DetNet was even defined? > > > > ... > It has been pointed out during last call (https://www.ietf.org/mail- > archive/web/detnet/current/msg01791.html), to be specific on what node > type is meant; and be consistent with terminology and definitions. DetNet > transit node is a term defined by this document. > So, it seems better to have DetNet transit node. > > Thank you! > Best regards, > Janos
- [Gen-art] Genart last call review of draft-ietf-d… Joel Halpern
- Re: [Gen-art] Genart last call review of draft-ie… János Farkas
- Re: [Gen-art] Genart last call review of draft-ie… Joel M. Halpern
- Re: [Gen-art] Genart last call review of draft-ie… János Farkas
- Re: [Gen-art] Genart last call review of draft-ie… Pascal Thubert (pthubert)
- Re: [Gen-art] Genart last call review of draft-ie… János Farkas
- Re: [Gen-art] Genart last call review of draft-ie… János Farkas
- Re: [Gen-art] Genart last call review of draft-ie… Joel M. Halpern
- Re: [Gen-art] Genart last call review of draft-ie… Joel M. Halpern
- Re: [Gen-art] [Detnet] Genart last call review of… János Farkas