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

["Andrew G. Malis" <[e-mail]>]

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=[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
> >>
> _______________________________________________
> detnet mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet
>