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

["BRUNGARD, DEBORAH A" <[e-mail]>]

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 <[e-mail]>
Sent: Friday, July 13, 2018 7:41 AM
To: Lou Berger <[e-mail]>
Cc: Pascal Thubert (pthubert) <[e-mail]>; BRUNGARD, DEBORAH A <[e-mail]>; [e-mail]; DetNet WG <[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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)" <[e-mail]<mailto:[e-mail]>> 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
Le 13 juil. 2018 à 00:30, BRUNGARD, DEBORAH A <[e-mail]<mailto:[e-mail]>> a écrit :

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

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

Thanks,
Deborah

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


 Hi,

I have the following comments/questions:

- WRT 4.4.2

I think CPE and PCE are a bit conflated.  To clarify, hiw about:

OLD
   to any device operating in that plane, whether is it a Path
   Computation entity, or a Network Management entity (NME)), or a
   distributed control plane.  The Path Computation Element (PCE)
   [RFC4655] is a core element of a controller, in charge of computing
   Deterministic paths to be applied in the Network Plane.

NEW
   to any device operating in that plane, whether is it a Path
   Computation Element [RFC4655] or entity, or a Network Management entity    (NME)), or a
   distributed control plane.  The CPE
    is a core element of a controller, in charge of computing
   Deterministic paths to be applied in the Network Plane.

and s/PCE/CPE in the next paragraph, specifically:

OLD
   One or more PCE(s) collaborate to implement the requests from the FME
   as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for
   each individual flow.  The PCEs place each flow along a deterministic NEW
   One or more CPE(s) collaborate to implement the requests from the FME
   as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for
   each individual flow.  The CPEs place each flow along a deterministic

- WRT Section 4.4.3
I'm unclear as to what "Operational Plane (control plane)" means in the first paragraph.  Should it perhaps read "Operational Plane (OAM)"? If not, what is the intent of "control plane" in this paragraph (and section)?

Thank you,
Lou
On 6/28/2018 10:35 PM, Lou Berger wrote:
Authors,

     Thank you for the update!

WG,

     This document has changed to a sufficient degree that I think a
2nd last call is warranted.  Typically I would start a 1 week LC in
these circumstances - but given the proximity to the meeting I'd like
to start a 3 week LC right ending with the IETF meeting -- that is on July 20th.
This should allow for both adequate review of the changes and
discussion of the changes in our WG session (Monday July 16.)

As always, please send LC comment to the list and positive comments,
e.g., "I've reviewed this document and believe it is ready for
publication", are welcome!

Thank you,

Lou (as Shepherd)
On 6/28/2018 9:08 PM, János Farkas wrote:
Dear all,

Off-line discussions among Lou, Stewart, and authors followed the
discussions to properly address the WGLC comments, including the
detailed comments.

A new revision of the draft has been uploaded:
draft-ietf-detnet-architecture-06.

In addition to the changes already described in this thread, the
following bigger changes have been made to the draft:


*Section 2.1 Terms used in this document*

Some definitions refined as suggested by the detailed comments

New definitions have been added:

   "allocation
           Resources are dedicated to support a DetNet flow.
Depending
           on an implementation, the resource may be reused by non-
           DetNet flows when it is not used by the DetNet flow.


   PEF     A Packet Elimination Function (PEF) eliminates duplicate
           copies of packets to prevent excess packets flooding the
           network or duplicate packets being sent out of the DetNet
           domain.  PEF can be implemented by an edge node, a relay
           node, or an end system.

  PRF     A Packet Replication Function (PRF) replicates DetNet flow
           packets and forwards them to one or more next hops in the
           DetNet domain.  The number of packet copies sent to each
next
           hop is a DetNet flow specific parameter at the node doing
the
           replication.  PRF can be implemented by an edge node, a
relay
           node, or an end system.

   PREOF   Collective name for Packet Replication, Elimination, and
           Ordering Functions.

   POF     A Packet Ordering Function (POF) re-orders packets within
a
           DetNet flow that are received out of order.  This
function
           can be implemented by an edge node, a relay node, or an
end
           system.

  DetNet service proxy
           Maps between App-flows and DetNet flows.

   bridged path
           A VLAN bridge uses the VLAN ID and the destination MAC
           address to select the outbound port hence the path for a
           frame."


*Section 3.1 Primary goals defining the DetNet QoS*

A new QoS aspect has been added:
   "o  An upper bound on out-of-order packet delivery.  It is worth
      noting that some DetNet applications are unable to tolerate
any
      out-of-order delivery."


The 3rd paragraph on loss on page 8 after the bullet list has been
extended to:
   "After congestion, the most important contributions to packet
loss are
   typically from random media errors and equipment failures.
Service
   protection is the name for the mechanisms used by DetNet to
address
   these losses.  The mechanisms employed are constrained by the
   requirement to meet the users' latency requirements.  Packet
   replication and elimination (Section 3.2.2) and packet encoding
   (Section 3.2.2.3) are described in this document to provide
service
   protection; others may be found.  For instance, packet encoding
can
   be used to provide service protection against random media
errors,
   packet replication and elimination can be used to provide service
   protection against equipment failures.  This mechanism
distributes
   the contents of DetNet flows over multiple paths in time and/or
   space, so that the loss of some of the paths does need not cause
the
   loss of any packets."


*3.2.2.  Service Protection*

Service protection is used as a more generic term. Introductory text
added:
   "Service protection aims to mitigate or eliminate packet loss due
to
   equipment failures, random media and/or memory faults.  These
