Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

From: János Farkas <[email-masked]>
Date: Wed, 4 Jul 2018 20:15:02 +0200

Hi David,

Thank you very much for your review and comments!

Please see in-line.

On 6/29/2018 4:10 PM, Black, David wrote:
>
> The -06 version of this draft is much improved over the -05 version – 
> lots of diligent work by the authors is evident and appreciated.
>
> I have two minor content concerns and some smaller editorial items.
>
> ** Content
>
> -- Section 2.2
>
> The definition of “bridged path” looks like a definition of “bridged 
> forwarding” – the definition needs to encompass the notion of a path 
> that involves more than one bridge.
>
>    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.
>
You are right, it looks like the emphasis is on bridge forwarding rather 
than path.
However, the superposition of the outbound ports provides a path, which 
was tried to be captured by "hence the path".
The idea was to keep it simple not dive into the details, which are not 
necessary in this document.

Would it be good to update to:

    bridged path

            A VLAN bridge uses the VLAN ID and the destination MAC

            address to select the outbound port. The superposition of 
the outbound ports is the path for a frame.

?

Or should we do something else?
There is only one occurrence of "bridged path" in the text in brackets.

> -- Section 4
>
> Figure 2 in Section 4.1.1 introduces the Detnet service and transport 
> layers.   The associated text quickly dives into explaining the 
> functionality in those layers, but it would be helpful to start with 
> an initial high level description of each of those layers that helps 
> motivate their separation.  It appears that:
>
> - The DetNet Service layer provides timely reliable in-order DetNet 
> flow delivery to applications that use DetNet.   A DetNet flow at the 
> top of the DetNet Service layer may or may not be a compound flow at 
> the bottom of that layer.
>
> - The DetNet Transport layer insulates DetNet flows (at the bottom of 
> the DetNet Service layer) from interference by network mechanisms, 
> primarily queuing and routing, where congestion is an indication of 
> queueing interference.  A DetNet flow at the top of the DetNet 
> Transport layer may or may not be a member flow that is part of a 
> compound flow, depending on what is done in the DetNet Service layer.
>

You are right, section 4 jumps into the details without much of an 
introduction. I guess we had a kind of chicken and egg problem here. 
Figure 4 provides a higher level view than Figure 2. However, Figure 4 
captures different aspects, dives into the details of data plane 
options. So, it seems better to keep the order.

We could add some introductory text to 4.1 or 4.1.1, for instance:
The functionality needed for DetNet (Section 3) are implemented in the 
DetNet layer which comprises the DetNet service layer and the DetNet 
transport layer. The DetNet service layer functions rely on flow 
identification and sequencing. The DetNet transport layer function may 
rely on flow identification.

What do you think?

Should we also rearrange, e.g., indent the text after Figure 2 such that
Packet sequencing, Duplicate elimination, Flow replication, Flow 
merging, Packet encoding, and Packet decoding get under Service layer
and
Congestion protection and Explicit routes get under Transport layer?

> There’s a related paragraph of text between Figures 3 and 4 in Section 
> 4.1.2, but it doesn’t provide useful intuition about which 
> functionality belongs in which layer.
>
> ** Editorial
>
> -- Section 2.1
>
> “expected” seems off in the definition of reservation:
>
> reservation
>
> The set of resources allocated between a source and one or
>
> more destinations through transit nodes and subnets
>
> associated with a DetNet flow, to provide the expected DetNet
>
> Service.
>
> Suggest either “to provide the provisioned DetNet Service to that flow”
>
I like this one, will update to this one.

> or “to provide the specified DetNet Service to that flow.”
>
> -- Section 3.1
>
>    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.
>
> Is that a sequence bound or a time bound or both?   I suspect that a 
> sequence bound (maximum degree of reordering in a flow, independent of 
> flow rate) was intended.  An analogous clarification would be helpful 
> in section 3.2.2.1 .
>
It is intentionally kept high level in the architecture draft. Details 
are to be provided by the flow information model draft. Please see my 
previous mail: 
https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8.

> -- Section 3.2.3
>
> I don’t understand “defined” in:
>
>    Even the use of
>    redundant paths through a network defined, e.g., by [RFC6372] do not
>    eliminate the chances of packet loss.
>
> Was “e.g., as defined by [RFC6372],” intended?
>
Yes, this was the intention, will update to this one.

>    Many real-time networks rely on physical rings or chains of two-port
>    devices, with a relatively simple ring control protocol.
>
> How does a “ring control protocol” control “chains”?  Suggest: “ring 
> control protocol” -> “control protocol”
>
> Also, are paired chains between common endpoints intended, or a more 
> general notion of chains?
>
This text refers to typical factory deployment, which is chain or ring.
It seems better to keep “ring control protocol” because they are often 
very different from generic control protocols applicable to mesh networks.

Would flipping chain and ring resolve your concern?

    Many real-time networks rely on physical chains or rings of two-port

    devices, with a relatively simple ring control protocol.

>    Explicit routes can be established various ways,
>
> established various -> established in various
>
OK.

>    This is
>    irrespective of the distribution method used, also applies to service
>    protection over explicit routes.
>
> used, also -> used, and also
>
OK.

> -- Figure 5 (Section 4.1.3)
>
> The UNI acronym is introduced without expansion or definition – please 
> correct that, e.g., by defining UNI in Section 2.1.
>
DetNet-UNI is there among the definitions. It seems enough to me.

> -- Figure 9 (Section 4.7.2)
>
> I think I understand what’s going on, but the use of “add/remove” in 
> the figure should be explained in associated text.
>
What about updating the sentence above Figure 9 to:
A packet with corresponding Flow-IDs is illustrated in Figure 9, which 
also indicates where Flow-ID can be added or removed.

> Thanks, --David

Thank you!
Janos

> *From:*detnet [mailto:[email-masked]] *On Behalf Of *János Farkas
> *Sent:* Thursday, June 28, 2018 9:09 PM
> *To:* Lou Berger; Stewart Bryant; [email-masked] >> DetNet WG
> *Subject:* Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05
>
> 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
>     <[email-masked]> <mailto:[email-masked]>
>     wrote:
>
>
>         Hi Lou, Thanks for the comments. See reactions inline.
>         Document update in progress. Cheers Bala'zs
>
>         -----Original Message-----
>         From: detnet <[email-masked]>
>         <mailto:[email-masked]> On Behalf Of Lou Berger
>         Sent: 2018. június 1. 22:42
>         To: DetNet WG <[email-masked]> <mailto:[email-masked]>;
>         [email-masked]
>         <mailto:[email-masked]>
>         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
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/listinfo/detnet
>         _______________________________________________
>         detnet mailing list
>         [email-masked] <mailto:[email-masked]>
>         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
>

---

From: "Black, David" <[email-masked]>
Date: Fri, 6 Jul 2018 21:50:50 +0000

-- Bridged path definition

> There is only one occurrence of "bridged path" in the text in brackets.

That sounds like a better suggestion – change that occurrence and remove the definition of “bridged path” from the draft.  That occurrence is in Section 4.1.1:

   Congestion protection
           The DetNet transport layer provides congestion protection.
           See Section 4.5.  The actual queuing and shaping mechanisms
           are typically provided by underlying subnet layers, these can
           be closely associated with the means of providing paths for
          DetNet flows (e.g., MPLS LSPs or bridged paths), the path and
           the congestion protection are conflated in this figure.

Perhaps: (e.g., MPLS LSPs or bridged paths) -> (MPLS LSPs or other network paths)
or just delete the entire parenthetical example.

-- Section 4

> The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer.
> The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.
>
> What do you think?

I prefer functional (what it does) characterization to mechanistic (how it works) characterization in an overview, e.g., excerpting from what I originally wrote:

