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

[Stewart Bryant <[e-mail]>]

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