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

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

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 <[e-mail]> 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
> 
>> On 7/13/2018 12:19 AM, Pascal Thubert (pthubert) wrote:
>> Hello Lou and Norm:
>> 
>> I meant control protocols over the LMI as well as measurement (OAM) and automation such as (reflex) reactions that do no pass via a controller.
>> 
>> The LMI provides information on the status of a DetNet path which can act as go/nogo for data and trigger fallback. It may in the future enable flow setup if one day we go for a more distributed design. It may provide time though for DetNet it is not in scope. It may provide rate control as well which is the object of a draft I have to split.
>> 
>> So operation there was meant as a generic term for train data traffic overhead inside the network as opposed to in relation with a controller.
>> 
>> Should we expand to clarify?
>> 
>> Regards,
>> 
>> Pascal
>> 
>>> Le 13 juil. 2018 à 00:04, Norman Finn <[e-mail]> a écrit :
>>> 
>>> Pascal wrote that chunk.  I always assumed that "Operational Plane (control plane)" was some sort of IETF phrase I just didn't understand.  If it's OAM, I don't see what the "(control plane)" is for.
>>> 
>>> Pascal?
>>> 
>>> -- Norm
>>> ________________________________________
>>> From: detnet [[e-mail]] on behalf of Lou Berger [[e-mail]]
>>> Sent: Thursday, July 12, 2018 9:47 AM
>>> To: [e-mail]
>>> Cc: DetNet WG
>>> Subject: Re: [Detnet] Extended WG Last Call: draft-ietf-detnet-architecture-06
>>> 
>>>  Hi,
>>> 
>>> I have the following comments/questions:
>>> 
>>> - WRT 4.4.2
>>> 
>>> I think CPE and PCE are a bit conflated.  To clarify, hiw about:
>>> 
>>> OLD
>>>    to any device operating in that plane, whether is it a Path
>>>    Computation entity, or a Network Management entity (NME)), or a
>>>    distributed control plane.  The Path Computation Element (PCE)
>>>    [RFC4655] is a core element of a controller, in charge of computing
>>>    Deterministic paths to be applied in the Network Plane.
>>> 
>>> NEW
>>>    to any device operating in that plane, whether is it a Path
>>>    Computation Element [RFC4655] or entity, or a Network Management
>>> entity (NME)), or a
>>>    distributed control plane.  The CPE
>>>     is a core element of a controller, in charge of computing
>>>    Deterministic paths to be applied in the Network Plane.
>>> 
>>> and s/PCE/CPE in the next paragraph, specifically:
>>> 
>>> OLD
>>>    One or more PCE(s) collaborate to implement the requests from the FME
>>>    as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for
>>>    each individual flow.  The PCEs place each flow along a deterministic
>>> NEW
>>>    One or more CPE(s) collaborate to implement the requests from the FME
>>>    as Per-Flow Per-Hop Behaviors installed in the intermediate nodes for
>>>    each individual flow.  The CPEs place each flow along a deterministic
>>> 
>>> - WRT Section 4.4.3
>>> I'm unclear as to what "Operational Plane (control plane)" means in the
>>> first paragraph.  Should it perhaps read "Operational Plane (OAM)"? If
>>> not, what is the intent of "control plane" in this paragraph (and section)?
>>> 
>>> Thank you,
>>> Lou
>>> 
>>>> On 6/28/2018 10:35 PM, Lou Berger wrote:
>>>> Authors,
>>>> 
>>>>      Thank you for the update!
>>>> 
>>>> WG,
>>>> 
>>>>      This document has changed to a sufficient degree that I think a 2nd
>>>> last call is warranted.  Typically I would start a 1 week LC in these
>>>> circumstances - but given the proximity to the meeting I'd like to start
>>>> a 3 week LC right ending with the IETF meeting -- that is on July 20th.
>>>> This should allow for both adequate review of the changes and discussion
>>>> of the changes in our WG session (Monday July 16.)
>>>> 
>>>> As always, please send LC comment to the list and positive comments,
>>>> e.g., "I've reviewed this document
>>>> and believe it is ready for publication", are welcome!
>>>> 
>>>> Thank you,
>>>> 
>>>> Lou (as Shepherd)
>>>> 
>>>>> On 6/28/2018 9:08 PM, János Farkas wrote:
>>>>> Dear all,
>>>>> 
>>>>> Off-line discussions among Lou, Stewart, and authors followed the
>>>>> discussions to properly address the WGLC comments, including the
>>>>> detailed comments.
>>>>> 
>>>>> A new revision of the draft has been uploaded:
>>>>> draft-ietf-detnet-architecture-06.
>>>>> 
>>>>> In addition to the changes already described in this thread, the
>>>>> following bigger changes have been made to the draft:
>>>>> 
>>>>> 
>>>>> *Section 2.1 Terms used in this document*
>>>>> 
>>>>> Some definitions refined as suggested by the detailed comments
>>>>> 
>>>>> New definitions have been added:
>>>>> 
>>>>>    "allocation
>>>>>            Resources are dedicated to support a DetNet flow. Depending
>>>>>            on an implementation, the resource may be reused by non-
>>>>>            DetNet flows when it is not used by the DetNet flow.
>>>>> 
>>>>> 
>>>>>    PEF     A Packet Elimination Function (PEF) eliminates duplicate
>>>>>            copies of packets to prevent excess packets flooding the
>>>>>            network or duplicate packets being sent out of the DetNet
>>>>>            domain.  PEF can be implemented by an edge node, a relay
>>>>>            node, or an end system.
>>>>> 
>>>>>   PRF     A Packet Replication Function (PRF) replicates DetNet flow
>>>>>            packets and forwards them to one or more next hops in the
>>>>>            DetNet domain.  The number of packet copies sent to each next
>>>>>            hop is a DetNet flow specific parameter at the node doing the
>>>>>            replication.  PRF can be implemented by an edge node, a relay
>>>>>            node, or an end system.
>>>>> 
>>>>>    PREOF   Collective name for Packet Replication, Elimination, and
>>>>>            Ordering Functions.
>>>>> 
>>>>>    POF     A Packet Ordering Function (POF) re-orders packets within a
>>>>>            DetNet flow that are received out of order.  This function
>>>>>            can be implemented by an edge node, a relay node, or an end
>>>>>            system.
>>>>> 
>>>>>   DetNet service proxy
>>>>>            Maps between App-flows and DetNet flows.
>>>>> 
>>>>>    bridged path
>>>>>            A VLAN bridge uses the VLAN ID and the destination MAC
>>>>>            address to select the outbound port hence the path for a
>>>>>            frame."
>>>>> 
>>>>> 
>>>>> *Section 3.1 Primary goals defining the DetNet QoS*
>>>>> 
>>>>> A new QoS aspect has been added:
>>>>>    "o  An upper bound on out-of-order packet delivery.  It is worth
>>>>>       noting that some DetNet applications are unable to tolerate any
>>>>>       out-of-order delivery."
>>>>> 
>>>>> 
>>>>> The 3rd paragraph on loss on page 8 after the bullet list has been
>>>>> extended to:
>>>>>    "After congestion, the most important contributions to packet loss are
>>>>>    typically from random media errors and equipment failures. Service
>>>>>    protection is the name for the mechanisms used by DetNet to address
>>>>>    these losses.  The mechanisms employed are constrained by the
>>>>>    requirement to meet the users' latency requirements.  Packet
>>>>>    replication and elimination (Section 3.2.2) and packet encoding
>>>>>    (Section 3.2.2.3) are described in this document to provide service
>>>>>    protection; others may be found.  For instance, packet encoding can
>>>>>    be used to provide service protection against random media errors,
>>>>>    packet replication and elimination can be used to provide service
>>>>>    protection against equipment failures.  This mechanism distributes
>>>>>    the contents of DetNet flows over multiple paths in time and/or
>>>>>    space, so that the loss of some of the paths does need not cause the
>>>>>    loss of any packets."
>>>>> 
>>>>> 
>>>>> *3.2.2.  Service Protection*
>>>>> 
>>>>> Service protection is used as a more generic term. Introductory text
>>>>> added:
>>>>>    "Service protection aims to mitigate or eliminate packet loss due to
>>>>>    equipment failures, random media and/or memory faults.  These types
>>>>>    of packet loss can be greatly reduced by spreading the data over
>>>>>    multiple disjoint forwarding paths.  Various service protection
>>>>>    methods are described in [RFC6372], e.g., 1+1 linear protection.
>>>>>    This section describes the functional details of an additional method
>>>>>    in Section 3.2.2.2, which can be implemented as described in
>>>>>    Section 3.2.2.3 or as specified in [I-D.ietf-detnet-dp-sol-mpls] in
>>>>>    order to provide 1+n hitless protection.  The appropriate service
>>>>>    protection mechanism depends on the scenario and the requirements."
>>>>> 
>>>>> 
>>>>> New sub-section added:
>>>>> 
>>>>> "3.2.2.1.  In-Order Delivery
>>>>> 
>>>>>    Out-of-order packet delivery can be a side effect of service
>>>>>    protection.  Packets delivered out-of-order impact the amount of
>>>>>    buffering needed at the destination to properly process the received
>>>>>    data.  Such packets also influence the jitter of a flow.  The DetNet
>>>>>    service includes maximum allowed misordering as a constraint. Zero
>>>>>    misordering would be a valid service constraint to reflect that the
>>>>>    end system(s) of the flow cannot tolerate any out-of-order delivery.
>>>>>    Service protection may provide a mechanism to support in-order
>>>>>    delivery."
>>>>> 
>>>>> 
>>>>> *3.2.2.2. Packet Replication and Elimination*
>>>>> 
>>>>> New bullet added as the last one:
>>>>>    "o  The Packet Ordering Function (POF) uses the sequencing information
>>>>>       to re-order a DetNet flow's packets that are received out of
>>>>>       order."
>>>>> 
>>>>> New sentence added after the bullet list:
>>>>> "The order in which a node applies the PEF and the PRF to a DetNet
>>>>> flow is implementation specific."
>>>>> 
>>>>> 2nd paragraph after the bullet list has been updated to:
>>>>> "Some service protection mechanisms rely on switching from one flow to
>>>>>    another when a failure of a flow is detected.  Contrarily, packet
>>>>>    replication and elimination combines the DetNet member flows sent
>>>>>    along multiple different paths, and performs a packet-by-packet
>>>>>    selection of which to discard, e.g., based on sequencing information."
>>>>> 
>>>>> 
>>>>> *3.2.3.  Explicit routes*
>>>>> 
>>>>> Out-of-order aspect added to the first paragraph, which is about
>>>>> distributed routing:
>>>>> "Furthermore, out-of-order
>>>>> packet delivery can be a side effect of route changes."
>>>>> 
>>>>> New sentence added to the 3rd paragraph:
>>>>> "Explicit routes can be established various
>>>>> ways, e.g., with RSVP-TE [RFC3209], with Segment Routing (SR)
>>>>> [I-D.ietf-spring-segment-routing], via a Software Defined Networking
>>>>> approach [RFC7426], with IS-IS [RFC7813], etc."
>>>>> 
>>>>> New paragraph added:
>>>>>    "Out-of-order packet delivery can be a side effect of distributing a
>>>>>    single flow over multiple paths especially when there is a change
>>>>>    from one path to another when combining the flow.  This is
>>>>>    irrespective of the distribution method used, also applies to service
>>>>>    protection over explicit routes.  As described in Section 3.2.2.1,
>>>>>    out-of-order packets influence the jitter of a flow and impact the
>>>>>    amount of buffering needed to process the data; therefore, DetNet
>>>>>    service includes maximum allowed misordering as a constraint. The
>>>>>    use of explicit routes helps to provide in-order delivery because
>>>>>    there is no immediate route change with the network topology, but the
>>>>>    changes are plannable as they are between the different explicit
>>>>>    routes."
>>>>> 
>>>>> *
>>>>> **4.1.1. Representative Protocol Stack Model*
>>>>> 
>>>>> "Explicit routes" have been added to Figure 2 with the corresponding
>>>>> explanation:
>>>>>  "Explicit routes
>>>>>            The DetNet transport layer provides mechanisms to ensure that
>>>>>            fixed paths are provided for DetNet flows.  These explicit
>>>>>            paths avoid the impact of network convergence."
>>>>> 
>>>>> 
>>>>> Section 4.11 Connected islands vs. networks of v05 has been deleted
>>>>> because it was just a leftover from early drafts on what DetNet WG
>>>>> should do; which are covered by the charter anyways.
>>>>> 
>>>>> 
>>>>> References have been cleaned up and brought up-to-date.
>>>>> 
>>>>> 
>>>>> Refinements have been implemented in the draft according to Lou's
>>>>> detailed comments. They are not listed here because they are minor
>>>>> changes.
>>>>> 
>>>>> 
>>>>> Best regards,
>>>>> Janos
>>>>> 
>>>>> 
>>>>>> On 6/12/2018 2:48 PM, Lou Berger wrote:
>>>>>> Balázs,
>>>>>> 
>>>>>> Thanks for the response -- please see below.
>>>>>> 
>>>>>> ----------
>>>>>> On June 12, 2018 4:07:35 AM Balázs Varga A
>>>>>> <[e-mail]> wrote:
>>>>>> 
>>>>>>> Hi Lou, Thanks for the comments. See reactions inline. Document
>>>>>>> update in progress. Cheers Bala'zs
>>>>>>> 
>>>>>>> -----Original Message-----
>>>>>>> From: detnet <[e-mail]> On Behalf Of Lou Berger
>>>>>>> Sent: 2018. június 1. 22:42
>>>>>>> To: DetNet WG <[e-mail]>;
>>>>>>> [e-mail]
>>>>>>> Subject: [Detnet] Promised comments on draft-ietf-detnet-architecture
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>>      I have a number of high level comments on the document that I'd
>>>>>>> like to  raise below.  I also have a number of more
>>>>>>> editorial/specific comments that  I'd like to review directly with
>>>>>>> the authors and then have them report back  on changes -- if any
>>>>>>> turn out to be more substantive discussions from the  author's
>>>>>>> perspective, I'll raise these on the list separately.
>>>>>>> 
>>>>>> ...
>>>>>>> - WRT Section 4.4.3, I think the inclusion of a distributed control
>>>>>>> plane in the "Network Plane" is inconsistent with other functional
>>>>>>> definitions and conflates where a function resides from the actual
>>>>>>> function and that whether control is implemented in a fully
>>>>>>> centralized, fully distributed or some hybrid form doesn't
>>>>>>> fundamentally change  the control function's role -- therefore I
>>>>>>> think the sections 4.4.2 and .3 should be revised accordingly
>>>>>>> [Balázs Varga A] Agree in principal. Let's discuss the details.
>>>>>>> 
>>>>>> Okay - I'll work with you off line and we can report back the
>>>>>> results/proposed changes.
>>>>>> 
>>>>>>> - In several places it's not clear that DetNet service is always a
>>>>>>> L3 service which is controlled using L3 identifiers, i.e., IP
>>>>>>> addresses -- this is true even in the MPLS service case and the TSN
>>>>>>> over MPLS case. I think this is an important point to be clear on in
>>>>>>> the document.
>>>>>>> [Balázs Varga A] I am not sure. DetNet service is always provided
>>>>>>> over a L3 network (IP or MPLS), that is fine. However the service
>>>>>>> itself can be L2 or L3. In case of TSN Ethernet frames are
>>>>>>> transported, so it is a L2 service. In case of IP end systems IP
>>>>>>> packets are transported so it is a L3 service.
>>>>>>> 
>>>>>> Humm - While I agree that DetNet is providing an (enhanced) L2VPN
>>>>>> service, it is not itself providing control or service of L2 devices
>>>>>> -- this is TSN's job.  The fact that DetNet is all about behavior of
>>>>>> L3 nodes (i.e., IP and PW/MPLS) and not L2 nodes (i.e., TSN bridges)
>>>>>> is something the architecture should make unambiguous.
>>>>>> 
>>>>>> Thanks,
>>>>>> Lou
>>>>>> 
>>>>>>> Please let me know what you think.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> 
>>>>>>> Lou
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>>>> _______________________________________________
>>>>>>> detnet mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/detnet
>>>>> 
>>>>> 
>>>>>> On 6/12/2018 6:27 PM, Stewart Bryant wrote:
>>>>>> Dear Bala'zs
>>>>>> 
>>>>>> Thank you your for your consideration of these points. I will just
>>>>>> pick up a few that need some further thought:
>>>>>> 
>>>>>> 
>>>>>>>     DetNet transit node
>>>>>>> 
>>>>>>>            A node operating at the DetNet transport layer, that utilizes
>>>>>>> 
>>>>>>>            link layer and/or network layer switching across multiple
>>>>>>> 
>>>>>>>            links and/or sub-networks to provide paths for DetNet service
>>>>>>> 
>>>>>>>            layer functions. Optionally provides congestion protection
>>>>>>> 
>>>>>>>            over those paths.  An MPLS LSR is an example of a DetNet
>>>>>>> 
>>>>>>>            transit node.
>>>>>>> 
>>>>>>> SB> In that example it would have to be a DetNet enable/aware LSR. An
>>>>>>> 
>>>>>>> SB> ordinary LSR would not know anything about DetNet.
>>>>>>> 
>>>>>>> [Balázs Varga A] No, A DetNet aware LSR would be a relay node (S-PE).
>>>>>>> 
>>>>>> I think the confusion is what "DetNet Transport Layer" means. This
>>>>>> technology touches on Transport Layer in  the L4 sense, and the
>>>>>> Transport Network Layer as in the packet network that carries
>>>>>> L3 packets.
>>>>>> 
>>>>>> So I think that we need to clarify whether a DetNet transit node
>>>>>> is an S-PE (i.e. a a transit node in the DetNet layer), or a P node
>>>>>> (i.e. a transit node that is carrying DetNet packets but could be
>>>>>> carrying any sort of MPLS packet)
>>>>>> 
>>>>>>> ============
>>>>>>> 
>>>>>>>    These three techniques can be applied independently, giving eight
>>>>>>> 
>>>>>>>    possible combinations, including none (no DetNet), although some
>>>>>>> 
>>>>>>>    combinations are of wider utility than others.  This separation keeps
>>>>>>> 
>>>>>>>    the protocol stack coherent and maximizes interoperability with
>>>>>>> 
>>>>>>>    existing and developing standards in this (IETF) and other Standards
>>>>>>> 
>>>>>>>    Development Organizations.  Some examples of typical expected
>>>>>>> 
>>>>>>>    combinations:
>>>>>>> 
>>>>>>>    o  Explicit routes plus service protection are exactly the techniques
>>>>>>> 
>>>>>>>       employed by [HSR-PRP]. Explicit routes are achieved by limiting
>>>>>>> 
>>>>>>>       the physical topology of the network, and the sequentialization,
>>>>>>> 
>>>>>>>       replication, and duplicate elimination are facilitated by packet
>>>>>>> 
>>>>>>>       tags added at the front or the end of Ethernet frames.
>>>>>>> 
>>>>>>> SB> ER can be done virtually as well as physically. RSVP is a type of
>>>>>>> 
>>>>>>> SB> ER, as is Adj-SID based SR, and we can design other types.
>>>>>>> 
>>>>>>> [Balázs Varga A] Agree, but these are examples. Statement is for
>>>>>>> HSR-PRP.
>>>>>>> 
>>>>>> So the question is whether we should expand the set of examples,
>>>>>> particularly
>>>>>> to more accessible ones.
>>>>>> 
>>>>>> ============
>>>>>>>                     Packet replication and elimination
>>>>>>> 
>>>>>>>>>>>>>>>> relay > > > > > > > >
>>>>>>>> /------------+ R node E +------------\ >
>>>>>>>> /                  v + ^               \ >
>>>>>>>       end    R +                   v | ^                + E end
>>>>>>> 
>>>>>>>       system   +                   v | ^                +   system
>>>>>>> 
>>>>>>>> \                  v + ^               / >
>>>>>>>> \------------+ R relay E +-----------/ >
>>>>>>>>>>>>>>>>   node > > > > > > > >
>>>>>>> Figure 1
>>>>>>> 
>>>>>>>    Packet replication and elimination does not react to and correct
>>>>>>> 
>>>>>>>    failures; it is entirely passive.  Thus, intermittent failures,
>>>>>>> 
>>>>>>> SB> I think it copes with intermittent failures OK.
>>>>>>> 
>>>>>>> [Balázs Varga A] Yes, PRF and PEF can eliminate the effect of such
>>>>>>> failures. But text
>>>>>>> 
>>>>>>> intends to say that it is passive. It is not reacting to such
>>>>>>> failures. No change in text.
>>>>>>> 
>>>>>> You say that PREF does not correct failures. I would contend that is
>>>>>> exactly
>>>>>> what it does. Sure it does not react but it does correct, and it does
>>>>>> address intermittent failures.
>>>>>>> ===========
>>>>>>> 
>>>>>>>    transported between the peer end systems.  Therefore, the following
>>>>>>> 
>>>>>>>    possible types / formats of a DetNet flow are distinguished in this
>>>>>>> 
>>>>>>>    document:
>>>>>>> 
>>>>>>>    o  App-flow: native format of a DetNet flow.  It does not contain any
>>>>>>> 
>>>>>>>       DetNet related attributes.
>>>>>>> 
>>>>>>>    o  DetNet-t-flow: specific format of a DetNet flow.  Only requires
>>>>>>> 
>>>>>>>       the congestion / latency features provided by the Detnet transport
>>>>>>> 
>>>>>>>       layer.
>>>>>>> 
>>>>>>>    o  DetNet-s-flow: specific format of a DetNet flow.  Only requires
>>>>>>> 
>>>>>>>       the replication/elimination feature ensured by the DetNet service
>>>>>>> 
>>>>>>>       layer.
>>>>>>> 
>>>>>>>    o  DetNet-st-flow: specific format of a DetNet flow.  It requires
>>>>>>> 
>>>>>>>       both DetNet service layer and DetNet transport layer functions
>>>>>>> 
>>>>>>>       during forwarding.
>>>>>>> 
>>>>>>> SB> I find the relisting of these types confusing. Wheren't they
>>>>>>> defined
>>>>>>> 
>>>>>>> SB> in the section above?
>>>>>>> 
>>>>>>> [Balázs Varga A] This is inline with the previous section " Grouping
>>>>>>> of end systems ".
>>>>>>> 
>>>>>> Surely if we have defined them we never need to do anything but name
>>>>>> them in
>>>>>> later sections. Redefinition is never a good idea because it often
>>>>>> leads to
>>>>>> conflicting definitions.
>>>>>> 
>>>>>>> ============
>>>>>>> 
>>>>>>>    [HSR-PRP]  IEC, "High availability seamless redundancy (HSR) is a
>>>>>>> 
>>>>>>>               further development of the PRP approach, although HSR
>>>>>>> 
>>>>>>>               functions primarily as a protocol for creating media
>>>>>>> 
>>>>>>>               redundancy while PRP, as described in the previous
>>>>>>> 
>>>>>>>               section, creates network redundancy.  PRP and HSR are both
>>>>>>> 
>>>>>>>               described in the IEC 62439 3 standard.",
>>>>>>> 
>>>>>>>               <http://webstore.iec.ch/webstore/webstore.nsf/
>>>>>>> 
>>>>>>> artnum/046615!opendocument>.
>>>>>>> 
>>>>>>> SB> Not available at the time of this review, but my recollection is
>>>>>>> 
>>>>>>> SB> that this is not readily available without paying a large fee.
>>>>>>> 
>>>>>> If we decide that this is essential as a key reference, there needs to be
>>>>>> some suitable text, as this will get raised a number of times between
>>>>>> here an publication as first the directorates and then the ADs run
>>>>>> into this.
>>>>>> 
>>>>>>> ===========
>>>>>>> 
>>>>>>>    [ISA95]    ANSI/ISA, "Enterprise-Control System Integration Part 1:
>>>>>>> 
>>>>>>>               Models and Terminology", 2000,
>>>>>>> 
>>>>>>>               <https://www.isa.org/isa95/>.
>>>>>>> 
>>>>>>> SB> Should that be 2000, or 2010.
>>>>>>> 
>>>>>>> SB> Note that this seems to be a very expensive document to access.
>>>>>>> 
>>>>>> You did not comment on the correctness of the reference.
>>>>>> Best Regards
>>>>>> 
>>>>>> Stewart
>>>> _______________________________________________
>>>> detnet mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/detnet
>>> _______________________________________________
>>> detnet mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/detnet
>> _______________________________________________
>> detnet mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/detnet
>