types
   of packet loss can be greatly reduced by spreading the data over
   multiple disjoint forwarding paths.  Various service protection
   methods are described in [RFC6372], e.g., 1+1 linear protection.
   This section describes the functional details of an additional
method
   in Section 3.2.2.2, which can be implemented as described in
   Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls]
in
   order to provide 1+n hitless protection.  The appropriate service
   protection mechanism depends on the scenario and the requirements."


New sub-section added:

"3.2.2.1.  In-Order Delivery

   Out-of-order packet delivery can be a side effect of service
   protection.  Packets delivered out-of-order impact the amount of
   buffering needed at the destination to properly process the
received
   data.  Such packets also influence the jitter of a flow.  The
DetNet
   service includes maximum allowed misordering as a constraint.
Zero
   misordering would be a valid service constraint to reflect that
the
   end system(s) of the flow cannot tolerate any out-of-order delivery.
   Service protection may provide a mechanism to support in-order
   delivery."


*3.2.2.2. Packet Replication and Elimination*

New bullet added as the last one:
   "o  The Packet Ordering Function (POF) uses the sequencing
information
      to re-order a DetNet flow's packets that are received out of
      order."

New sentence added after the bullet list:
"The order in which a node applies the PEF and the PRF to a DetNet
flow is implementation specific."

2nd paragraph after the bullet list has been updated to:
"Some service protection mechanisms rely on switching from one flow
to
   another when a failure of a flow is detected.  Contrarily, packet
   replication and elimination combines the DetNet member flows sent
   along multiple different paths, and performs a packet-by-packet
   selection of which to discard, e.g., based on sequencing information."


*3.2.3.  Explicit routes*

Out-of-order aspect added to the first paragraph, which is about
distributed routing:
"Furthermore, out-of-order
packet delivery can be a side effect of route changes."

New sentence added to the 3rd paragraph:
"Explicit routes can be established various ways, e.g., with RSVP-TE
[RFC3209], with Segment Routing (SR)
[I-D.ietf-spring-segment-routing], via a Software Defined Networking
approach [RFC7426], with IS-IS [RFC7813], etc."

New paragraph added:
   "Out-of-order packet delivery can be a side effect of
distributing a
   single flow over multiple paths especially when there is a change
   from one path to another when combining the flow.  This is
   irrespective of the distribution method used, also applies to
service
   protection over explicit routes.  As described in Section
3.2.2.1,
   out-of-order packets influence the jitter of a flow and impact
the
   amount of buffering needed to process the data; therefore, DetNet
   service includes maximum allowed misordering as a constraint. The
   use of explicit routes helps to provide in-order delivery because
   there is no immediate route change with the network topology, but
the
   changes are plannable as they are between the different explicit
   routes."

*
**4.1.1. Representative Protocol Stack Model*

"Explicit routes" have been added to Figure 2 with the corresponding
explanation:
 "Explicit routes
           The DetNet transport layer provides mechanisms to ensure
that
           fixed paths are provided for DetNet flows.  These
explicit
           paths avoid the impact of network convergence."


Section 4.11 Connected islands vs. networks of v05 has been deleted
because it was just a leftover from early drafts on what DetNet WG
should do; which are covered by the charter anyways.


References have been cleaned up and brought up-to-date.


Refinements have been implemented in the draft according to Lou's
detailed comments. They are not listed here because they are minor
changes.


Best regards,
Janos

On 6/12/2018 2:48 PM, Lou Berger wrote:
Balázs,

Thanks for the response -- please see below.

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

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

Hi,

     I have a number of high level comments on the document that
I'd like to  raise below.  I also have a number of more
editorial/specific comments that  I'd like to review directly with
the authors and then have them report back  on changes -- if any
turn out to be more substantive discussions from the  author's
perspective, I'll raise these on the list separately.
...
- WRT Section 4.4.3, I think the inclusion of a distributed control
plane in the "Network Plane" is inconsistent with other functional
definitions and conflates where a function resides from the actual
function and that whether control is implemented in a fully
centralized, fully distributed or some hybrid form doesn't
fundamentally change  the control function's role -- therefore I
think the sections 4.4.2 and .3 should be revised accordingly
[Balázs Varga A] Agree in principal. Let's discuss the details.
Okay - I'll work with you off line and we can report back the
results/proposed changes.
- In several places it's not clear that DetNet service is always a
L3 service which is controlled using L3 identifiers, i.e., IP
addresses -- this is true even in the MPLS service case and the TSN
over MPLS case. I think this is an important point to be clear on
in the document.
[Balázs Varga A] I am not sure. DetNet service is always provided
over a L3 network (IP or MPLS), that is fine. However the service
itself can be L2 or L3. In case of TSN Ethernet frames are
transported, so it is a L2 service. In case of IP end systems IP
packets are transported so it is a L3 service.
Humm - While I agree that DetNet is providing an (enhanced) L2VPN
service, it is not itself providing control or service of L2 devices
-- this is TSN's job.  The fact that DetNet is all about behavior of
L3 nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges)
is something the architecture should make unambiguous.

Thanks,
Lou
Please let me know what you think.

Cheers,

Lou


_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
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=
_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
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=


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


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

artnum/046615!opendocument>.

SB> Not available at the time of this review, but my recollection
SB> 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://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=>.

SB> Should that be 2000, or 2010.

SB> Note that this seems to be a very expensive document to access.
You did not comment on the correctness of the reference.

Best Regards

Stewart
_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
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=

_______________________________________________
detnet mailing list
[e-mail]<mailto:[e-mail]>
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=>