Re: [Detnet] Fwd: Re: Tsvart last call review of draft-ietf-detnet-architecture-08
Lou Berger <lberger@labn.net> Thu, 15 November 2018 07:41 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 07AF8127B92 for <detnet@ietfa.amsl.com>; Wed, 14 Nov 2018 23:41:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.701
X-Spam-Level:
X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (body has been altered)" 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 ChXPp-zh3-Cp for <detnet@ietfa.amsl.com>; Wed, 14 Nov 2018 23:41:51 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (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 652DB126BED for <detnet@ietf.org>; Wed, 14 Nov 2018 23:41:51 -0800 (PST)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id DB2911E0607 for <detnet@ietf.org>; Thu, 15 Nov 2018 00:41:50 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id NCHegxqNoE0jMNCHegIckU; Thu, 15 Nov 2018 00:41:50 -0700
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=TSuQSpFhC8OEERRBVizBZEiI6SphSXT29HJHmZ7N9BU=; b=cD0lW+LNoYfu2tgz5B5Ji0kAB3 HWlsu7f0t6HCA5bGoln9zS5J2ggMPiZw3tY5PLH4IzrBgKwhayIqd6gaGycuav3FbncLkycA/5kgv ljDueRCv/KRyKaDKYl/Vp8Deb;
Received: from me65036d0.tmodns.net ([208.54.80.230]:38237 helo=[100.88.148.170]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1gNCHX-000byO-RX; Thu, 15 Nov 2018 00:41:50 -0700
From: Lou Berger <lberger@labn.net>
To: János Farkas <Janos.Farkas@ericsson.com>, "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>, "Black, David" <David.Black@dell.com>
CC: tsv-art@ietf.org, DetNet WG <detnet@ietf.org>
Date: Thu, 15 Nov 2018 16:41:34 +0900
Message-ID: <167165167c8.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <2b1d286d-d127-393d-d735-d8dfd8ce57f2@ericsson.com>
References: <6b6d3f37-0d43-553a-da0a-b1a3bb1a094c@ericsson.com> <2b1d286d-d127-393d-d735-d8dfd8ce57f2@ericsson.com>
User-Agent: AquaMail/1.17.0-1318 (build: 101700009)
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----------16716516bd6226227ce3b1bfc"
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: 208.54.80.230
X-Source-L: No
X-Exim-ID: 1gNCHX-000byO-RX
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: me65036d0.tmodns.net ([100.88.148.170]) [208.54.80.230]:38237
X-Source-Auth: lberger@labn.net
X-Email-Count: 14
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/3CE5XThJ2BJQxn3ZUuF3zWnTCZM>
Subject: Re: [Detnet] Fwd: Re: 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: Thu, 15 Nov 2018 07:41:56 -0000
Just an FYI. I have some proposed text for the architecture document that I'm running by Michael and David. I'll circulate it to the list once I'm no longer in transit. Lou ---------- On November 15, 2018 4:31:40 PM János Farkas <janos.farkas@ericsson.com> wrote: > Hi, > > Coming back to the aspects that have not been picked up in the ongoing > email discussions. > Combining the Michael's email and David's add-on to that. > > Some comments, suggestions are in line, marked <JF> </JF>. > > Best regards, > Janos > > ps: In this month, I have difficulties with accessing emails. Sorry > about that. I trust that the WG, including co-authors. continue the > discussions. > > > > On 11/4/2018 6:21 PM, Black, David wrote: >> Trying to help with these Transport issues. I generally agree with Michael >> Sharf's >> first two concerns. Like Michael, I will defer to the IESG on appropriate >> use of >> RFC 7426. >> >> In each case, I've extracted a key piece of text to try to make the point >> crisp ... >> >> [1] Minimum required level of DetNet support. >> >>> Does "some of the DetNet capabilities >>> (not necessarily all)" include e.g. vanilla traffic engineering? For >>> instance, if a >>> network node can ensure that the QoS requirements are met by leveraging >>> existing standardized TE without any additional DetNet awareness, is this >>> enough for deploying DetNet? Or does this node have to implement additional >>> DetNet-specific functionality? Specifically, please explain if an existing >>> DetNet- >>> unaware router on the path taken by DetNet traffic can be used to forward >>> DetNet traffic, or if it is mandatory that any router forwarding DetNet traffic >>> indeed implements new capabilities specific to DetNet. >> It's the former, as indicated by this text in Section 4.2.2 (I'm working >> from the -09 draft): >> >> In general, if a DetNet flow passes through one or more DetNet- >> unaware network nodes between two DetNet nodes providing the DetNet >> transport sub-layer for that flow, there is a potential for >> disruption or failure of the DetNet QoS. A network administrator >> needs to ensure that the DetNet-unaware network nodes are configured >> to minimize the chances of packet loss and delay, and provision >> enough extra buffer space in the DetNet transit node following the >> DetNet-unaware network nodes to absorb the induced latency >> variations. >> >> Perhaps a forward reference to Section 4.2.2 from the new text in the >> Introduction would help. > <JF> > David is right. > Forward reference will be added. Furthermore, the last sentence will be > updated in order to make it clear. > > The suggested new text: > > A goal of DetNet is a converged network in all respects. That is, the > presence of DetNet flows does not preclude non-DetNet flows, and the > benefits offered DetNet flows should not, except in extreme cases, > prevent existing QoS mechanisms from operating in a normal fashion, > subject to the bandwidth required for the DetNet flows. A single > source-destination pair can trade both DetNet and non-DetNet flows. End > systems and applications need not instantiate special interfaces for > DetNet flows. Networks are not restricted to certain topologies; > connectivity is not restricted. Any application that generates a data > flow that can be usefully characterized as having a maximum bandwidth > should be able to take advantage of DetNet, as long as the necessary > resources can be reserved. Reservations can be made by the application > itself, via network management, by an application’s controller, or by > other means, e.g., a dynamic control plane (e.g., [RFC2205]). Network > nodes of a DetNet domain, i.e., DetNet nodes have to implement DetNet > capabilities in order to treat DetNet flows such that their QoS > requirements are met. DetNet nodes can be interconnected with different > sub-network technologies (4.1.2), where the nodes of the subnet are not > DetNet aware (4.2.2). > > > > Furthermore, the the following text is suggested to be added at the end > of section 4.5: > > All nodes in a DetNet domain are expected to support the data behavior > required to deliver a particular DetNet service. If a node itself is > not DetNet service aware, the DetNet nodes that are adjacent to such > non-DetNet aware nodes must ensure that the non-DetNet aware node is > provisioned to appropriately support the DetNet service. For example, > an IEEE 802.1 TSN node may be used to interconnect DetNet aware nodes, > and these DetNet nodes can map DetNet flows to 802.1 TSN flows. An other > example, and MPLS-TE or TP domain may be used to interconnect DetNet > aware nodes, and these DetNet nodes can map DetNet flows to TE LSPs > which can provide the Quality of Service requirements of the DetNet > service. > </JF> > > > > On 10/22/2018 11:44 PM, Scharf, Michael wrote: >> Hi Janos, >> >> Thanks for the reply. My comments are inline [ms]. >> >> I have omitted all proposed changes that work for me. >> >> Michael >> >> >> -----Original Message----- >> From: János Farkas<janos.farkas@ericsson.com> >> Sent: Wednesday, October 17, 2018 10:56 AM >> To: Scharf, Michael<Michael.Scharf@hs-esslingen.de> >> Cc:tsv-art@ietf.org;draft-ietf-detnet-architecture.all@ietf.org; DetNet >> WG<detnet@ietf.org> >> Subject: Re: Tsvart last call review of draft-ietf-detnet-architecture-08 >> >> Hi Michael, >> >> Thank you very much for the thorough review and good comments! >> >> Please find below in-line responses and how we plan to update the draft to >> resolve your comments. >> >> Best regards, >> Janos >> >> >> On 9/29/2018 12:24 AM, Michael Scharf wrote: >>> Reviewer: Michael Scharf >>> Review result: Ready with Issues >>> >>> The document "Deterministic Networking Architecture" >>> (draft-ietf-detnet-architecture-08) defines an overall framework for >>> Deterministic Networking. >>> >>> As TSV-ART reviewer, I believe that this document has issues as >>> detailed below. >>> >>> Michael >>> >>> Major issues: >> [...] >> >>> DetNet >>> basically requires support in (almost) all network devices >>> transporting DetNet traffic. That assumption should be explicitly >>> spelt out early in the document, e.g., in the introduction. >> Actually, some form of DetNet support is required from each node that >> transports DetNet traffic. For instance, DetNet flows have to be recognized >> in order not to spoil their QoS at the minimum. >> >> [ms] I look for an clear explanation in the architecture document of what >> "some form of DetNet support" exactly means. > <JF> > The key point is that each DetNet node of a DetNet MUST support DetNet. > There is text making this point, e.g., the definition of DetNet domain. > However, you are right, further clarifications are needed in the text. > See suggestions below. > </JF> > >> For instance, is standard MPLS TE without any DetNet support good enough >> for an LSR on the IP/MPLS path used by DetNet traffic, or not? As an >> example, when I read the following paragraph in >> draft-ietf-detnet-dp-sol-mpls-01 ... >> >> Transit nodes are normal MPLS Label Switching Routers (LSRs). They >> are generally unaware of the special requirements of DetNet flows, >> although they need to provide traffic engineering services and proper >> QoS to the LSPs associated with DetNet flows to enhance the prospect >> of the LSPs meeting the DetNet service requirements. Some >> implementations of transit nodes may be DetNet aware, but such nodes >> just support the DetNet transport layer. >> >> ... I could maybe assume that actually there can be "transit nodes" that do >> not require *any* sort of DetNet support or DetNet awareness. Is that correct? > <JF> > It is correct. > DetNet nodes of a DetNet domain can be interconnected by various subnet > technologies, e.g., MPLS TE. The nodes of the subnet, e.g., and LSR are > not DetNet aware. > </JF> > >> I think the architecture document has to be clear on such fundamental >> questions. > <JF> > See suggestions for clarification below. > </JF> > > >> The Introduction could be extended to clarify, e.g., the third paragraph: >> >> OLD: >> A goal of DetNet is a converged network in all respects. That is, the >> presence of DetNet flows does not preclude non-DetNet flows, and the >> benefits offered DetNet flows should not, except in extreme cases, prevent >> existing QoS mechanisms from operating in a normal fashion, subject to the >> bandwidth required for the DetNet flows. A single source-destination pair >> can trade both DetNet and non-DetNet flows. End systems and applications >> need not instantiate special interfaces for DetNet flows. Networks are not >> restricted to certain topologies; connectivity is not restricted. Any >> application that generates a data flow that can be usefully characterized >> as having a maximum bandwidth should be able to take advantage of DetNet, >> as long as the necessary resources can be reserved. Reservations can be >> made by the application itself, via network management, by an application’s >> controller, or by other means, e.g., a dynamic control plane (e.g., [RFC2205]). >> >> NEW: >> A goal of DetNet is a converged network in all respects. That is, the >> presence of DetNet flows does not preclude non-DetNet flows, and the >> benefits offered DetNet flows should not, except in extreme cases, prevent >> existing QoS mechanisms from operating in a normal fashion, subject to the >> bandwidth required for the DetNet flows. A single source-destination pair >> can trade both DetNet and non-DetNet flows. End systems and applications >> need not instantiate special interfaces for DetNet flows. Networks are not >> restricted to certain topologies; connectivity is not restricted. Any >> application that generates a data flow that can be usefully characterized >> as having a maximum bandwidth should be able to take advantage of DetNet, >> as long as the necessary resources can be reserved. Reservations can be >> made by the application itself, via network management, by an application’s >> controller, or by other means, e.g., a dynamic control plane (e.g., >> [RFC2205]). Network nodes supporting DetNet flows have to implement some of >> the DetNet capabilities (not necessarily all) in order to treat DetNet >> flows such that their QoS requirements are met. >> >> [ms] To me, the last sentence is not clear. Does "some of the DetNet >> capabilities (not necessarily all)" include e.g. vanilla traffic >> engineering? For instance, if a network node can ensure that the QoS >> requirements are met by leveraging existing standardized TE without any >> additional DetNet awareness, is this enough for deploying DetNet? Or does >> this node have to implement additional DetNet-specific functionality? >> Specifically, please explain if an existing DetNet-unaware router on the >> path taken by DetNet traffic can be used to forward DetNet traffic, or if >> it is mandatory that any router forwarding DetNet traffic indeed implements >> new capabilities specific to DetNet. In the latter case, I think the >> document would need to discuss incremental deployment strategies as well. >> >>> * It is surprising that there is hardly any discussion on network >>> robustness >>> and safety; this probably also relates to security. For instance, >>> misconfiguration or errors of functions performing packet replication >>> could >>> severely and permantly congest a network and cause harm. How does the >>> DetNet >>> architecture ensure that a network stays fully operational e.g. if the >>> topology >>> changes or there are equipment failures? Probably this can be solved by >>> implementations (e.g., dynamic control plane), but why are corresponding >>> requirements not spelt out? Section 3.3.2 speculates that filters and >>> policers >>> can help, and that may be true, but that probably still assumes >>> consistently >>> and correctly configured (and well-behaving) devices. And Section 3.3.2 is >>> vague and mentions a "infinite variety of possible failures" without >>> stating >>> any requirements or recommendations. There may be further solutions, >>> such as >>> circuit breakers and the like. Why are such topics not discussed? >> Security issues and considerations are addressed by the DetNet Security >> draft:https://datatracker.ietf.org/doc/draft-ietf-detnet-security. >> Reference to the DetNet Security draft will be added. >> >> There will be a document dedicated to Operations, Administration and >> Maintenance (OAM), which will address operational, misconfiguration, and >> failure detection issues. >> >> The topology changes have to be solved by the control plane, either >> centralized or distributed. >> >> The filters and policers described in Section 3.3.2 also provide >> robustness by eliminating/mitigating traffic coming from malfunctioning >> devices. >> >> RFC2475 is recommended for traffic policing functions to increase >> robustness. >> >> The text in Section 3.3.2 could be made clearer, e.g., by updating the >> first paragraph to: >> >> OLD: >> One key to building robust real-time systems is to reduce the >> infinite variety of possible failures to a number that can be >> analyzed with reasonable confidence. DetNet aids in the process by >> allowing for filters and policers to detect DetNet packets received >> on the wrong interface, or at the wrong time, or in too great a >> volume, and to then take actions such as discarding the offending >> packet, shutting down the offending DetNet flow, or shutting down the >> offending interface. >> >> NEW: >> Robust real-time systems require to reduce the number of possible >> failures. Filters and policers should be used in a DetNet network to >> detect if DetNet packets are received on the wrong interface, or at >> the wrong time, or in too great volume. Furthermore, filters and >> policers can take action to discard offending packets or flows, or >> trigger shutting down the offending DetNet flow, or shutting down >> the offending interface. >> >> [ms] That does not address my concern. As I wrote already, I believe this >> document has to discuss the applicability of circuit breakers according to >> RFC 8084. >> >>> * Somewhat related, the document only looks at impact of failures to >>> the QoS of >>> DetNet traffic. What is missing is a discussion how to protect >>> non-DetNet parts >>> of a network from any harm caused by DetNet mechanisms. Solutions to this >>> probably exist. But why is the impact on non-DetNet traffic (e.g., in >>> case of >>> topology changes or failures of DetNet functions) not discussed at all >>> in the >>> document? >> Actually the regulation of DetNet traffic by polices and filters >> protects both other DetNet traffic and non-DetNet traffic. >> >> Section 3.3.1 could be extended to make it clear, e.g., by extending the >> last paragraph: >> >> OLD: >> Ideally, the net effect of the presence of DetNet flows in a network >> on the non-DetNet packets is primarily a reduction in the available >> bandwidth. >> >> NEW: >> Traffic policing functions (e.g. [RFC2475]) are used to avoid the >> starvation of non-DetNet traffic. Thus, the net effect of the presence >> of DetNet flows in a network on non-DetNet flows is primarily a >> reduction in the available bandwidth. >> >> [ms] I believe a stronger wording is needed, e.g. along the lines of "a >> DetNet deployment must avoid starvation of non-DetNet traffic ...". > <JF> > Along your suggestion, the text will be updated to: > Starvation of non-DetNet traffic must be avoided, e.g., by traffic > policing functions (e.g. [RFC2475]). Thus, the net effect of the > presence of DetNet flows in a network on non-DetNet flows is > primarily a reduction in the available bandwidth. > </JF> > >> [...] >> >>> * Section 4.4 refers to RFC 7426, which is an informational RFC on >>> IRTF stream, >>> and the document uses the concepts introduced there (e.g., "planes"). >>> This is >>> very confusing. First, an IETF Proposed Standard should probably refer to >>> documents having IETF consensus. An example would be RFC 7491, albeit >>> there is >>> other related work as well, e.g., in the TEAS WG. Second, Section 4.4 >>> is by and >>> large decoupled from the rest of the document and not specific to DetNet. >>> Neither do other sections of the document refer to the concepts >>> introduced in >>> Section 4.4, nor does Section 4.4 use the DetNet terminology or discuss >>> applicability to DetNet. Section 4.4 even mentions explicitly at the >>> end that >>> it discusses aspects that are orthogonal to the DetNet architecture. >>> It is not >>> at all clear why Section 4.4 is in this document. Section 4.4 could be >>> removed >>> from the document without impacting the rest of the document. >> The document should point out to traffic engineering and centralized >> control plane aspects, so it is better to keep Section 4.4. >> >> RFC 7426 provides the full picture of SDN architecture, which needs to >> be referred from the DetNet architecture. No other RFC provides such >> detailed picture. Therefore, we need to keep the reference to RFC 7426, >> which is an informative reference. >> >> [ms] I'll leave that up to the IESG to decide whether an IETF proposed >> standard should build an architecture based on research work instead of, >> say, documents with IETF consensus. As a side note, I believe the >> understanding in industry what "SDN architecture" really means and how it >> is implemented may have evolved since publication of IRTF RFC 7426, which >> was published in Jan. 2015. For instance, IRTF RFC 7426 does not discuss >> the implications of segment routing, BGP-LS, and other recent IETF >> techniques. And, based on what I read in the DetNet architecture, I believe >> DetNet could actually be implemented without any "SDN architecture", e.g. >> by distributed traffic engineering. As a result, I don't even understand >> the need to discuss "SDN". >> >> [ms] For the record: As TSV-ART reviewer, I question whether IRTF RFC 7426 >> is indeed an appropriate reference, I have doubts that IRTF RFC 7426 is >> really up-to-date, and I am concerned about the content quality of section >> 4.4, e.g., regarding the lack of alignment with the rest of the document. >> The IESG will certainly have a better understanding that than me how to >> deal with such topics. > > <JF> > The subject is introduced with TEAS in the beginning of Section 4.4. The > architectural principles described in the DetNet architecture document > are according to RFC 8453 and RFC 7149, as well as RFC 7426. It would be > good to make this point clearer by adding references to RFC 8453 and RFC > 7149. As the architectural principles are the same, there is no need to > remove RFC 7426. > > Suggested modifications: > > Section 3.3: > > OLD: > Explicit routes can be established in > various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) > [RFC8402], via a Software Defined Networking approach [RFC7426], with > IS-IS [RFC7813], etc. Explicit routes are typically used in MPLS TE > LSPs. > > NEW: > Explicit routes can be established in > various ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR) > [RFC8402], via a Software Defined Networking approach [RFC7426], > [RFC8453], and [RFC7149], with IS-IS [RFC7813], etc. Explicit routes > are typically used in MPLS TE LSPs. > > Section 4.4 > > OLD: > The Deterministic Networking architecture is thus composed of three > planes, a (User) Application Plane, a Controller Plane, and a Network > Plane, which echoes that of Figure 1 of Software-Defined Networking > (SDN): Layers and Architecture Terminology [RFC7426].: > > > NEW: > The Deterministic Networking architecture is thus composed of three > planes, a (User) Application Plane, a Controller Plane, and a Network > Plane, which echoes that of Figure 1 of Software-Defined Networking > (SDN): Layers and Architecture Terminology [RFC7426] , and the > Controllers identified in [RFC8453] and [RFC7149]. > > </JF> > >> >> The related work in TEAS is already referred to. >> >> [...] >> >>> Minor issues: >>> >>> * Terminology "DetNet transport layer" >>> >>> The term "transport layer" has a well-defined meaning in the IETF, e.g. >>> originating from RFC 1122. While "transport" and e.g. "transport >>> network" is >>> used in the IETF for different technologies in different areas, I >>> think the >>> term "transport layer" is typically understood to refer to transport >>> protocols such as TCP and UDP. As such, I personally find the term "DetNet >>> transport layer" misleading and confusing. The confusion is easy to >>> see e.g. >>> in Figure 4, where UDP (which is a transport protocol as per RFC 1122) >>> sits >>> on top of "transport". >>> >>> Based on the document it also may be solution/implementation specific >>> whether >>> the "DetNet transport layer" is actually a separate protocol layer >>> compared >>> to the "DetNet service layer". Thus it is not clear to me why the word >>> "layer" has to be used, specifically in combination "transport layer". >>> >>> To me as, the word "transport layer" (and "transport protocol") should be >>> used for protocols defined in TSV area, consistent with RFC 1122. But >>> this is >>> probably a question to be sorted out by the IESG. >> "transport" is used here as in "packet transport networks" not as OSI L4 >> transport. >> >> [ms] At the risk of stating the obvious: The relevant section of RFC 1122 >> defining "transport layer" is entitled by "The Internet Architecture". And, >> according e.g. to RFC 5921, "packet transport network" is a term defined by >> ITU-T. In an IETF document, I believe IETF terminology should be used. >> >> I suggest to use the terms "DetNet transport sub-layer" and "DetNet >> service sub-layer" throughout the document, which would hopefully avoid >> confusion. >> >> [ms] "DetNet transport sub-layer" somewhat solves my concern of avoiding >> the expression "transport layer". To really avoid confusion, I believe it >> would be better to avoid the ambiguous term "transport" altogether. But I >> will be fine if all DetNet documents consistently avoid the term "transport >> layer". > <JF> > The plan is to avoid "transport layer". > > Based on your comment, it seems better to make the following change in > 3.2.2.2: > > OLD: > o Providing sequencing information to the packets of a DetNet > compound flow. This may be done by adding a sequence number or > time stamp as part of DetNet, or may be inherent in the packet, > e.g., in a Layer-4 transport protocol, or associated to other > physical properties such as the precise time (and radio channel) > of reception of the packet. This is typically done once, at or > near the source. > > NEW: > o Providing sequencing information to the packets of a DetNet > compound flow. This may be done by adding a sequence number or > time stamp as part of DetNet, or may be inherent in the packet, > e.g., in a higher layer protocol, or associated to other > physical properties such as the precise time (and radio channel) > of reception of the packet. This is typically done once, at or > near the source. > </JF> > >> 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