Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

[Lou Berger <[e-mail]>]

Umm. You may want to reread the draft....


----------
On July 13, 2018 1:49:00 PM "Pascal Thubert (pthubert)" 
<[e-mail]> 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) <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 [[e-mail]] on behalf of Lou Berger 
>>>>> [[e-mail]]
>>>>> Sent: Thursday, July 12, 2018 9:47 AM
>>>>> To: [e-mail]
>>>>> 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
>>>>>>>> <[e-mail]> wrote:
>>>>>>>>
>>>>>>>>> Hi Lou, Thanks for the comments. See reactions inline. Document
>>>>>>>>> update in progress. Cheers Bala'zs
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: detnet <[e-mail]> On Behalf Of Lou Berger
>>>>>>>>> Sent: 2018. június 1. 22:42
>>>>>>>>> To: DetNet WG <[e-mail]>;
>>>>>>>>> [e-mail]
>>>>>>>>> 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
>>>>>>>>> [e-mail]
>>>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>>>> _______________________________________________
>>>>>>>>> detnet mailing list
>>>>>>>>> [e-mail]
>>>>>>>>> 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
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>> _______________________________________________
>>>>> detnet mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>> _______________________________________________
>>>> detnet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>