Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08
János Farkas <janos.farkas@ericsson.com> Wed, 06 February 2019 22:17 UTC
Return-Path: <Janos.Farkas@ericsson.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B2EB130EE9 for <detnet@ietfa.amsl.com>; Wed, 6 Feb 2019 14:17:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.854
X-Spam-Level:
X-Spam-Status: No, score=-8.854 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 4-5R82qgC1w8 for <detnet@ietfa.amsl.com>; Wed, 6 Feb 2019 14:17:41 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 65C8C130E62 for <detnet@ietf.org>; Wed, 6 Feb 2019 14:17:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1549491459; x=1552083459; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0VlZ5DGZynmvw3k7BtIAixYjcXDPKTSiRO17N1Hd67A=; b=DOBNfwIlkzrE4XdrA3DGXn3ckPH2amQHHVR5f4gg2126DrFuS/f3IocugPJ/ovg1 eHcwtkevRVQeBvFPQgYbzx1aDdswq7G1Abk/nTcDt07lWAUXnk1FrNE8HjBYIboM qw+31RSSVCwxbiC87PdUfzRWGWt0Z/DWBEesBtib2uw=;
X-AuditID: c1b4fb2d-db5ff7000000062f-5d-5c5b5d03454e
Received: from ESESSMB503.ericsson.se (Unknown_Domain [153.88.183.121]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 16.66.01583.30D5B5C5; Wed, 6 Feb 2019 23:17:39 +0100 (CET)
Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMB503.ericsson.se (153.88.183.164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 6 Feb 2019 23:17:39 +0100
Received: from [100.94.32.17] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.193) with Microsoft SMTP Server id 15.1.1466.3 via Frontend Transport; Wed, 6 Feb 2019 23:17:39 +0100
To: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
CC: "tsv-art@ietf.org" <tsv-art@ietf.org>, "detnet@ietf.org" <detnet@ietf.org>
References: <153817345967.27205.135001179751151278@ietfa.amsl.com> <fdf872d6-08a6-2c33-de21-9dd1506c1d21@labn.net> <6EC6417807D9754DA64F3087E2E2E03E2D16A4D3@rznt8114.rznt.rzdir.fht-esslingen.de> <e38ab4d6-0924-ab60-b1dc-4ac26600044c@labn.net> <6EC6417807D9754DA64F3087E2E2E03E2D16C02A@rznt8114.rznt.rzdir.fht-esslingen.de> <505e7a95-05bd-5dcb-628f-460790fc1b12@labn.net> <3DF0466E9510274382F5B74499ACD6F80171FFF5@lhrpml504-mbx.exmail.huawei.com> <6EC6417807D9754DA64F3087E2E2E03E2D17715F@rznt8114.rznt.rzdir.fht-esslingen.de>
From: János Farkas <janos.farkas@ericsson.com>
Message-ID: <d5c8a2fa-2e56-3888-3ac3-9cb5cc2a7c6d@ericsson.com>
Date: Wed, 06 Feb 2019 23:17:38 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <6EC6417807D9754DA64F3087E2E2E03E2D17715F@rznt8114.rznt.rzdir.fht-esslingen.de>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLLMWRmVeSWpSXmKPExsUyM2J7pS5zbHSMweH5Wha/P81msdi3uJnd YtaeRSwOzB5Nr/6xeixZ8pMpgCmKyyYlNSezLLVI3y6BK+Pj52NMBfecK6a/WsjawLjJvIuR g0NCwETiyav6LkYuDiGBI4wSH1YeYINwvjJKzF47Dco5xCix/NoVli5GTg5hgTiJxtntbCDd IgJmEssWGoGEmQX8JL5Oe8gIUT+bRaL3wwZ2kASbgL3E3UsbmEHqeYHsybsCQMIsAioSTyct YQOxRQViJT5dWcwMYvMKCEqcnPkEbBWnQIxE67wXTBDzLSRmzj/PCGHLS2x/O4cZwhaXuPVk PliNkICaxKe3D9knMArNQjJqFpL2WUjaZyFpX8DIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1 ZBMjMNAPbvmtu4Nx9WvHQ4wCHIxKPLwK0dExQqyJZcWVucDA4WBWEuF9+ywqRog3JbGyKrUo P76oNCe1+BCjNAeLkjjvHyHBGCGB9MSS1OzU1ILUIpgsEwenVAOjz6F/e522XF6zeuvUy8Wf xXwcs6bP+NxVdXjDpzdWWUYn/z7Wy9bWSdrUuH/TzQemX0tY3T0+vZi1+tGZruNGRs3xRexz E/+LHO55LqtVs/XPjf/qrk7z/1rbv3jxoPyi0ckZJ055mapvZtgQu/BVfXPkhnWeE/aoZmxU Y1iuJzFB5fKuWsuDxkosxRmJhlrMRcWJAKBkOzhwAgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/_q7q8aYW8086UdlKbfw29g8p9mI>
Subject: Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf-detnet-architecture-08
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Feb 2019 22:17:43 -0000
Hi Michael, Thank you very much again for your review! The draft had multiple updates since v08 you reviewed. The latest revision is v 11: https://mailarchive.ietf.org/arch/msg/detnet/SP63CCzi4C2Biy9mk0Qxrehoa_0 The updates address review comments, and comments and discussions on the DetNet WG list. Please let us know if you have further comments. Regards, Janos On 11/28/2018 8:02 AM, Scharf, Michael wrote: > Just to repeat: I won't mandate text on this specific issue. > > But there could be an implicit assumption that PREOF compute resources in the node fast path will _always_ be available. And it is entirely unclear to me if that would be a realistic assumption if the router fast path has to do complex coding on each packet, e.g. for "network coding" as explicitly mentioned in the architecture document. There could be tradeoffs on power, cost, etc. when doing such complex PREOF coding functions for every single packet. And it could be more complex than existing MPLS protection and restoration schemes. > > So, one could e.g. wonder if a DetNet network could run into the situation that a DetNet node as enough bandwidth and buffer, but not enough "network coding" coding/decoding capacity, or if a DetNet node would have to announce that it can do, say, 1+1 protection with PREOF, but there are not enough transcoder resources left for doing PREOF "network coding". Then there could be architectural implications, e.g., on protocols. > > Assuming that "implementers will do the right thing" would be reasonable if per-packet coding/decoding actions in PREOF are always cheap. Otherwise, one may have to consider transcoders as a potentially scarce resource that could also impact flow placement decisions - maybe somewhat similar to wavelength converters in optical networks. > > I don't know how to implement "network coding" in the fast path of a router that runs at Tbit/s. If running code has already shown that doing "network coding" at the line speed of today's routers is easily doable, this specific point may not be relevant. Clearly I am not an expert for router fast path designs. > > Michael > > >> -----Original Message----- >> From: Norman Finn [mailto:norman.finn@mail01.huawei.com] >> Sent: Tuesday, November 27, 2018 11:32 PM >> To: Lou Berger; Scharf, Michael >> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet- >> architecture.all@ietf.org >> Subject: RE: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf- >> detnet-architecture-08 >> >> Typically, the resources for DetNet flows are reserved before the flow >> starts. In the case of PREOF, the functions are at least configured >> before being used. I would think that, if insufficient capability >> exists, the reservation/configuration would be refused. We're talking >> an awful lot of 9s here, to justify this feature, so doing otherwise >> would be a poor implementation choice. Do we need to say something >> about that, or figure that implementors will do the right thing? >> >> -- Norm >> >> ________________________________________ >> From: detnet [detnet-bounces@ietf.org] on behalf of Lou Berger >> [lberger@labn.net] >> Sent: Tuesday, November 20, 2018 10:07 AM >> To: Scharf, Michael >> Cc: tsv-art@ietf.org; detnet@ietf.org; draft-ietf-detnet- >> architecture.all@ietf.org >> Subject: Re: [Detnet] [Tsv-art] Tsvart last call review of draft-ietf- >> detnet-architecture-08 >> >> Michael, >> >> Thanks for the clarification. >> >> On 11/20/2018 10:02 AM, Scharf, Michael wrote: >>> Lou, >>> >>> Just regarding my comment that seems unclear... >>> >>> [snip] >>> >>>>> In addition, I'd like to emphasize that my review comment "It is >> surprising that there is hardly any discussion on network robustness >> and safety" >>>> I have no idea what you mean by safety here. Can you elaborate. >>> As far as I understand, DetNet introduces network functions that at >> least partly novel, such as PREOF. And as PREOF explicitly allows >> solutions beyond 1+1 protection ("network coding" is mentioned as >> example). >> >> at the network layer, protection and restoration is not new. There is >> LFAs. FRR, 1+1, 1:n, shared mesh etc all defined in RFCs - mostly, but >> not solely for MPLS. It's also not new transport protocol layer either >> as there is work (have to check if RFCs) on network coding and 1+1 -- >> but this is outside the scope of Detnet. >> >> >>> I believe that any new function typically raises operational issues. >>> >>> Out-of-my-head, here are some examples of potential challenges that >> seem not well addressed in -09: >>> - PREOF (and specifically) PEF as a single point of failure: Is there >> any need to worry about that? As far as I can see, the document >> discusses failures of paths between POF and PEF, but not failures of >> the functions themselves. Wouldn't it make sense to discuss basic >> requirements such as implementing these functions redundantly etc.? And >> if they are implemented redundantly, does this impact the architecture, >> e.g., result in additional interfaces that may need standardization? >> >> No more so than exists in the current RFCs related to the topic. >> >>> - Overload of DetNet components: As another example for PREOF, how >> would a DetNet deployment ensure that PEF never gets overloaded? >> >> Umm, how does an RFC ever dictate that a router/node/host isn't >> overloaded? In the normal internet case, I think this is way outside >> the scope of an RFC. For TE networks, this is what >> configuration/management/control is all about - and sure we can add a >> sentence on that. >> >> >>> Buffering and resequencing of packets requires processing. Techniques >> to allocate buffer space alone may not be enough to ensure that PEF >> never gets overloaded. Is this a problem or not? And even if this >> problem may perhaps not really exist for 1+1, is there no need to worry >> about other, possibly more complex PREOF schemes that may require >> complex packet processing (or even coding)? Are there scaling issues in >> PREOF? And could this impact signaling, e.g., require control plane >> protocol extensions? >> >> yes, there is configuration/management/control-- this can be mentioned. >> >> >>> More generally, if the intention of DetNet is to carry mission- >> critical or safety-critical traffic that cannot tolerate any packet >> loss, let alone any downtime, wouldn't words such as "reliability", >> "dependability", "redundancy", "high availability", etc. be relevant in >> a description of the architecture? (Some of these terms are actually >> used in this document, mostly in references to non-IETF work.) >> >> The IETF generally just defines the behavior on the wire in standards >> track RFCs and let others define requirement system performance levels. >> I don't think we should be changing this in DetNet. >> >> >>> And this may not only matter for the data plane. Assuming that a lot >> of DetNet traffic requires extremely high reliability, are there >> architectural requirements on components outside the data plane, e.g., >> regarding redundancy? Obviously, control plane and management plane >> functions are often built today already as high availability solutions, >> but if the intention is to _never_ fail, isn't there a risk that DetNet >> may require solutions "better-than-current-IP" outside the data plane >> as well? >> >> There are plenty of high availability (and different level of >> availability) implementations of systems out there. The only think the >> IETF gets involved with specifying are those aspects that impact >> interoperability between systems. (E.g., all the graceful restart >> related extensions in control plane protocols). Again, I don't think >> it's for DetNet to move beyond this. >> >> >>> This list of topics may not be comprehensive. I just want to >> illustrate some examples for what could also matter when running a >> network _really_ deterministically, beyond the well-known congestion >> issue. >>> However, just to be precise: I don't ask for additional text to >> address what is written in this e-mail. >> >> Thanks - it sounds like we're ending at the same place even if we >> didn't >> follow the same path to get here. >> >> Thanks again for comments/review. I do think we'll have a better >> document once the other points are addressed. >> >> Lou >> >>> Michael >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet
- [Detnet] Tsvart last call review of draft-ietf-de… Michael Scharf
- Re: [Detnet] Tsvart last call review of draft-iet… János Farkas
- Re: [Detnet] Tsvart last call review of draft-iet… Scharf, Michael
- Re: [Detnet] Tsvart last call review of draft-iet… Black, David
- Re: [Detnet] Tsvart last call review of draft-iet… Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Black, David
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Black, David
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Toerless Eckert
- [Detnet] Fwd: Re: Tsvart last call review of draf… János Farkas
- Re: [Detnet] Fwd: Re: Tsvart last call review of … Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Toerless Eckert
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Toerless Eckert
- Re: [Detnet] Tsvart last call review of draft-iet… Lou Berger
- Re: [Detnet] Tsvart last call review of draft-iet… Scharf, Michael
- Re: [Detnet] Tsvart last call review of draft-iet… Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Black, David
- Re: [Detnet] Tsvart last call review of draft-iet… Pascal Thubert (pthubert)
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Pascal Thubert (pthubert)
- Re: [Detnet] Transport sub-layer name change (Was… Grossman, Ethan A.
- [Detnet] Transport sub-layer name change (Was Re:… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Toerless Eckert
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Mach Chen
- Re: [Detnet] Transport sub-layer name change (Was… Pascal Thubert (pthubert)
- Re: [Detnet] Transport sub-layer name change (Was… Loa Andersson
- Re: [Detnet] Transport sub-layer name change (Was… Toerless Eckert
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Toerless Eckert
- Re: [Detnet] Transport sub-layer name change (Was… Norman Finn
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Norman Finn
- Re: [Detnet] [Tsv-art] Tsvart last call review of… Scharf, Michael
- Re: [Detnet] Transport sub-layer name change (Was… János Farkas
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- Re: [Detnet] Transport sub-layer name change (Was… Greg Mirsky
- Re: [Detnet] Transport sub-layer name change (Was… Loa Andersson
- Re: [Detnet] Transport sub-layer name change (Was… S.V.R.Anand
- Re: [Detnet] Transport sub-layer name change (Was… Pascal Thubert (pthubert)
- Re: [Detnet] Transport sub-layer name change (Was… qiangli (D)
- Re: [Detnet] Transport sub-layer name change (Was… Balázs Varga A
- Re: [Detnet] Transport sub-layer name change (Was… Loa Andersson
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- [Detnet] Congestion Protection name change (was: … János Farkas
- Re: [Detnet] Congestion Protection name change (w… Pascal Thubert (pthubert)
- Re: [Detnet] Congestion Protection name change (w… Andrew G. Malis
- Re: [Detnet] Congestion Protection name change (w… Lou Berger
- Re: [Detnet] Congestion Protection name change János Farkas
- Re: [Detnet] Congestion Protection name change Black, David
- Re: [Detnet] Congestion Protection name change Pascal Thubert (pthubert)
- Re: [Detnet] Congestion Protection name change (w… qiangli (D)
- Re: [Detnet] Congestion Protection name change qiangli (D)
- Re: [Detnet] Congestion Protection name change Balázs Varga A
- Re: [Detnet] Congestion Protection name change Lou Berger
- Re: [Detnet] Congestion Protection name change Lou Berger
- Re: [Detnet] Congestion Protection name change Pascal Thubert (pthubert)
- Re: [Detnet] Congestion Protection name change Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Stewart Bryant
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- Re: [Detnet] Congestion Protection name change Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- Re: [Detnet] Congestion Protection name change Andrew G. Malis
- Re: [Detnet] Congestion Protection name change John E Drake
- Re: [Detnet] Transport sub-layer name change (Was… Andrew G. Malis
- Re: [Detnet] Transport sub-layer name change (Was… Lou Berger
- Re: [Detnet] [Tsv-art] Tsvart last call review of… János Farkas