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

[Lou Berger <[e-mail]>]

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:
> 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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>      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://www.ietf.org/mailman/listinfo/detnet
>                     <https://www.ietf.org/mailman/listinfo/detnet>
>                     _______________________________________________
>                     detnet mailing list
>                     [e-mail] <mailto:[e-mail]>
>                     https://www.ietf.org/mailman/listinfo/detnet
>                     <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/
>                     <http://webstore.iec.ch/webstore/webstore.nsf/>
>
>                     artnum/046615!opendocument>.
>
>                     SB> Not available at the time of this review, but
>                     my recollection is
>
>                     SB> that this is not readily available without
>                     paying a large fee.
>
>                 If we decide that this is essential as a key
>                 reference, there needs to be
>                 some suitable text, as this will get raised a number
>                 of times between
>                 here an publication as first the directorates and then
>                 the ADs run
>                 into this.
>
>                     ===========
>
>                         [ISA95]    ANSI/ISA, "Enterprise-Control
>                     System Integration Part 1:
>
>                                    Models and Terminology", 2000,
>
>                                    <https://www.isa.org/isa95/>.
>
>                     SB> Should that be 2000, or 2010.
>
>                     SB> Note that this seems to be a very expensive
>                     document to access.
>
>                 You did not comment on the correctness of the reference.
>
>
>                 Best Regards
>
>                 Stewart
>
>         _______________________________________________
>         detnet mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/detnet
>         <https://www.ietf.org/mailman/listinfo/detnet>
>
>
>     _______________________________________________
>     detnet mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/detnet
>     <https://www.ietf.org/mailman/listinfo/detnet>
>
>