·         The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.

·         The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing

> Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
> and

No, I don’t think that’s necessary – Figure 2 provides sufficient structure.

Plus a few more minor comments inline …

Thanks, --David

From: János Farkas [mailto:[email-masked]]
Sent: Wednesday, July 4, 2018 2:15 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

Please see in-line.
On 6/29/2018 4:10 PM, Black, David wrote:
The -06 version of this draft is much improved over the -05 version – lots of diligent work by the authors is evident and appreciated.

** Content

-- Section 2.2

The definition of “bridged path” looks like a definition of “bridged forwarding” – the definition needs to encompass the notion of a path that involves more than one bridge.

   bridged path

           frame.

You are right, it looks like the emphasis is on bridge forwarding rather than path.
However, the superposition of the outbound ports provides a path, which was tried to be captured by "hence the path".
The idea was to keep it simple not dive into the details, which are not necessary in this document.

   bridged path

           address to select the outbound port. The superposition

           of the outbound ports is the path for a frame.
?

-- Section 4

Figure 2 in Section 4.1.1 introduces the Detnet service and transport layers.   The associated text quickly dives into explaining the functionality in those layers, but it would be helpful to start with an initial high level description of each of those layers that helps motivate their separation.  It appears that:
- The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.   A DetNet flow at the top of the DetNet Service layer may or may not be a compound flow at the bottom of that layer.
- The DetNet Transport layer insulates DetNet flows (at the bottom of the DetNet Service layer) from interference by network mechanisms, primarily queuing and routing, where congestion is an indication of queueing interference.  A DetNet flow at the top of the DetNet Transport layer may or may not be a member flow that is part of a compound flow, depending on what is done in the DetNet Service layer.

You are right, section 4 jumps into the details without much of an introduction. I guess we had a kind of chicken and egg problem here. Figure 4 provides a higher level view than Figure 2. However, Figure 4 captures different aspects, dives into the details of data plane options. So, it seems better to keep the order.

We could add some introductory text to 4.1 or 4.1.1, for instance:
The functionality needed for DetNet (Section 3) are implemented in the DetNet layer which comprises the DetNet service layer and the DetNet transport layer. The DetNet service layer functions rely on flow identification and sequencing. The DetNet transport layer function may rely on flow identification.

What do you think?

Should we also rearrange, e.g., indent the text after Figure 2 such that
Packet sequencing, Duplicate elimination, Flow replication, Flow merging, Packet encoding, and Packet decoding get under Service layer
and
Congestion protection and Explicit routes get under Transport layer?

There’s a related paragraph of text between Figures 3 and 4 in Section 4.1.2, but it doesn’t provide useful intuition about which functionality belongs in which layer.

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

Is that a sequence bound or a time bound or both?   I suspect that a sequence bound (maximum degree of reordering in a flow, independent of flow rate) was intended.  An analogous clarification would be helpful in section 3.2.2.1 .
It is intentionally kept high level in the architecture draft. Details are to be provided by the flow information model draft. Please see my previous mail: https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8.

[David>] OK.

-- Section 3.2.3

   Even the use of

How does a “ring control protocol” control “chains”?  Suggest: “ring control protocol” -> “control protocol”
Also, are paired chains between common endpoints intended, or a more general notion of chains?
This text refers to typical factory deployment, which is chain or ring.
It seems better to keep “ring control protocol” because they are often very different from generic control protocols applicable to mesh networks.

[David>] It feels like “ring control protocol” is an important phrase to retain.   In the original text, would it be reasonable to add “(applies to both rings and chains)” to the end of the sentence?

   This is

The UNI acronym is introduced without expansion or definition – please correct that, e.g., by defining UNI in Section 2.1.
DetNet-UNI is there among the definitions. It seems enough to me.

[David>] That’s fine – I overlooked that definition, sorry.

I think I understand what’s going on, but the use of “add/remove” in the figure should be explained in associated text.
What about updating the sentence above Figure 9 to:
A packet with corresponding Flow-IDs is illustrated in Figure 9, which also indicates where Flow-ID can be added or removed.

[David>] Sure, with one minor edit: “where Flow-ID” -> “where each Flow-ID”

Thanks, --David

Thank you!
Janos

From: detnet [mailto:[email-masked]] On Behalf Of János Farkas
Sent: Thursday, June 28, 2018 9:09 PM
To: Lou Berger; Stewart Bryant; [email-masked]<mailto:[email-masked]> >> DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

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

   "allocation

  DetNet service proxy

   bridged path

Section 3.1 Primary goals defining the DetNet QoS

The 3rd paragraph on loss on page 8 after the bullet list has been extended to:

3.2.2.  Service Protection

Service protection is used as a more generic term. Introductory text added:

New sub-section added:

3.2.2.2. Packet Replication and Elimination

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 paragraph added:

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.

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

Balázs,

----------
On June 12, 2018 4:07:35 AM Balázs Varga A <[email-masked]><mailto:[email-masked]> wrote:

Hi Lou, Thanks for the comments. See reactions inline. Document update in progress. Cheers Bala'zs

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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

Cheers,

Lou

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet
_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet

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

[Balázs Varga A] No, A DetNet aware LSR would be a relay node (S-PE).

============

   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

   existing and developing standards in this (IETF) and other Standards

   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

SB> ER can be done virtually as well as physically. RSVP is a type of

