Re: [Detnet-dp-dt] New architecture draft

["Norman Finn (nfinn)" <[e-mail]>]

Ahhhh yes.  There was one other possible use for a “transit edge node":  Without any sequencing or elimination, there was the function of protecting reservations from mislabeled traffic and shaping and/or policing incoming critical streams to make sure they can’t mess up other streams.

Still, more people have put more thought into the dp-alt doc, so I’ll go with that usage, for this rev, and cut out transit edge node.

— Norm

From: Norman Finn <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 8, 2016 at 13:06 PM
To: Norman Finn <[e-mail]<mailto:[e-mail]>>, János Farkas <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet-dp-dt] New architecture draft

Forgot,

DetNet transport edge node (should have been DetNet transit edge node):

If the end system provides the sequencing with an 802.1CB tag, and the transit node converts that to a pseudowire, that was my idea of a DetNet transit edge node.  Obviously, that wasn’t clear.  As I think about it, that would probably be better described as a relay edge node, because even though it doesn’t alter any sequence numbers, it certainly changes their form and messes around at the sequence numbering layer.

I’l remove it.

— Norm

From: Detnet-dp-dt <[e-mail]<mailto:[e-mail]>> on behalf of Norman Finn <[e-mail]<mailto:[e-mail]>>
Date: Friday, July 8, 2016 at 13:01 PM
To: János Farkas <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet-dp-dt] New architecture draft

János,

I’d like to get these things aligned.

See in-line

From: Detnet-dp-dt <[e-mail]<mailto:[e-mail]>> on behalf of János Farkas <[e-mail]<mailto:[e-mail]>>
Date: Thursday, July 7, 2016 at 09:58 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [Detnet-dp-dt] New architecture draft

Hi,

I've also found some differences that may be confusing.

The architecture draft defines:

DetNet intermediate node
           A DetNet relay node or transport node.

DetNet transport 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.  An MPLS LSR is an example of a DetNet
           transport node.

Whereas "transport node" is not used in the data plane draft.
Instead, the data plane draft defines:
Transit Node
A node that provides link layer and network layer switching across
multiple links and/or sub-networks. An MPLS LSR is an example of
a transit node.

I’m good with that.  The transit node operates in the transport layer.  I gave them the same name.  I’ll  make it right, if Pascal has not, already.

The architecture draft defines:

   DetNet relay edge node
           An instance of a DetNet relay node that includes a service
           layer (packet sequencing and/or elimination) proxy function
           for one or more end systems, analogous to a Label Edge Router
           (LER).

   DetNet transport edge node
           An instance of a DetNet transport node that includes a
           transport layer (DetNet flow encapsulation, splitting and/or
           merging) proxy function for one or more end systems, for
           example, a Label Edge Router (LER).

Do we have DetNet transport edge node? Isn't each DetNet edge node is a DetNet relay edge node?

The data plane draft says at the moment:
Edge Node
A relay node with application level knowledge (i.e., basically a
"proxy" node). Egde nodes are needed when interfacing with nodes
or end systems that are not DetNet-enabled.



The data plane draft says:
Transit Node
A node that provides link layer and network layer switching across
multiple links and/or sub-networks. An MPLS LSR is an example of
a transit node.

The architecture draft says:
relay node
           A DetNet service layer function that interconnects different
           DetNet transport layer protocols or networks (instances) to
           perform packet replication and elimination (Section 3.4.  May
           be a router, transit node, bridge, Label Switch Router (LSR),
           firewall, or any other system that participates in the DetNet
           service layer.  A DetNet relay node typically incorporates
           DetNet transport layer functions, as well.

Should be "transit node" and LSR removed from the definition of relay node in the architecture draft?
(My understanding from the call yesterday and from the data plane draft is that a relay node is rather a LER than an LSR.)

Kept some old text, there.  A relay node can’t be those things; it just resides in the same box.  Will trim down to match dp-alt more closely.

In the data plane draft, the criteria relevant for the Service and dor the Transport layer are collected in Section 4. IT has been discussed a lot and what we have at the moment is:

for the Service layer:
#5 Packet replication and elimination (note: only the packet deletion
for seamless redundancy)

for the Transport layer
#5 Packet replication and elimination (note: only the packet
replication and/or flow merging for seamless redundancy)
The architecture draft says:

DetNet service layer
           The layer at which packet replication and elimination
           (Section 3.4) is performed.

DetNet transport layer
           The layer that splits and merges Detnet flows for packet
           replication and elimination (Section 3.4).

  1.  Please get rid of the term “seamless redundancy” (: not necessarily right now :)  I took it out of the architecture document because ISO/IEC 62439-3 kind of owns that term.

  2. The DetNet service layer definition in the architecture should NOT say packet replication, but can say packet sequencing and elimination.  I think that fixes the gross difference.

I guess the two drafts could be better synchronized.
One key difference is that packet replication is considered as part of the Service layer in the Architecture draft whereas it is part of the Transport layer in the data plane draft.

At the moment, maybe the easiest way to delete these from the architecture draft? (Actually the Service and Transport layers are distinguished for other purposes too.)

The data plane draft said yesterday:
[I-D.finn-detnet-architecture] does not specify the relationship
between layers.
which I've just suggested to update to
[I-D.finn-detnet-architecture] does not specify the relationship
between the DetNet Service and Transport layers used in this document
to investigate data plane options as explained in the following.

In any case, I guess we should get rid of "seamless redundancy" from the data plane draft as the architecture uses "packet replication and elimination" instead.
I guess we should update the data plane draft to

The two referred bullets of Section 4 could be updated to:

for the Service layer:
#5 Packet elimination for packet replication and elimination (see Section 3.4 in Architecture)

for the Transport layer
#5 Packet replication and splits and merges of DetNet flows for packet replication and elimination (see Section 3.4 in Architecture)

If you have time, I’d say #5 packet sequencing (if needed) and packet elimination ...


nits on the architecture draft

all kinds of nodes are defined as "DetNet xy node" except for "relay node" which has no DetNet in its name but the definition itself begins with DetNet. Maybe it could be renamed to "DetNet relay node" and the definition could be moved next to "DetNet relay edge node" to show the specialty of edge.


 DetNet node
           A DetNet aware end system, transport node, or relay node.
           "DetNet" may be omitted in some text.

It may be confusing to have "end system here.
However,, I understand that an end system is a DetNet relay node e.g., the right hand side end system in Fig 1 of data plane.
Unfortunately, I have no resolution at hand.


Regards,
Janos



On 7/6/2016 9:11 PM, Lou Berger wrote:

Norm,

    I think there are still some mismatches between what Jouni is
working on and this document.  Do you have time to discuss today? or
tomorrow am?  What's the best way to get you comments on other sections?

Lou


On 7/6/2016 2:49 PM, Norman Finn (nfinn) wrote:


Uploaded it to bitbucket.  Here’s a link to the text in dropbox.

https://www.dropbox.com/s/9kc1ingqtnwgb49/draft-finn-detnet-architecture-05
.txt?dl=0

Big differences are the simplified stack diagram and terminology revised
to better match dp-alt, in accordance with last two dial-in meetings.

— Norm

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/detnet-dp-dt

_______________________________________________
Detnet-dp-dt mailing list
[e-mail]<mailto:[e-mail]>https://www.ietf.org/mailman/listinfo/detnet-dp-dt