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

["Pascal Thubert (pthubert)" <[e-mail]>]

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