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

[Lou Berger <[e-mail]>]

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