Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06
Lou Berger <lberger@labn.net> Fri, 13 July 2018 20:11 UTC
Return-Path: <lberger@labn.net>
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 38AC3130F40 for <detnet@ietfa.amsl.com>; Fri, 13 Jul 2018 13:11:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 Lh42M14reuRb for <detnet@ietfa.amsl.com>; Fri, 13 Jul 2018 13:11:39 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 0F453130E8A for <detnet@ietf.org>; Fri, 13 Jul 2018 13:11:39 -0700 (PDT)
Received: from cmgw15.unifiedlayer.com (unknown [10.9.0.15]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id EDE0421738C for <detnet@ietf.org>; Fri, 13 Jul 2018 13:53:07 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id e47nf2iMqj0soe47nfiHXI; Fri, 13 Jul 2018 13:53:07 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=D5Foh1L+BLXD7hRafSSTO4WJqnIY0gse/fxT/NanDkg=; b=v9287Cpzs5ISvmg3vnrj2Z2kZQ jZcCD+yH13mbAAzkZEy8aCP7s5oe0d5iPX6pYHsDnqmPA5SLSdg29ejgZRTkHt04fSkJ4jIyNidQp THqCF8xbOCjxJPTZW+54ZwSc+;
Received: from [172.58.185.214] (port=59822 helo=[IPV6:2607:fb90:6458:6872:0:45:9575:8401]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1fe47l-003D51-4t; Fri, 13 Jul 2018 13:53:07 -0600
From: Lou Berger <lberger@labn.net>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, "Andrew G. Malis" <agmalis@gmail.com>, "Pascal Thubert (pthubert)" <pthubert=40cisco.com@dmarc.ietf.org>
CC: draft-ietf-detnet-architecture@ietf.org, Norman Finn <norman.finn@mail01.huawei.com>, DetNet WG <detnet@ietf.org>
Date: Fri, 13 Jul 2018 15:53:02 -0400
Message-ID: <16495342d30.282b.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <bb399622f7694c1fbb00c2d2a6dedd46@XCH-RCD-001.cisco.com>
References: <99657d22-f9e4-8a1a-27de-6997900f727e@labn.net> <7cc44e35-cbd0-fbdb-95b7-c93ab38ec5d7@gmail.com> <AM3PR07MB4021D464E3E2C4CCAA0883EAC7F0@AM3PR07MB402.eurprd07.prod.outlook.com> <fee5178f-a1da-53e7-1684-e09ec2bfcb42@gmail.com> <ab532cc6-0552-ecb1-fe3f-09ebce5f6ba9@ericsson.com> <30d8df73-9f52-89d3-66fd-2173f7038624@labn.net> <a19cb7bb-a518-acfd-4539-d002bfc58bca@labn.net> <3DF0466E9510274382F5B74499ACD6F8D31E2D@dfwpml705-chm.exmail.huawei.com> <6D76E3A0-CA07-4EE5-8157-AC604F3CB796@cisco.com> <bdf4d1ec-11be-9071-b94a-f6719f2fd397@labn.net> <3F7B52F1-ECCB-4789-B8FF-A171B4FE58F6@cisco.com> <B50E7F65-5892-4071-8636-7A00F059E636@cisco.com> <CAA=duU1Z-4LhZX0Vb3mc9fo53y7YiOr+bSdmmPe3SidzeoQLTQ@mail.gmail.com> <bb399622f7694c1fbb00c2d2a6dedd46@XCH-RCD-001.cisco.com>
User-Agent: AquaMail/1.15.0-916 (build: 101500003)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------16495342fb15106282b62703d8"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 172.58.185.214
X-Source-L: No
X-Exim-ID: 1fe47l-003D51-4t
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: ([IPV6:2607:fb90:6458:6872:0:45:9575:8401]) [172.58.185.214]:59822
X-Source-Auth: lberger@labn.net
X-Email-Count: 5
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/hTA04ZX2dMK3Ffm2AIfHIvg-Z7M>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 13 Jul 2018 20:11:43 -0000
I think CP entity is a better representation of the architecture being agnostic of the control plane being fully centralized, fully distributed, or any hybrid of the two. Saying that control is limited to a single controller and to a pce implementation is certainly overly limiting in my opinion... Lou ---------- On July 13, 2018 3:16:39 PM "Pascal Thubert (pthubert)" <pthubert@cisco.com> wrote: > Oups, you’re right Andy, > > it was just added in 06 in replacement to “controller”, and I missed that > when I browsed the diffs. > > Well, wasn’t “controller” good enough? Note also that the replacement was > only partial, and “controller” is still there in many places. > > Also, we need to define what we mean by that “controller”, whatever we call it. > > At the time of that writing, I viewed the controller as a composite of > separate entities, as illustrated below: > > [cid:image003.png@01D41ABB.C711DC30] > Does that make sense? > > Cheers, > > pascla > > From: Andrew G. Malis <agmalis@gmail.com> > Sent: vendredi 13 juillet 2018 13:54 > To: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org> > Cc: Lou Berger <lberger@labn.net>; draft-ietf-detnet-architecture@ietf.org; > Norman Finn <norman.finn@mail01.huawei.com>; DetNet WG <detnet@ietf.org> > Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06 > > Pascal, > > CPE is in sections 4.4.2 and 4.4.3 of revision 06. There are 8 occurrences > total. > > Cheers, > Andy > > > On Fri, Jul 13, 2018 at 1:48 PM, Pascal Thubert (pthubert) > <pthubert=40cisco.com@dmarc.ietf.org<mailto:pthubert=40cisco.com@dmarc.ietf.org>> > wrote: > Hello Deborah > > The architecture as published does not have a CPE. > > This was introduced in this thread and never needs to see the light. > > The original text had PCE because conceptually this is the IETF base for > that entity, even if we’ll need to evolve it, and that there are other > entities we'll need for management and automation. > > I’m still unclear When CPE came up ? > I saw it first in Lou’s proposal. Was that voluntary or a typo ? > > > Regards, > > Pascal > >> Le 13 juil. 2018 à 13:44, Pascal Thubert (pthubert) >> <pthubert@cisco.com<mailto:pthubert@cisco.com>> a écrit : >> >> Works for me, Lou, >> >> I think that the best would be a terminology that would define this >> operational plane, leaving it open to network control and feedback, and >> then change in situ the text as you proposed. >> >> >> Regards, >> >> Pascal >> >>> Le 13 juil. 2018 à 06:29, Lou Berger >>> <lberger@labn.net<mailto:lberger@labn.net>> a écrit : >>> >>> Pascal, >>> >>> Keeping in mind that LMI is generally considered a form of OAM, it sounds >>> like changing it to "Operational Plane (e.g., OAM)" would sufficiently >>> cover your intent and be a fairly trivial change to the document. Would >>> this change work for you? >>> >>> Lou >>> >>>> On 7/13/2018 12:19 AM, Pascal Thubert (pthubert) wrote: >>>> Hello Lou and Norm: >>>> >>>> I meant control protocols over the LMI as well as measurement (OAM) and >>>> automation such as (reflex) reactions that do no pass via a controller. >>>> >>>> The LMI provides information on the status of a DetNet path which can act >>>> as go/nogo for data and trigger fallback. It may in the future enable flow >>>> setup if one day we go for a more distributed design. It may provide time >>>> though for DetNet it is not in scope. It may provide rate control as well >>>> which is the object of a draft I have to split. >>>> >>>> So operation there was meant as a generic term for train data traffic >>>> overhead inside the network as opposed to in relation with a controller. >>>> >>>> Should we expand to clarify? >>>> >>>> Regards, >>>> >>>> Pascal >>>> >>>>> Le 13 juil. 2018 à 00:04, Norman Finn >>>>> <norman.finn@mail01.huawei.com<mailto:norman.finn@mail01.huawei.com>> a écrit : >>>>> >>>>> Pascal wrote that chunk. I always assumed that "Operational Plane (control >>>>> plane)" was some sort of IETF phrase I just didn't understand. If it's >>>>> OAM, I don't see what the "(control plane)" is for. >>>>> >>>>> Pascal? >>>>> >>>>> -- Norm >>>>> ________________________________________ >>>>> From: detnet [detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>] on >>>>> behalf of Lou Berger [lberger@labn.net<mailto:lberger@labn.net>] >>>>> Sent: Thursday, July 12, 2018 9:47 AM >>>>> To: >>>>> draft-ietf-detnet-architecture@ietf.org<mailto:draft-ietf-detnet-architecture@ietf.org> >>>>> Cc: DetNet WG >>>>> Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06 >>>>> >>>>> Hi, >>>>> >>>>> I have the following comments/questions: >>>>> >>>>> - WRT 4.4.2 >>>>> >>>>> I think CPE and PCE are a bit conflated. To clarify, hiw about: >>>>> >>>>> OLD >>>>> to any device operating in that plane, whether is it a Path >>>>> Computation entity, or a Network Management entity (NME)), or a >>>>> distributed control plane. The Path Computation Element (PCE) >>>>> [RFC4655] is a core element of a controller, in charge of computing >>>>> Deterministic paths to be applied in the Network Plane. >>>>> >>>>> NEW >>>>> to any device operating in that plane, whether is it a Path >>>>> Computation Element [RFC4655] or entity, or a Network Management >>>>> entity (NME)), or a >>>>> distributed control plane. The CPE >>>>> is a core element of a controller, in charge of computing >>>>> Deterministic paths to be applied in the Network Plane. >>>>> >>>>> and s/PCE/CPE in the next paragraph, specifically: >>>>> >>>>> OLD >>>>> One or more PCE(s) collaborate to implement the requests from the FME >>>>> as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for >>>>> each individual flow. The PCEs place each flow along a deterministic >>>>> NEW >>>>> One or more CPE(s) collaborate to implement the requests from the FME >>>>> as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for >>>>> each individual flow. The CPEs place each flow along a deterministic >>>>> >>>>> - WRT Section 4.4.3 >>>>> I'm unclear as to what "Operational Plane (control plane)" means in the >>>>> first paragraph. Should it perhaps read "Operational Plane (OAM)"? If >>>>> not, what is the intent of "control plane" in this paragraph (and section)? >>>>> >>>>> Thank you, >>>>> Lou >>>>> >>>>>> On 6/28/2018 10:35 PM, Lou Berger wrote: >>>>>> Authors, >>>>>> >>>>>> Thank you for the update! >>>>>> >>>>>> WG, >>>>>> >>>>>> This document has changed to a sufficient degree that I think a 2nd >>>>>> last call is warranted. Typically I would start a 1 week LC in these >>>>>> circumstances - but given the proximity to the meeting I'd like to start >>>>>> a 3 week LC right ending with the IETF meeting -- that is on July 20th. >>>>>> This should allow for both adequate review of the changes and discussion >>>>>> of the changes in our WG session (Monday July 16.) >>>>>> >>>>>> As always, please send LC comment to the list and positive comments, >>>>>> e.g., "I've reviewed this document >>>>>> and believe it is ready for publication", are welcome! >>>>>> >>>>>> Thank you, >>>>>> >>>>>> Lou (as Shepherd) >>>>>> >>>>>>> On 6/28/2018 9:08 PM, János Farkas wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> Off-line discussions among Lou, Stewart, and authors followed the >>>>>>> discussions to properly address the WGLC comments, including the >>>>>>> detailed comments. >>>>>>> >>>>>>> A new revision of the draft has been uploaded: >>>>>>> draft-ietf-detnet-architecture-06. >>>>>>> >>>>>>> In addition to the changes already described in this thread, the >>>>>>> following bigger changes have been made to the draft: >>>>>>> >>>>>>> >>>>>>> *Section 2.1 Terms used in this document* >>>>>>> >>>>>>> Some definitions refined as suggested by the detailed comments >>>>>>> >>>>>>> New definitions have been added: >>>>>>> >>>>>>> "allocation >>>>>>> Resources are dedicated to support a DetNet flow. Depending >>>>>>> on an implementation, the resource may be reused by non- >>>>>>> DetNet flows when it is not used by the DetNet flow. >>>>>>> >>>>>>> >>>>>>> PEF A Packet Elimination Function (PEF) eliminates duplicate >>>>>>> copies of packets to prevent excess packets flooding the >>>>>>> network or duplicate packets being sent out of the DetNet >>>>>>> domain. PEF can be implemented by an edge node, a relay >>>>>>> node, or an end system. >>>>>>> >>>>>>> PRF A Packet Replication Function (PRF) replicates DetNet flow >>>>>>> packets and forwards them to one or more next hops in the >>>>>>> DetNet domain. The number of packet copies sent to each next >>>>>>> hop is a DetNet flow specific parameter at the node doing the >>>>>>> replication. PRF can be implemented by an edge node, a relay >>>>>>> node, or an end system. >>>>>>> >>>>>>> PREOF Collective name for Packet Replication, Elimination, and >>>>>>> Ordering Functions. >>>>>>> >>>>>>> POF A Packet Ordering Function (POF) re-orders packets within a >>>>>>> DetNet flow that are received out of order. This function >>>>>>> can be implemented by an edge node, a relay node, or an end >>>>>>> system. >>>>>>> >>>>>>> DetNet service proxy >>>>>>> Maps between App-flows and DetNet flows. >>>>>>> >>>>>>> bridged path >>>>>>> A VLAN bridge uses the VLAN ID and the destination MAC >>>>>>> address to select the outbound port hence the path for a >>>>>>> frame." >>>>>>> >>>>>>> >>>>>>> *Section 3.1 Primary goals defining the DetNet QoS* >>>>>>> >>>>>>> A new QoS aspect has been added: >>>>>>> "o An upper bound on out-of-order packet delivery. It is worth >>>>>>> noting that some DetNet applications are unable to tolerate any >>>>>>> out-of-order delivery." >>>>>>> >>>>>>> >>>>>>> The 3rd paragraph on loss on page 8 after the bullet list has been >>>>>>> extended to: >>>>>>> "After congestion, the most important contributions to packet loss are >>>>>>> typically from random media errors and equipment failures. Service >>>>>>> protection is the name for the mechanisms used by DetNet to address >>>>>>> these losses. The mechanisms employed are constrained by the >>>>>>> requirement to meet the users' latency requirements. Packet >>>>>>> replication and elimination (Section 3.2.2) and packet encoding >>>>>>> (Section 3.2.2.3) are described in this document to provide service >>>>>>> protection; others may be found. For instance, packet encoding can >>>>>>> be used to provide service protection against random media errors, >>>>>>> packet replication and elimination can be used to provide service >>>>>>> protection against equipment failures. This mechanism distributes >>>>>>> the contents of DetNet flows over multiple paths in time and/or >>>>>>> space, so that the loss of some of the paths does need not cause the >>>>>>> loss of any packets." >>>>>>> >>>>>>> >>>>>>> *3.2.2. Service Protection* >>>>>>> >>>>>>> Service protection is used as a more generic term. Introductory text >>>>>>> added: >>>>>>> "Service protection aims to mitigate or eliminate packet loss due to >>>>>>> equipment failures, random media and/or memory faults. These types >>>>>>> of packet loss can be greatly reduced by spreading the data over >>>>>>> multiple disjoint forwarding paths. Various service protection >>>>>>> methods are described in [RFC6372], e.g., 1+1 linear protection. >>>>>>> This section describes the functional details of an additional method >>>>>>> in Section 3.2.2.2, which can be implemented as described in >>>>>>> Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls] in >>>>>>> order to provide 1+n hitless protection. The appropriate service >>>>>>> protection mechanism depends on the scenario and the requirements." >>>>>>> >>>>>>> >>>>>>> New sub-section added: >>>>>>> >>>>>>> "3.2.2.1. In-Order Delivery >>>>>>> >>>>>>> Out-of-order packet delivery can be a side effect of service >>>>>>> protection. Packets delivered out-of-order impact the amount of >>>>>>> buffering needed at the destination to properly process the received >>>>>>> data. Such packets also influence the jitter of a flow. The DetNet >>>>>>> service includes maximum allowed misordering as a constraint. Zero >>>>>>> misordering would be a valid service constraint to reflect that the >>>>>>> end system(s) of the flow cannot tolerate any out-of-order delivery. >>>>>>> Service protection may provide a mechanism to support in-order >>>>>>> delivery." >>>>>>> >>>>>>> >>>>>>> *3.2.2.2. Packet Replication and Elimination* >>>>>>> >>>>>>> New bullet added as the last one: >>>>>>> "o The Packet Ordering Function (POF) uses the sequencing information >>>>>>> to re-order a DetNet flow's packets that are received out of >>>>>>> order." >>>>>>> >>>>>>> New sentence added after the bullet list: >>>>>>> "The order in which a node applies the PEF and the PRF to a DetNet >>>>>>> flow is implementation specific." >>>>>>> >>>>>>> 2nd paragraph after the bullet list has been updated to: >>>>>>> "Some service protection mechanisms rely on switching from one flow to >>>>>>> another when a failure of a flow is detected. Contrarily, packet >>>>>>> replication and elimination combines the DetNet member flows sent >>>>>>> along multiple different paths, and performs a packet-by-packet >>>>>>> selection of which to discard, e.g., based on sequencing information." >>>>>>> >>>>>>> >>>>>>> *3.2.3. Explicit routes* >>>>>>> >>>>>>> Out-of-order aspect added to the first paragraph, which is about >>>>>>> distributed routing: >>>>>>> "Furthermore, out-of-order >>>>>>> packet delivery can be a side effect of route changes." >>>>>>> >>>>>>> New sentence added to the 3rd paragraph: >>>>>>> "Explicit routes can be established various >>>>>>> ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) >>>>>>> [I-D.ietf-spring-segment-routing], via a Software Defined Networking >>>>>>> approach [RFC7426], with IS-IS [RFC7813], etc." >>>>>>> >>>>>>> New paragraph added: >>>>>>> "Out-of-order packet delivery can be a side effect of distributing a >>>>>>> single flow over multiple paths especially when there is a change >>>>>>> from one path to another when combining the flow. This is >>>>>>> irrespective of the distribution method used, also applies to service >>>>>>> protection over explicit routes. As described in Section 3.2.2.1, >>>>>>> out-of-order packets influence the jitter of a flow and impact the >>>>>>> amount of buffering needed to process the data; therefore, DetNet >>>>>>> service includes maximum allowed misordering as a constraint. The >>>>>>> use of explicit routes helps to provide in-order delivery because >>>>>>> there is no immediate route change with the network topology, but the >>>>>>> changes are plannable as they are between the different explicit >>>>>>> routes." >>>>>>> >>>>>>> * >>>>>>> **4.1.1. Representative Protocol Stack Model* >>>>>>> >>>>>>> "Explicit routes" have been added to Figure 2 with the corresponding >>>>>>> explanation: >>>>>>> "Explicit routes >>>>>>> The DetNet transport layer provides mechanisms to ensure that >>>>>>> fixed paths are provided for DetNet flows. These explicit >>>>>>> paths avoid the impact of network convergence." >>>>>>> >>>>>>> >>>>>>> Section 4.11 Connected islands vs. networks of v05 has been deleted >>>>>>> because it was just a leftover from early drafts on what DetNet WG >>>>>>> should do; which are covered by the charter anyways. >>>>>>> >>>>>>> >>>>>>> References have been cleaned up and brought up-to-date. >>>>>>> >>>>>>> >>>>>>> Refinements have been implemented in the draft according to Lou's >>>>>>> detailed comments. They are not listed here because they are minor >>>>>>> changes. >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Janos >>>>>>> >>>>>>> >>>>>>>> On 6/12/2018 2:48 PM, Lou Berger wrote: >>>>>>>> Balázs, >>>>>>>> >>>>>>>> Thanks for the response -- please see below. >>>>>>>> >>>>>>>> ---------- >>>>>>>> On June 12, 2018 4:07:35 AM Balázs Varga A >>>>>>>> <balazs.a.varga@ericsson.com<mailto:balazs.a.varga@ericsson.com>> wrote: >>>>>>>> >>>>>>>>> Hi Lou, Thanks for the comments. See reactions inline. Document >>>>>>>>> update in progress. Cheers Bala'zs >>>>>>>>> >>>>>>>>> -----Original Message----- >>>>>>>>> From: detnet <detnet-bounces@ietf.org<mailto:detnet-bounces@ietf.org>> On >>>>>>>>> Behalf Of Lou Berger >>>>>>>>> Sent: 2018. június 1. 22:42 >>>>>>>>> To: DetNet WG <detnet@ietf.org<mailto:detnet@ietf.org>>; >>>>>>>>> draft-ietf-detnet-architecture@ietf.org<mailto:draft-ietf-detnet-architecture@ietf.org> >>>>>>>>> Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I have a number of high level comments on the document that I'd >>>>>>>>> like to raise below. I also have a number of more >>>>>>>>> editorial/specific comments that I'd like to review directly with >>>>>>>>> the authors and then have them report back on changes -- if any >>>>>>>>> turn out to be more substantive discussions from the author's >>>>>>>>> perspective, I'll raise these on the list separately. >>>>>>>>> >>>>>>>> ... >>>>>>>>> - WRT Section 4.4.3, I think the inclusion of a distributed control >>>>>>>>> plane in the "Network Plane" is inconsistent with other functional >>>>>>>>> definitions and conflates where a function resides from the actual >>>>>>>>> function and that whether control is implemented in a fully >>>>>>>>> centralized, fully distributed or some hybrid form doesn't >>>>>>>>> fundamentally change the control function's role -- therefore I >>>>>>>>> think the sections 4.4.2 and .3 should be revised accordingly >>>>>>>>> [Balázs Varga A] Agree in principal. Let's discuss the details. >>>>>>>>> >>>>>>>> Okay - I'll work with you off line and we can report back the >>>>>>>> results/proposed changes. >>>>>>>> >>>>>>>>> - In several places it's not clear that DetNet service is always a >>>>>>>>> L3 service which is controlled using L3 identifiers, i.e., IP >>>>>>>>> addresses -- this is true even in the MPLS service case and the TSN >>>>>>>>> over MPLS case. I think this is an important point to be clear on in >>>>>>>>> the document. >>>>>>>>> [Balázs Varga A] I am not sure. DetNet service is always provided >>>>>>>>> over a L3 network (IP or MPLS), that is fine. However the service >>>>>>>>> itself can be L2 or L3. In case of TSN Ethernet frames are >>>>>>>>> transported, so it is a L2 service. In case of IP end systems IP >>>>>>>>> packets are transported so it is a L3 service. >>>>>>>>> >>>>>>>> Humm - While I agree that DetNet is providing an (enhanced) L2VPN >>>>>>>> service, it is not itself providing control or service of L2 devices >>>>>>>> -- this is TSN's job. The fact that DetNet is all about behavior of >>>>>>>> L3 nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges) >>>>>>>> is something the architecture should make unambiguous. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Lou >>>>>>>> >>>>>>>>> Please let me know what you think. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Lou >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> detnet mailing list >>>>>>>>> detnet@ietf.org<mailto:detnet@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>>>>>> _______________________________________________ >>>>>>>>> detnet mailing list >>>>>>>>> detnet@ietf.org<mailto:detnet@ietf.org> >>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>>>> >>>>>>> >>>>>>>> On 6/12/2018 6:27 PM, Stewart Bryant wrote: >>>>>>>> Dear Bala'zs >>>>>>>> >>>>>>>> Thank you your for your consideration of these points. I will just >>>>>>>> pick up a few that need some further thought: >>>>>>>> >>>>>>>> >>>>>>>>> DetNet transit node >>>>>>>>> >>>>>>>>> A node operating at the DetNet transport layer, that utilizes >>>>>>>>> >>>>>>>>> link layer and/or network layer switching across multiple >>>>>>>>> >>>>>>>>> links and/or sub-networks to provide paths for DetNet service >>>>>>>>> >>>>>>>>> layer functions. Optionally provides congestion protection >>>>>>>>> >>>>>>>>> over those paths. An MPLS LSR is an example of a DetNet >>>>>>>>> >>>>>>>>> transit node. >>>>>>>>> >>>>>>>>> SB> In that example it would have to be a DetNet enable/aware LSR. An >>>>>>>>> >>>>>>>>> SB> ordinary LSR would not know anything about DetNet. >>>>>>>>> >>>>>>>>> [Balázs Varga A] No, A DetNet aware LSR would be a relay node (S-PE). >>>>>>>>> >>>>>>>> I think the confusion is what "DetNet Transport Layer" means. This >>>>>>>> technology touches on Transport Layer in the L4 sense, and the >>>>>>>> Transport Network Layer as in the packet network that carries >>>>>>>> L3 packets. >>>>>>>> >>>>>>>> So I think that we need to clarify whether a DetNet transit node >>>>>>>> is an S-PE (i.e. a a transit node in the DetNet layer), or a P node >>>>>>>> (i.e. a transit node that is carrying DetNet packets but could be >>>>>>>> carrying any sort of MPLS packet) >>>>>>>> >>>>>>>>> ============ >>>>>>>>> >>>>>>>>> These three techniques can be applied independently, giving eight >>>>>>>>> >>>>>>>>> possible combinations, including none (no DetNet), although some >>>>>>>>> >>>>>>>>> combinations are of wider utility than others. This separation keeps >>>>>>>>> >>>>>>>>> the protocol stack coherent and maximizes interoperability with >>>>>>>>> >>>>>>>>> existing and developing standards in this (IETF) and other Standards >>>>>>>>> >>>>>>>>> Development Organizations. Some examples of typical expected >>>>>>>>> >>>>>>>>> combinations: >>>>>>>>> >>>>>>>>> o Explicit routes plus service protection are exactly the techniques >>>>>>>>> >>>>>>>>> employed by [HSR-PRP]. Explicit routes are achieved by limiting >>>>>>>>> >>>>>>>>> the physical topology of the network, and the sequentialization, >>>>>>>>> >>>>>>>>> replication, and duplicate elimination are facilitated by packet >>>>>>>>> >>>>>>>>> tags added at the front or the end of Ethernet frames. >>>>>>>>> >>>>>>>>> SB> ER can be done virtually as well as physically. RSVP is a type of >>>>>>>>> >>>>>>>>> SB> ER, as is Adj-SID based SR, and we can design other types. >>>>>>>>> >>>>>>>>> [Balázs Varga A] Agree, but these are examples. Statement is for >>>>>>>>> HSR-PRP. >>>>>>>>> >>>>>>>> So the question is whether we should expand the set of examples, >>>>>>>> particularly >>>>>>>> to more accessible ones. >>>>>>>> >>>>>>>> ============ >>>>>>>>> Packet replication and elimination >>>>>>>>> >>>>>>>>>>>>>>>>>> relay > > > > > > > > >>>>>>>>>> /------------+ R node E +------------\ > >>>>>>>>>> / v + ^ \ > >>>>>>>>> end R + v | ^ + E end >>>>>>>>> >>>>>>>>> system + v | ^ + system >>>>>>>>> >>>>>>>>>> \ v + ^ / > >>>>>>>>>> \------------+ R relay E +-----------/ > >>>>>>>>>>>>>>>>>> node > > > > > > > > >>>>>>>>> Figure 1 >>>>>>>>> >>>>>>>>> Packet replication and elimination does not react to and correct >>>>>>>>> >>>>>>>>> failures; it is entirely passive. Thus, intermittent failures, >>>>>>>>> >>>>>>>>> SB> I think it copes with intermittent failures OK. >>>>>>>>> >>>>>>>>> [Balázs Varga A] Yes, PRF and PEF can eliminate the effect of such >>>>>>>>> failures. But text >>>>>>>>> >>>>>>>>> intends to say that it is passive. It is not reacting to such >>>>>>>>> failures. No change in text. >>>>>>>>> >>>>>>>> You say that PREF does not correct failures. I would contend that is >>>>>>>> exactly >>>>>>>> what it does. Sure it does not react but it does correct, and it does >>>>>>>> address intermittent failures. >>>>>>>>> =========== >>>>>>>>> >>>>>>>>> transported between the peer end systems. Therefore, the following >>>>>>>>> >>>>>>>>> possible types / formats of a DetNet flow are distinguished in this >>>>>>>>> >>>>>>>>> document: >>>>>>>>> >>>>>>>>> o App-flow: native format of a DetNet flow. It does not contain any >>>>>>>>> >>>>>>>>> DetNet related attributes. >>>>>>>>> >>>>>>>>> o DetNet-t-flow: specific format of a DetNet flow. Only requires >>>>>>>>> >>>>>>>>> the congestion / latency features provided by the Detnet transport >>>>>>>>> >>>>>>>>> layer. >>>>>>>>> >>>>>>>>> o DetNet-s-flow: specific format of a DetNet flow. Only requires >>>>>>>>> >>>>>>>>> the replication/elimination feature ensured by the DetNet service >>>>>>>>> >>>>>>>>> layer. >>>>>>>>> >>>>>>>>> o DetNet-st-flow: specific format of a DetNet flow. It requires >>>>>>>>> >>>>>>>>> both DetNet service layer and DetNet transport layer functions >>>>>>>>> >>>>>>>>> during forwarding. >>>>>>>>> >>>>>>>>> SB> I find the relisting of these types confusing. Wheren't they >>>>>>>>> defined >>>>>>>>> >>>>>>>>> SB> in the section above? >>>>>>>>> >>>>>>>>> [Balázs Varga A] This is inline with the previous section " Grouping >>>>>>>>> of end systems ". >>>>>>>>> >>>>>>>> Surely if we have defined them we never need to do anything but name >>>>>>>> them in >>>>>>>> later sections. Redefinition is never a good idea because it often >>>>>>>> leads to >>>>>>>> conflicting definitions. >>>>>>>> >>>>>>>>> ============ >>>>>>>>> >>>>>>>>> [HSR-PRP] IEC, "High availability seamless redundancy (HSR) is a >>>>>>>>> >>>>>>>>> further development of the PRP approach, although HSR >>>>>>>>> >>>>>>>>> functions primarily as a protocol for creating media >>>>>>>>> >>>>>>>>> redundancy while PRP, as described in the previous >>>>>>>>> >>>>>>>>> section, creates network redundancy. PRP and HSR are both >>>>>>>>> >>>>>>>>> described in the IEC 62439 3 standard.", >>>>>>>>> >>>>>>>>> <http://webstore.iec.ch/webstore/webstore.nsf/ >>>>>>>>> >>>>>>>>> artnum/046615!opendocument>. >>>>>>>>> >>>>>>>>> SB> Not available at the time of this review, but my recollection is >>>>>>>>> >>>>>>>>> SB> that this is not readily available without paying a large fee. >>>>>>>>> >>>>>>>> If we decide that this is essential as a key reference, there needs to be >>>>>>>> some suitable text, as this will get raised a number of times between >>>>>>>> here an publication as first the directorates and then the ADs run >>>>>>>> into this. >>>>>>>> >>>>>>>>> =========== >>>>>>>>> >>>>>>>>> [ISA95] ANSI/ISA, "Enterprise-Control System Integration Part 1: >>>>>>>>> >>>>>>>>> Models and Terminology", 2000, >>>>>>>>> >>>>>>>>> <https://www.isa.org/isa95/>. >>>>>>>>> >>>>>>>>> SB> Should that be 2000, or 2010. >>>>>>>>> >>>>>>>>> SB> Note that this seems to be a very expensive document to access. >>>>>>>>> >>>>>>>> You did not comment on the correctness of the reference. >>>>>>>> Best Regards >>>>>>>> >>>>>>>> Stewart >>>>>> _______________________________________________ >>>>>> detnet mailing list >>>>>> detnet@ietf.org<mailto:detnet@ietf.org> >>>>>> https://www.ietf.org/mailman/listinfo/detnet >>>>> _______________________________________________ >>>>> detnet mailing list >>>>> detnet@ietf.org<mailto:detnet@ietf.org> >>>>> https://www.ietf.org/mailman/listinfo/detnet >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org<mailto:detnet@ietf.org> >>>> https://www.ietf.org/mailman/listinfo/detnet >>> > _______________________________________________ > detnet mailing list > detnet@ietf.org<mailto:detnet@ietf.org> > https://www.ietf.org/mailman/listinfo/detnet >
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Stewart Bryant
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Balázs Varga A
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Balázs Varga A
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… János Farkas
- [Detnet] Extended WG Last Call: draft-ietf-detnet… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Andrew G. Malis
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… János Farkas
- [Detnet] WG Last Call: draft-ietf-detnet-architec… Lou Berger
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Andrew G. Malis
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Stewart Bryant
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Andrew G. Malis
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Norman Finn
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… BRUNGARD, DEBORAH A
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Andrew G. Malis
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… BRUNGARD, DEBORAH A
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… BRUNGARD, DEBORAH A
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Andrew G. Malis
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Pascal Thubert (pthubert)
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Lou Berger
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… János Farkas
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… János Farkas
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] Extended WG Last Call: draft-ietf-de… Norman Finn
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Janos Farkas
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Janos Farkas
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Norman Finn
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Lou Berger
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Black, David
- Re: [Detnet] WG Last Call: draft-ietf-detnet-arch… Prof. Diego Dujovne
- [Detnet] draft-ietf-detnet-architecture-07 János Farkas
- Re: [Detnet] draft-ietf-detnet-architecture-07 János Farkas