[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.

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

   Packet replication and elimination does not react to and correct

[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

   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

[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

              section, creates network redundancy.  PRP and HSR are both

SB> Not available at the time of this review, but my recollection is

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:

SB> Note that this seems to be a very expensive document to access.

Best Regards

Stewart

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Jul 2018 12:47:29 -0400

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,
>>
>> **4.1.1. Representative Protocol Stack Model*
>>
>>> <[email-masked]> wrote:
>>>
>>>> From: detnet <[email-masked]> On Behalf Of Lou Berger
>>>> To: DetNet WG <[email-masked]>;
>>>>       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
>>>> - 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.
>>>>
>>> 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
>>>
>>>> [email-masked]
>>>> [email-masked]
>>>>                  > > > > > > > > > relay > > > > > > > >
>>>>
>>>>                 > /------------+ R node E +------------\ >
>>>>
>>>>                > /                  v + ^               \ >
>>>>
>>>>        end    R +                   v | ^                + E end
>>>>
>>>>        system   +                   v | ^                +   system
>>>>
>>>>                > \                  v + ^               / >
>>>>
>>>>                 > \------------+ R relay E +-----------/ >
>>>>
>>>>                  > > > > > > > > >  node > > > > > > > >
>>>>
>>>> Figure 1
>>>>
> [email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Thu, 12 Jul 2018 14:14:04 -0400

Lou,

Would it be better if we changed “Controller Plane Entity (CPE)" to
"Controller Plane Device (CPD)”? I ask this for a couple of reasons.

1. CPE also means (not in this document, but throughout the industry)
Customer Premise Equipment. Re-defining CPE for this document could be
confusing for readers more accustomed to the usual definition.

2. CPE is, as you noted, very similar to PCE as an acronym. CPD and PCE are
much less likely to be confused or typoed with each other.

Just a thought.

Cheers,
Andy

On Thu, Jul 12, 2018 at 12:47 PM, Lou Berger <[email-masked]> wrote:

>    Computation Element [RFC4655] or entity, or a Network Management entity
> (NME)), or a
> 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
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 12 Jul 2018 16:27:22 -0400

Hi Andy,

     I'll defer to the WG/Authors on the name.  My comment was really 
clarifying PCE vs CPE/CPD/WhateverYouCallIt...

Thanks,

Lou

On 7/12/2018 2:14 PM, Andrew G. Malis wrote:
> 2. CPE is, as you noted, very similar to PCE as an acronym. CPD and 
> PCE are much less likely to be confused or typoed with each other.
>
> Just a thought.
>
> Cheers,
> Andy
>
>
> On Thu, Jul 12, 2018 at 12:47 PM, Lou Berger <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>
>      Hi,
>
>        Computation Element [RFC4655] or entity, or a Network
>     Management entity (NME)), or a
>     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
>
>
>                 <[email-masked]
>                 <mailto:[email-masked]>> wrote:
>
>                     Hi Lou, Thanks for the comments. See reactions
>                     inline. Document
>                     update in progress. Cheers Bala'zs
>
>                     From: detnet <[email-masked]
>                     <mailto:[email-masked]>> On Behalf Of Lou
>                     Berger
>                     To: DetNet WG <[email-masked]
>                     <mailto:[email-masked]>>;
>                     <https://www.ietf.org/mailman/listinfo/detnet>
>                     <https://www.ietf.org/mailman/listinfo/detnet>
>
>
>
>
>                     [Balázs Varga A] Agree, but these are examples.
>                     Statement is for
>                     HSR-PRP.
>
>                                      > > > > > > > > > relay > > > > >
>                     > > >
>
>                                    > /                  v +
>                     ^               \ >
>                            end    R +                   v |
>                     ^                + E end
>                            system   +                   v |
>                     ^                +   system
>                                    > \                  v +
>                     ^               / >
>                                      > > > > > > > > >  node > > > > >
>                     > > >
>
>                     Figure 1
>
>                     [Balázs Varga A] Yes, PRF and PEF can eliminate
>                     the effect of such
>                     failures. But text
>
>                 You say that PREF does not correct failures. I would
>                 contend that is
>                 exactly
>                     SB> I find the relisting of these types confusing.
>                     Wheren't they
>                     defined
>
>                     [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
>                     <http://webstore.iec.ch/webstore/webstore.nsf/>
>
>         <https://www.ietf.org/mailman/listinfo/detnet>
>
>
>     <https://www.ietf.org/mailman/listinfo/detnet>
>
>

---

From: Norman Finn <[email-masked]>
Date: Thu, 12 Jul 2018 22:04:22 +0000

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 [[email-masked]] on behalf of Lou Berger [[email-masked]]
Sent: Thursday, July 12, 2018 9:47 AM
To: [email-masked]
Cc: DetNet WG
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

  Hi,

- WRT 4.4.2

OLD

NEW

OLD

- WRT Section 4.4.3

Thank you,
Lou

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 12 Jul 2018 17:33:44 +0000

Hi,

Sorry for not catching earlier, the abbreviation/acronym "CPE" for controller plane entity clashes with the RFC Editor's abbreviations list where CPE is the well-known abbreviation customer premises equipment:

https://www.rfc-editor.org/materials/abbrev.expansion.txt

To avoid lots of comments during the publication process, best is to find an alternative abbreviation.

Thanks,
Deborah

-----Original Message-----
From: detnet <[email-masked]> On Behalf Of Lou Berger
Sent: Thursday, July 12, 2018 12:47 PM
To: [email-masked]
Cc: DetNet WG <[email-masked]>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

  Hi,

- WRT 4.4.2

OLD

NEW
    Computation Element [RFC4655] or entity, or a Network Management entity (NME)), or a

OLD
    each individual flow.  The PCEs place each flow along a deterministic NEW

- 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:
>       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.)
>
> e.g., "I've reviewed this document and believe it is ready for 
> publication", are welcome!
>
> Thank you,
>
> Lou (as Shepherd)
>
>> "Explicit routes can be established various ways, e.g., with RSVP-TE 
>> [RFC3209], with Segment Routing (SR) 
>>>>       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 
>>>> over MPLS case. I think this is an important point to be clear on 
>>>> in the document.
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
>>>> ailman_listinfo_detnet&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9l
>>>> wi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=aMfC
>>>> DVPT3YMdiViiL9V0euSBe5sY-LKrZm3w1AzZfVs&e=
>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_m
>>>> ailman_listinfo_detnet&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9l
>>>> wi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=aMfC
>>>> DVPT3YMdiViiL9V0euSBe5sY-LKrZm3w1AzZfVs&e=
>>
>>
>>
>>>> SB> In that example it would have to be a DetNet enable/aware LSR. 
>>>> SB> An
>>>>
>>> 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 
>>>> SB> ER can be done virtually as well as physically. RSVP is a type 
>>>> SB> of
>>>>
>>> particularly to more accessible ones.
>>>
>>> ============
>>> 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.
>>>> ===========
>>>>
>>> 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.
>>>
>>>> ============
>>>>
>>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__webstore.iec.c
>>>> h_webstore_webstore.nsf_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW
>>>> 9lwi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=4s
>>>> jAVn2iIEGDI1IhQ0CEvisDuw9KtAQ3ELh_MAUNRSo&e=
>>>>
>>>> SB> Not available at the time of this review, but my recollection 
>>>> SB> is
>>>>
>>> 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.
>>>
>>>> ===========
>>>>
>>>>                <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.isa.org_isa95_&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=uskJx__T6DFJncAuSToswWeLsNcfcE81RV05mvKyflU&e=>.
>>>>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail
> man_listinfo_detnet&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7
> jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=aMfCDVPT3YMdi
> ViiL9V0euSBe5sY-LKrZm3w1AzZfVs&e=

_______________________________________________
detnet mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=aMfCDVPT3YMdiViiL9V0euSBe5sY-LKrZm3w1AzZfVs&e=

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 04:03:35 +0000

Hello Deborah 

I used the term PCE as an extension to what a PCE does today to compute more complex track then simple one or two lanes as it does today, possibly including planning for reservation associated to precise timing and service late setup. It is an extension but not a giant leap either. Can’t we just keep that term?

Regards,

Pascal

> Le 13 juil. 2018 à 00:30, BRUNGARD, DEBORAH A <[email-masked]> a écrit :
> 
> Hi,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 04:19:27 +0000

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 <[email-masked]> a écrit :
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2018 06:24:24 -0400

Pascal,

The issue being raised (by Deborah and Andy) is that the document is 
defining the new three letter acronym "CPE" and that "CPE" is well known 
in the IETF context as "Customer Premise Equipment".  So all that needs 
to be done here is to rename CPE, to minimize change at this late date 
and given how infrequently this TLA is used, how about "Control Plane 
Entity (CPEnt)?

Lou

PS Andy, yes I changed my position on this topic from how I responded to 
your message - just trying to shortcut resolving this minor issue...

----------
On July 13, 2018 12:04:10 AM "Pascal Thubert (pthubert)" 
<[email-masked]> wrote:

> Hello Deborah
>
> I used the term PCE as an extension to what a PCE does today to compute 
> more complex track then simple one or two lanes as it does today, possibly 
> including planning for reservation associated to precise timing and service 
> late setup. It is an extension but not a giant leap either. Can’t we just 
> keep that term?
>
>
> Regards,
>
> Pascal
>
>> Sorry for not catching earlier, the abbreviation/acronym "CPE" for 
>> controller plane entity clashes with the RFC Editor's abbreviations list 
>> where CPE is the well-known abbreviation customer premises equipment:
>>

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2018 06:28:51 -0400

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

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 13 Jul 2018 07:41:07 -0400

Lou,

No problem. I personally prefer “Control Plane Device (CPD)”, but If
Deborah and the RFC Editor accept "Control Plane Entity (CPEnt)”, then I
would be OK with it as well.

Cheers,
Andy

On Fri, Jul 13, 2018 at 6:24 AM, Lou Berger <[email-masked]> wrote:

> defining the new three letter acronym "CPE" and that "CPE" is well known in
> the IETF context as "Customer Premise Equipment".  So all that needs to be
> done here is to rename CPE, to minimize change at this late date and given
> how infrequently this TLA is used, how about "Control Plane Entity (CPEnt)?
>
> Lou
>
> On July 13, 2018 12:04:10 AM "Pascal Thubert (pthubert)" <
> [email-masked]> wrote:
>
> Hello Deborah
>>
>>>>>>>               <https://urldefense.proofpoint
>>>>>>> .com/v2/url?u=https-3A__www.isa.org_isa95_&d=DwIGaQ&c=
>>>>>>> LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=X5hVmXs94u
>>>>>>> -d2MJQfKeTvr0IKdXoWO1ZcWpuJlqnvhU&s=uskJx__T6DFJncAuSToswWeL
>>>>>>> sNcfcE81RV05mvKyflU&e=>.
>>>>>>>
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.iet
>>> f.org_mailman_listinfo_detnet&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicv
>>> jIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=X5hVmXs94u-d2MJQfKeTvr0IKdXo
>>> WO1ZcWpuJlqnvhU&s=aMfCDVPT3YMdiViiL9V0euSBe5sY-LKrZm3w1AzZfVs&e=
>>>
>>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 13 Jul 2018 16:29:41 +0000

I think either are ok- my personal preference is CPEnt  as “Device” seems to hardware centric. I’m wondering if teas/pce may already have a generic term – or be interested in helping so as to have a mutual term going forward.

Deborah

From: Andrew G. Malis <[email-masked]>
Sent: Friday, July 13, 2018 7:41 AM
To: Lou Berger <[email-masked]>
Cc: Pascal Thubert (pthubert) <[email-masked]>; BRUNGARD, DEBORAH A <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

Lou,

No problem. I personally prefer “Control Plane Device (CPD)”, but If Deborah and the RFC Editor accept "Control Plane Entity (CPEnt)”, then I would be OK with it as well.

Cheers,
Andy

On Fri, Jul 13, 2018 at 6:24 AM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
Pascal,

The issue being raised (by Deborah and Andy) is that the document is defining the new three letter acronym "CPE" and that "CPE" is well known in the IETF context as "Customer Premise Equipment".  So all that needs to be done here is to rename CPE, to minimize change at this late date and given how infrequently this TLA is used, how about "Control Plane Entity (CPEnt)?

Lou

PS Andy, yes I changed my position on this topic from how I responded to your message - just trying to shortcut resolving this minor issue...

----------

On July 13, 2018 12:04:10 AM "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>> wrote:
Hello Deborah

Regards,

Pascal
Le 13 juil. 2018 à 00:30, BRUNGARD, DEBORAH A <[email-masked]<mailto:[email-masked]>> a écrit :

Hi,

https://www.rfc-editor.org/materials/abbrev.expansion.txt<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_materials_abbrev.expansion.txt&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=GFPQIOE46CA0LvqaZv31c5HJVaMhDgF6GH15FydNsu0&s=INb5gDbjJ0OvDQn_ybvsY6VuqHkU0KDqBmWbC53BDX4&e=>

Thanks,
Deborah

-----Original Message-----
From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Lou Berger
Sent: Thursday, July 12, 2018 12:47 PM
To: [email-masked]<mailto:[email-masked]>
Cc: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

 Hi,

- WRT 4.4.2

OLD

NEW

OLD

- WRT Section 4.4.3

Thank you,
Lou

WG,

Thank you,

Lou (as Shepherd)

   "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.

  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.

   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

   bridged path

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."

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:

   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."

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."

"Some service protection mechanisms rely on switching from one flow
to

*3.2.3.  Explicit routes*

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."

*

"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."

Best regards,
Janos

----------
On June 12, 2018 4:07:35 AM Balázs Varga A
<[email-masked]<mailto:[email-masked]>> wrote:
Hi Lou, Thanks for the comments. See reactions inline. Document
update in progress. Cheers Bala'zs

-----Original Message-----
From: detnet <[email-masked]<mailto:[email-masked]>> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]<mailto:[email-masked]>>;
[email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on
draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

    DetNet transit node

           A node operating at the DetNet transport layer, that
utilizes

           links and/or sub-networks to provide paths for DetNet
service

           transit node.

   combinations are of wider utility than others.  This separation
keeps

   combinations:

      replication, and duplicate elimination are facilitated by
packet

[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.

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

Figure 1

[Balázs Varga A] Yes, PRF and PEF can eliminate the effect of such
failures. But text

   possible types / formats of a DetNet flow are distinguished in
this

   document:

      layer.

      the replication/elimination feature ensured by the DetNet
service

      layer.

      during forwarding.

SB> I find the relisting of these types confusing. Wheren't they
defined

   [HSR-PRP]  IEC, "High availability seamless redundancy (HSR) is
a

              further development of the PRP approach, although
HSR

              section, creates network redundancy.  PRP and HSR
are both

Best Regards

Stewart

_______________________________________________
detnet mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/detnet<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_detnet&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=GFPQIOE46CA0LvqaZv31c5HJVaMhDgF6GH15FydNsu0&s=wAG-JzO8R33t-22XTsGulhFQ_MnoucyT3WYOTH04ApE&e=>

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Fri, 13 Jul 2018 17:04:52 +0000

Hi Pascal,

As Lou has answered, I was concerned on "CPE".

I think the text is ok on PCE - I think Lou's new text is better - smoother.

Just wanted to add - on supporting reservations, there's a teas document which was just published - RFC8413 which may be of interest.

Thanks,
Deborah

-----Original Message-----
From: Pascal Thubert (pthubert) <[email-masked]> 
Sent: Friday, July 13, 2018 12:04 AM
To: BRUNGARD, DEBORAH A <[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; DetNet WG <[email-masked]>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

Hello Deborah 

Regards,

Pascal

> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc-2Deditor.org_materials_abbrev.expansion.txt&d=DwIGaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=6UhGpW9lwi9dM7jYlxXD8w&m=cLIxZglO0I49LxT9PMnCgh6abH1FoSOuP5HVI9iOgjE&s=_vwmcDDxAECd9NtYSiLF6OFS-bOSmC2LbPhvrPMjcR8&e=

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 17:41:09 +0000

Hello Lou

I agree that CPE is a collision. But the text so far had PCE for path computation entity. Can’t we just leave it at that?

Regards,

Pascal

> Le 13 juil. 2018 à 06:24, Lou Berger <[email-masked]> a écrit :
> 
> Pascal,
> 
>> On July 13, 2018 12:04:10 AM "Pascal Thubert (pthubert)" <[email-masked]> wrote:
>> 
>> Hello Deborah
>>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 17:43:56 +0000

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 <[email-masked]> 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
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 17:48:30 +0000

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) <[email-masked]> a écrit :
> 
> Works for me, Lou,
>

---

From: "Andrew G. Malis" <[email-masked]>
Date: Fri, 13 Jul 2018 13:53:48 -0400

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=[email-masked]> wrote:

> 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 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
> >
> >>> 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.
> >>>
> >>>> 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
> 2nd
> discussion
> I'd
> control
> devices
> is
> name
> is

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 19:15:01 +0000

Oups, you’re right Andy,

it was just added in 06 in replacement to “controller”, and I missed that when I browsed the diffs.

Well, wasn’t “controller” good enough? Note also that the replacement was only partial, and “controller” is still there in many places.

Also, we need to define what we mean by that “controller”, whatever we call it.

At the time of that writing, I viewed the controller as a composite of separate entities, as illustrated below:

Does that make sense?

Cheers,

pascla

From: Andrew G. Malis <[email-masked]>
Sent: vendredi 13 juillet 2018 13:54
To: Pascal Thubert (pthubert) <pthubert=[email-masked]>
Cc: Lou Berger <[email-masked]>; [email-masked]; Norman Finn <[email-masked]>; DetNet WG <[email-masked]>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

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=[email-masked]<mailto:pthubert=[email-masked]>> wrote:
Hello Deborah

Regards,

Pascal

> Le 13 juil. 2018 à 13:44, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> a écrit :
>
> Works for me, Lou,
>
>> Le 13 juil. 2018 à 06:29, Lou Berger <[email-masked]<mailto:[email-masked]>> a écrit :
>>
>> Pascal,
>>
>>>> Le 13 juil. 2018 à 00:04, Norman Finn <[email-masked]<mailto:[email-masked]>> a écrit :
>>>>
>>>> From: detnet [[email-masked]<mailto:[email-masked]>] on behalf of Lou Berger [[email-masked]<mailto:[email-masked]>]

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 Jul 2018 19:57:33 +0000

I agree Lou, that was not the intent.

Actually calling it an entity triggered me here, because we already know that there is more than one.
All you are saying below should end up in our definition of the abstract controller. But calling it an entity should be avoided…

Pascal

From: Lou Berger <[email-masked]>
Sent: vendredi 13 juillet 2018 15:53
To: Pascal Thubert (pthubert) <[email-masked]>; Andrew G. Malis <[email-masked]>; Pascal Thubert (pthubert) <pthubert=[email-masked]>
Cc: [email-masked]; Norman Finn <[email-masked]>; DetNet WG <[email-masked]>
Subject: RE: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

I think CP entity is a better representation of the architecture being agnostic of the control plane being fully centralized, fully distributed, or any hybrid of the two. Saying that control is limited to a single controller and to a pce implementation is certainly overly limiting in my opinion...

Lou

________________________________

On July 13, 2018 3:16:39 PM "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>> wrote:
Oups, you’re right Andy,

Does that make sense?

Cheers,

pascla

From: Andrew G. Malis <[email-masked]<mailto:[email-masked]>>
Sent: vendredi 13 juillet 2018 13:54
To: Pascal Thubert (pthubert) <pthubert=[email-masked]<mailto:pthubert=[email-masked]>>
Cc: Lou Berger <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Norman Finn <[email-masked]<mailto:[email-masked]>>; DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06

Pascal,

Cheers,
Andy

Regards,

Pascal

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2018 15:53:02 -0400

I think CP entity is a better representation of the architecture being 
agnostic of the control plane being fully centralized, fully distributed, 
or any hybrid of the two. Saying that control is limited to a single 
controller and to a pce implementation is certainly overly limiting in my 
opinion...

Lou

----------
On July 13, 2018 3:16:39 PM "Pascal Thubert (pthubert)" 
<[email-masked]> wrote:

> Well, wasn’t “controller” good enough? Note also that the replacement was 
> only partial, and “controller” is still there in many places.
>
> Cc: Lou Berger <[email-masked]>; [email-masked]; 
> Norman Finn <[email-masked]>; DetNet WG <[email-masked]>
> On Fri, Jul 13, 2018 at 1:48 PM, Pascal Thubert (pthubert) 
> <pthubert=[email-masked]<mailto:pthubert=[email-masked]>> 
> wrote:
> Hello Deborah
>
>> Le 13 juil. 2018 à 13:44, Pascal Thubert (pthubert) 
>> <[email-masked]<mailto:[email-masked]>> a écrit :
>>
>> Works for me, Lou,
>>
>>> Le 13 juil. 2018 à 06:29, Lou Berger 
>>> <[email-masked]<mailto:[email-masked]>> 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
>>>
>>>> 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.
>>>>
>>>>> Le 13 juil. 2018 à 00:04, Norman Finn 
>>>>> <[email-masked]<mailto:[email-masked]>> 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 [[email-masked]<mailto:[email-masked]>] on 
>>>>> behalf of Lou Berger [[email-masked]<mailto:[email-masked]>]
>>>>> To:

---

From: Lou Berger <[email-masked]>
Date: Fri, 13 Jul 2018 15:49:44 -0400

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

----------
On July 13, 2018 1:49:00 PM "Pascal Thubert (pthubert)"

---

From: János Farkas <[email-masked]>
Date: Mon, 16 Jul 2018 01:24:37 +0200

Hi David,

Please see in-line.

Thank you!
Janos

On 7/6/2018 11:50 PM, Black, David wrote:
> That sounds like a better suggestion – change that occurrence and 
> remove the definition of “bridged path” from the draft. That 
> occurrence is in Section 4.1.1:
>
>    Congestion protection
>
OK. Let's just delete the entire parenthetical example.

> > The functionality needed for DetNet (Section 3) are implemented in 
> the DetNet layer which comprises the DetNet service layer and the 
> DetNet transport layer.
>
> > The DetNet service layer functions rely on flow identification and 
> sequencing. The DetNet transport layer function may rely on flow 
> identification.
> >
> > What do you think?
>
> I prefer functional (what it does) characterization to mechanistic 
> (how it works) characterization in an overview, e.g., excerpting from 
> what I originally wrote:
>
> ·The DetNet Service layer provides timely reliable in-order DetNet 
> flow delivery to applications that use DetNet.
>
> ·The DetNet Transport layer insulates DetNet flows from interference 
> by network mechanisms, primarily queuing and routing
>
I understand the principle.

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as 
congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for 
DetNet flows over paths provided by the underlying network.

OK.

> *From:*János Farkas [mailto:[email-masked]]
> *Sent:* Wednesday, July 4, 2018 2:15 PM
> *To:* Black, David
> *Cc:* DetNet WG
>     The -06 version of this draft is much improved over the -05
>     version – lots of diligent work by the authors is evident and
>     appreciated.
>
>     The definition of “bridged path” looks like a definition of
>     “bridged forwarding” – the definition needs to encompass the
>     notion of a path that involves more than one bridge.
>
>        bridged path
>
> However, the superposition of the outbound ports provides a path, 
> which was tried to be captured by "hence the path".
>     Figure 2 in Section 4.1.1 introduces the Detnet service and
>     transport layers.   The associated text quickly dives into
>     explaining the functionality in those layers, but it would be
>     helpful to start with an initial high level description of each of
>     those layers that helps motivate their separation.  It appears that:
>
>     - The DetNet Service layer provides timely reliable in-order
>     DetNet flow delivery to applications that use DetNet.   A DetNet
>     flow at the top of the DetNet Service layer may or may not be a
>     compound flow at the bottom of that layer.
>
>     - The DetNet Transport layer insulates DetNet flows (at the bottom
>     of the DetNet Service layer) from interference by network
>     mechanisms, primarily queuing and routing, where congestion is an
>     indication of queueing interference.  A DetNet flow at the top of
>     the DetNet Transport layer may or may not be a member flow that is
>     part of a compound flow, depending on what is done in the DetNet
>     Service layer.
>
>
>     There’s a related paragraph of text between Figures 3 and 4 in
>     Section 4.1.2, but it doesn’t provide useful intuition about which
>     Is that a sequence bound or a time bound or both?   I suspect that
>     a sequence bound (maximum degree of reordering in a flow,
>     independent of flow rate) was intended.  An analogous
>     clarification would be helpful in section 3.2.2.1 .
>
> */[David>] /*OK.
>     How does a “ring control protocol” control “chains”? Suggest:
>     “ring control protocol” -> “control protocol”
>
>     */[David>] /*It feels like “ring control protocol” is an important
>     phrase to retain.   In the original text, would it be reasonable
>     to add “(applies to both rings and chains)” to the end of the
>     sentence?
>
Well, I guess the point is that there are many specific ring protocols, 
but we are looking for a generic solution.
What about deleting "chains" from the sentence?

>     The UNI acronym is introduced without expansion or definition –
>     please correct that, e.g., by defining UNI in Section 2.1.
>
> */[David>] /*That’s fine – I overlooked that definition, sorry.
>
>     I think I understand what’s going on, but the use of “add/remove”
>     in the figure should be explained in associated text.
>
> */[David>] /*Sure, with one minor edit: “where Flow-ID” -> “where each 
> Flow-ID”
>
OK.

>     *To:* Lou Berger; Stewart Bryant; [email-masked]
>     <mailto:[email-masked]> >> DetNet WG
>     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.
>
>
>         <[email-masked]>
>         <mailto:[email-masked]> wrote:
>
>
>
>                  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
>             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.
>             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
>
>
>
>         Thank you your for your consideration of these points. I will
>         just pick up a few that need some further thought:
>
>
>
>
>                 DetNet transit node
>
>                   end    R +                   v | ^                +
>             E end
>             Wheren't they defined

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Jul 2018 01:03:02 +0000

Moving the only two open items to the top …

-- Section 4

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.

David> Yes, that works, although I don’t think “congestion” was meant to be included in the first definition …

[David>] It feels like “ring control protocol” is an important phrase to retain.   In the original text, would it be reasonable to add “(applies to both rings and chains)” to the end of the sentence?
Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

David> Yes, if the sentence is all about rings, it’s clear.

Thanks, --David

From: János Farkas [mailto:[email-masked]]
Sent: Sunday, July 15, 2018 7:25 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

What about just copying the two definitions here:
DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided.
DetNet transport layer optionally provides congestion protection for DetNet flows over paths provided by the underlying network.

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

[David>] It feels like “ring control protocol” is an important phrase to retain.   In the original text, would it be reasonable to add “(applies to both rings and chains)” to the end of the sentence?
Well, I guess the point is that there are many specific ring protocols, but we are looking for a generic solution.
What about deleting "chains" from the sentence?

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: János Farkas <[email-masked]>
Date: Mon, 16 Jul 2018 04:43:25 +0200

Thank you David!

I think we are set. :-)

You got a point, we should update
"DetNet service layer is the layer at which A DetNet Service, such as 
congestion or service protection is provided."
to
"DetNet service layer is the layer at which A DetNet Service, such as 
congestion protection and/or service protection is provided."
in the definitions as well to make it clear.

Thanks,
Janos

On 7/16/2018 3:03 AM, Black, David wrote:
> phrase to retain. In the original text, would it be reasonable to add 
> “(applies to both rings and chains)” to the end of the sentence?
>
> Well, I guess the point is that there are many specific ring 
> protocols, but we are looking for a generic solution.
> *Sent:* Sunday, July 15, 2018 7:25 PM
> *To:* Black, David
> *Cc:* DetNet WG
>     > The functionality needed for DetNet (Section 3) are implemented
>     in the DetNet layer which comprises the DetNet service layer and
>     the DetNet transport layer.
>
>     > The DetNet service layer functions rely on flow identification
>     and sequencing. The DetNet transport layer function may rely on
>     flow identification.
>     >
>     > What do you think?
>
>     (how it works) characterization in an overview, e.g., excerpting
>     from what I originally wrote:
>
>     ·The DetNet Transport layer insulates DetNet flows from
>     interference by network mechanisms, primarily queuing and routing
>
>         helpful to start with an initial high level description of
>         each of those layers that helps motivate their separation.  It
>         appears that:
>
>         DetNet flow delivery to applications that use DetNet.   A
>         DetNet flow at the top of the DetNet Service layer may or may
>         not be a compound flow at the bottom of that layer.
>
>         - The DetNet Transport layer insulates DetNet flows (at the
>         bottom of the DetNet Service layer) from interference by
>         network mechanisms, primarily queuing and routing, where
>         congestion is an indication of queueing interference.  A
>         DetNet flow at the top of the DetNet Transport layer may or
>         may not be a member flow that is part of a compound flow,
>         depending on what is done in the DetNet Service layer.
>
>
>     introduction. I guess we had a kind of chicken and egg problem
>     here. Figure 4 provides a higher level view than Figure 2.
>     However, Figure 4 captures different aspects, dives into the
>     details of data plane options. So, it seems better to keep the order.
>
>     DetNet transport layer. The DetNet service layer functions rely on
>     flow identification and sequencing. The DetNet transport layer
>     function may rely on flow identification.
>
>     What do you think?
>
>         Section 4.1.2, but it doesn’t provide useful intuition about
>         which functionality belongs in which layer.
>
>         ** Editorial
>
>
>
>         -- Section 2.1
>
>         Is that a sequence bound or a time bound or both?   I suspect
>         that a sequence bound (maximum degree of reordering in a flow,
>     It is intentionally kept high level in the architecture draft.
>     Details are to be provided by the flow information model draft.
>     Please see my previous mail:
>     It seems better to keep “ring control protocol” because they are
>     often very different from generic control protocols applicable to
>     mesh networks.
>
>         */[David>] /*It feels like “ring control protocol” is an
>         important phrase to retain.   In the original text, would it
>         be reasonable to add “(applies to both rings and chains)” to
>         the end of the sentence?
>
> Well, I guess the point is that there are many specific ring 
> protocols, but we are looking for a generic solution.
>         The UNI acronym is introduced without expansion or definition
>         – please correct that, e.g., by defining UNI in Section 2.1.
>
>         I think I understand what’s going on, but the use of
>         “add/remove” in the figure should be explained in associated text.
>
>     A packet with corresponding Flow-IDs is illustrated in Figure 9,
>     which also indicates where Flow-ID can be added or removed.
>
>     */[David>] /*Sure, with one minor edit: “where Flow-ID” -> “where
>     each Flow-ID”
>
> OK.
>
>
>         Thanks, --David
>
>
>     Thank you!
>     Janos
>
>
>
>
>         Off-line discussions among Lou, Stewart, and authors followed
>         the discussions to properly address the WGLC comments,
>         including the detailed comments.
>
>         In addition to the changes already described in this thread,
>         the following bigger changes have been made to the draft:
>
>
>         deleted because it was just a leftover from early drafts on
>         what DetNet WG should do; which are covered by the charter
>         anyways.
>
>
>         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
>
>
>
>                 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
>                 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
>                 - 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
>
>
>
>
>             Thank you your for your consideration of these points. I
>             will just pick up a few that need some further thought:
>
>
>
>
>
>                     DetNet transit node
>
>                 Statement is for HSR-PRP.
>
>                       system +                   v | ^               
>                 + system
>             contend that is exactly
>                 section " Grouping of end systems ".
>
>             anything but name them in

---

From: "Black, David" <[email-masked]>
Date: Mon, 16 Jul 2018 13:21:19 +0000

Don’t use “congestion protection” in the definitions for both levels.

Thanks, --David

From: János Farkas [mailto:[email-masked]]
Sent: Sunday, July 15, 2018 10:43 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Thank you David!

I think we are set. :-)

You got a point, we should update
"DetNet service layer is the layer at which A DetNet Service, such as congestion or service protection is provided."
to
"DetNet service layer is the layer at which A DetNet Service, such as congestion protection and/or service protection is provided."
in the definitions as well to make it clear.

Thanks,
Janos

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: Norman Finn <[email-masked]>
Date: Mon, 16 Jul 2018 13:38:21 +0000

I've reviewed this document and believe it is ready for publication.

-- Norm Finn

________________________________________
From: Lou Berger [[email-masked]]
Sent: Thursday, June 28, 2018 7:35 PM
To: [email-masked]; DetNet WG
Subject: Extended WG Last Call: draft-ietf-detnet-architecture-06

Authors,

WG,

Thank you,

Lou (as Shepherd)

---

From: Janos Farkas <[email-masked]>
Date: Wed, 18 Jul 2018 15:44:42 +0000

Hi David,

This implies updating the definition of the DetNet service layer, e.g., to:
DetNet service layer
The layer at which A DetNet Service, e.g., service protection is provided.

The definition of the DetNet transport layer remains the same:
DetNet transport layer
The layer that optionally provides congestion protection for
DetNet flows over paths provided by the underlying network.

Regards,
Janos

From: Black, David <[email-masked]>
Sent: Monday, July 16, 2018 3:21 PM
To: Janos Farkas <[email-masked]>
Cc: DetNet WG <[email-masked]>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Thanks, --David

Thank you David!

I think we are set. :-)

Thanks,
Janos

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

  *   The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.
  *   The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing
I understand the principle.

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Jul 2018 18:19:04 +0000

Hi Janos,

That text works nicely.  In briefly talking to Lou, a related suggestion surfaced: “congestion protection” -> “congestion loss protection” where possible (may need to be abbreviated in the Figure) .

This change would make it clearer that the primary focus is protection from losses caused by congestion as opposed to protection from all congestion.  DetNet should be able to tolerate some modest congestion (e.g., in nodes that don’t have reserved DetNet resources) as long as delivery is reliable and timely.

Thanks, --David

From: Janos Farkas [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 11:45 AM
To: Black, David
Cc: DetNet WG
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Hi David,

Regards,
Janos

From: Black, David <[email-masked]<mailto:[email-masked]>>
Sent: Monday, July 16, 2018 3:21 PM
To: Janos Farkas <[email-masked]<mailto:[email-masked]>>
Cc: DetNet WG <[email-masked]<mailto:[email-masked]>>
Subject: RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Thanks, --David

Thank you David!

I think we are set. :-)

Thanks,
Janos

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: Janos Farkas <[email-masked]>
Date: Wed, 18 Jul 2018 21:26:46 +0000

Both “congestion protection” and “congestion loss protection” work for me.

Note that the architecture document is quite populated with the term “congestion protection”. I do not know the other documents by heart.

So it would be a bit of a change.

I’d like to have the group’s opinion before making such a change, e.g., any objections?

Thanks,
Janos

Sent: Wednesday, July 18, 2018 8:19 PM

Hi Janos,

Thanks, --David

Hi David,

Regards,
Janos

Thanks, --David

Thank you David!

I think we are set. :-)

Thanks,
Janos

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: Norman Finn <[email-masked]>
Date: Wed, 18 Jul 2018 22:45:39 +0000

"Congestion loss protection" is better than "congestion protection".  That's good.

It's a big change, and makes the document unnecessarily wordy.  That's bad.

I would use "congestion protection" but explain somewhere that we are not talking about source throttling.

And if adding that explanation is difficult or controversial, I would stick with "congestion protection".

-- Norm

________________________________
From: detnet [[email-masked]] on behalf of Janos Farkas [[email-masked]]
Sent: Wednesday, July 18, 2018 2:26 PM
To: Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Thanks,
Janos

Hi Janos,

Thanks, --David

Hi David,

Regards,
Janos

Thanks, --David

Thank you David!

I think we are set. :-)

Thanks,
Janos

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

-- Section 4

What do you think?

** Editorial

-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

---

From: Lou Berger <[email-masked]>
Date: Wed, 18 Jul 2018 18:52:21 -0400

This sounds sensible to me...

Lou

----------
On July 18, 2018 6:47:01 PM Norman Finn <[email-masked]> wrote:

> Note that the architecture document is quite populated with the term 
> “congestion protection”. I do not know the other documents by heart.
>
> That text works nicely.  In briefly talking to Lou, a related suggestion 
> surfaced: “congestion protection” -> “congestion loss protection” where 
> possible (may need to be abbreviated in the Figure) .
>
> This change would make it clearer that the primary focus is protection from 
> losses caused by congestion as opposed to protection from all congestion.  
> DetNet should be able to tolerate some modest congestion (e.g., in nodes 
> that don’t have reserved DetNet resources) as long as delivery is reliable 
> and timely.
>
> Thanks, --David
>
>> transport layer.
> I prefer functional (what it does) characterization to mechanistic (how it 
> works) characterization in an overview, e.g., excerpting from what I 
> originally wrote:
>
> ·         The DetNet Service layer provides timely reliable in-order DetNet 
> ·         The DetNet Transport layer insulates DetNet flows from 
> DetNet transport layer optionally provides congestion protection for DetNet 
> flows over paths provided by the underlying network.
>
> It seems better to keep “ring control protocol” because they are often very 
> different from generic control protocols applicable to mesh networks.
>
> [David>] It feels like “ring control protocol” is an important phrase to 
> retain.   In the original text, would it be reasonable to add “(applies to 
> both rings and chains)” to the end of the sentence?
> That sounds like a better suggestion – change that occurrence and remove 
> the definition of “bridged path” from the draft.  That occurrence is in 
> Section 4.1.1:
>
>    Congestion protection
>> transport layer.
> I prefer functional (what it does) characterization to mechanistic (how it 
> works) characterization in an overview, e.g., excerpting from what I 
> originally wrote:
>
>   *   The DetNet Service layer provides timely reliable in-order DetNet flow 
>   delivery to applications that use DetNet.
>   *   The DetNet Transport layer insulates DetNet flows from interference by 
>   network mechanisms, primarily queuing and routing
> DetNet transport layer optionally provides congestion protection for DetNet 
> flows over paths provided by the underlying network.
>
>
>> Packet sequencing, Duplicate elimination, Flow replication, Flow merging, 
>> Packet encoding, and Packet decoding get under Service layer
>> and
> The -06 version of this draft is much improved over the -05 version – lots 
> of diligent work by the authors is evident and appreciated.
>
> forwarding” – the definition needs to encompass the notion of a path that 
> involves more than one bridge.
>
>
>    bridged path
>
> However, the superposition of the outbound ports provides a path, which was 
> tried to be captured by "hence the path".
> functionality in those layers, but it would be helpful to start with an 
> initial high level description of each of those layers that helps motivate 
> their separation.  It appears that:
> - The DetNet Service layer provides timely reliable in-order DetNet flow 
> delivery to applications that use DetNet.   A DetNet flow at the top of the 
> DetNet Service layer may or may not be a compound flow at the bottom of 
> that layer.
> - The DetNet Transport layer insulates DetNet flows (at the bottom of the 
> DetNet Service layer) from interference by network mechanisms, primarily 
> queuing and routing, where congestion is an indication of queueing 
> interference.  A DetNet flow at the top of the DetNet Transport layer may 
> or may not be a member flow that is part of a compound flow, depending on 
> what is done in the DetNet Service layer.
>
> introduction. I guess we had a kind of chicken and egg problem here. Figure 
> 4 provides a higher level view than Figure 2. However, Figure 4 captures 
> different aspects, dives into the details of data plane options. So, it 
> seems better to keep the order.
>
> identification and sequencing. The DetNet transport layer function may rely 
> on flow identification.
>
> What do you think?
>
> Packet sequencing, Duplicate elimination, Flow replication, Flow merging, 
> Packet encoding, and Packet decoding get under Service layer
> and
> 4.1.2, but it doesn’t provide useful intuition about which functionality 
> belongs in which layer.
>
> ** Editorial
>
> -- Section 2.1
>
> sequence bound (maximum degree of reordering in a flow, independent of flow 
> rate) was intended.  An analogous clarification would be helpful in section 
> 3.2.2.1 .
> It is intentionally kept high level in the architecture draft. Details are 
> to be provided by the flow information model draft. Please see my previous 
> mail: https://mailarchive.ietf.org/arch/msg/detnet/AWG2eemg_AWsvF2FwtREyd_xtC8.
>
> [David>] OK.
>
> -- Section 3.2.3
>
> It seems better to keep “ring control protocol” because they are often very 
> different from generic control protocols applicable to mesh networks.
>
> [David>] It feels like “ring control protocol” is an important phrase to 
> retain.   In the original text, would it be reasonable to add “(applies to 
> both rings and chains)” to the end of the sentence?
> I think I understand what’s going on, but the use of “add/remove” in the 
> figure should be explained in associated text.
> A packet with corresponding Flow-IDs is illustrated in Figure 9, which also 
> indicates where Flow-ID can be added or removed.
>
> discussions to properly address the WGLC comments, including the detailed 
> comments.
>
> In addition to the changes already described in this thread, the following 
> bigger changes have been made to the draft:
>
>
> 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.
>
>
> 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
>
> <[email-masked]><mailto:[email-masked]> wrote:
>
>
> To: DetNet WG <[email-masked]><mailto:[email-masked]>; 
>      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
> - 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
>
>

---

From: "Black, David" <[email-masked]>
Date: Wed, 18 Jul 2018 23:52:59 +0000

+1, Thanks, --David

From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, July 18, 2018 6:52 PM
To: Norman Finn; Janos Farkas; Black, David
Cc: DetNet WG
Subject: Re: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05

Lou

On July 18, 2018 6:47:01 PM Norman Finn <[email-masked]<mailto:[email-masked]>> wrote:
"Congestion loss protection" is better than "congestion protection".  That's good.

-- Norm

So it would be a bit of a change..

Thanks,
Janos

Hi Janos,

Thanks, --David

Hi David,

Regards,
Janos

Thanks, --David

Thank you David!

I think we are set. :-)

Thanks,
Janos

-- Section 4

•         The DetNet Service layer provides timely reliable in-order DetNet flow delivery to applications that use DetNet.

•         The DetNet Transport layer insulates DetNet flows from interference by network mechanisms, primarily queuing and routing
I understand the principle.

How does a “ring control protocol” control “chains”?  Suggest: “ring control protocol” -> “control protocol”
Also, are paired chains between common endpoints intended, or a more general notion of chains?
This text refers to typical factory deployment, which is chain or ring..
It seems better to keep “ring control protocol” because they are often very different from generic control protocols applicable to mesh networks.

Thanks, --David

Hi David,

Please see in-line.

Thank you!
Janos

   Congestion protection

-- Section 4

Thanks, --David

Hi David,

Please see in-line.

** Content

-- Section 2.2

   bridged path

           frame.

   bridged path

What do you think?

** Editorial
-- Section 2.1

   reservation

-- Section 3.1

      out-of-order delivery.

[David>] OK.

-- Section 3.2.3

   Even the use of

   This is

Thanks, --David

Thank you!
Janos

Dear all,

   "allocation

  DetNet service proxy

   bridged path

New sub-section added:

3.2.3.  Explicit routes

New paragraph added:

Best regards,
Janos

Balázs,

----------

-----Original Message-----
From: detnet <[email-masked]><mailto:[email-masked]> On Behalf Of Lou Berger
Sent: 2018. június 1. 22:42
To: DetNet WG <[email-masked]><mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture

Hi,

- 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.

Thanks,
Lou

Cheers,

Lou

Dear Bala'zs

    DetNet transit node

           transit node.

============

   combinations:

============

      end    R +                   v | ^                + E end

      system   +                   v | ^                +   system

                                 Figure 1

===========

   document:

      layer.

      layer.

      during forwarding.

============

===========

Best Regards

Stewart

_______________________________________________
detnet mailing list
[email-masked]<mailto:detnet%40ietf.org>
https://www.ietf.org/mailman/listinfo/detnet

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Wed, 18 Jul 2018 20:04:41 -0400

+1

El mié., 18 de jul. de 2018 19:53, Black, David <[email-masked]>
escribió:

> +1, Thanks, --David
>
>
>
> *From:* Lou Berger [mailto:[email-masked]]
> *Sent:* Wednesday, July 18, 2018 6:52 PM
> *To:* Norman Finn; Janos Farkas; Black, David
> *Cc:* DetNet WG
> ------------------------------
>
> ------------------------------
>
> *From:* detnet [[email-masked]] on behalf of Janos Farkas [
> [email-masked]]
> *Sent:* Wednesday, July 18, 2018 2:26 PM
> *To:* Black, David
> *Cc:* DetNet WG
> *From:* Black, David <[email-masked]>
> *Sent:* Wednesday, July 18, 2018 8:19 PM
> *To:* Janos Farkas <[email-masked]>
> *Cc:* DetNet WG <[email-masked]>
> *Subject:* RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05
>
>
>
> Hi Janos,
>
>
>
> This change would make it clearer that the primary focus is protection
> from losses caused by congestion as opposed to protection from all
> congestion.  DetNet should be able to tolerate some modest congestion
> (e.g., in nodes that don’t have reserved DetNet resources) as long as
> delivery is reliable and timely.
>
>
>
> Thanks, --David
>
>
>
> *From:* Janos Farkas [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Wednesday, July 18, 2018 11:45 AM
> *To:* Black, David
> *Cc:* DetNet WG
> *Subject:* RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05
>
>
>
> Hi David,
>
>
>
> *From:* Black, David <[email-masked]>
> *Sent:* Monday, July 16, 2018 3:21 PM
> *To:* Janos Farkas <[email-masked]>
> *Cc:* DetNet WG <[email-masked]>
> *Subject:* RE: [Detnet] WG Last Call: draft-ietf-detnet-architecture-05
>
>
>
> *From:* János Farkas [mailto:[email-masked]
> <[email-masked]>]
> *Sent:* Sunday, July 15, 2018 10:43 PM
> *To:* Black, David
> *Cc:* DetNet WG
> ·         The DetNet Service layer provides timely reliable in-order
> DetNet flow delivery to applications that use DetNet.
>
> *[David>] *It feels like “ring control protocol” is an important phrase
> to retain.   In the original text, would it be reasonable to add “(applies
> to both rings and chains)” to the end of the sentence?
>
> *From:* János Farkas [mailto:[email-masked]
> <[email-masked]>]
>    - The DetNet Transport layer insulates DetNet flows from interference
> *From:* János Farkas [mailto:[email-masked]
> <[email-masked]>]
> mail:
> *[David>] *OK.
> *[David>] *It feels like “ring control protocol” is an important phrase
> to retain.   In the original text, would it be reasonable to add “(applies
> to both rings and chains)” to the end of the sentence?
>
> *[David>] *That’s fine – I overlooked that definition, sorry.
>
>
>
> *[David>] *Sure, with one minor edit: “where Flow-ID” -> “where each
> Flow-ID”
>
> OK.
>
>
>
> Thanks, --David
>
>
> Thank you!
> Janos
>
>
>
> *From:* detnet [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *János Farkas
> * 4.1.1. Representative Protocol Stack Model*
>
> because it was just a leftover from early drafts on what DetNet WG should
> do; which are covered by the charter anyways.
>
>
> On June 12, 2018 4:07:35 AM Balázs Varga A <[email-masked]>
> From: detnet <[email-masked]> <[email-masked]> On
> Behalf Of Lou Berger
> To: DetNet WG <[email-masked]> <[email-masked]>;
>      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.
>
> ...
>
>
> -- therefore I think the sections 4..4.2 and .3 should be revised
> accordingly
> [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.
>
>