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

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Wed, 6 Jul 2016 18:49:11 +0000

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

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 6 Jul 2016 11:52:10 -0700

Great. Thanks.

- Jouni

On Wed, Jul 6, 2016 at 11:49 AM, Norman Finn (nfinn) <[email-masked]>
wrote:

> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

-- 
Jouni Korhonen, Broadcom Ltd.

---

From: Lou Berger <[email-masked]>
Date: Wed, 6 Jul 2016 15:11:41 -0400

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

---

From: János Farkas <[email-masked]>
Date: Thu, 7 Jul 2016 18:58:59 +0200

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.

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.)

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).

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)

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

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 7 Jul 2016 10:15:02 -0700

See inline.

On Thu, Jul 7, 2016 at 9:58 AM, János Farkas <[email-masked]>
wrote:

> multiple links and/or sub-networks. An *MPLS LSR* is an example of
> a transit node.
>
>            be a router, *transit node*, bridge, *Label Switch Router
> (LSR)*,
> Should be "transit node" and LSR removed from the definition of relay node
> in the architecture draft?
>

​At least LSR part. A relay can operate as a transit node if so configured
but in that case it would appear in the network as "just a transit" node as
well.​

(My understanding from the call yesterday and from the data plane draft is
> that a relay node is rather a LER than an LSR.)
>

​Yes.​

>
>
> 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:
> 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.)
>

​Ok with the intention of this change. I might reword it a bit, though.​

> data plane draft as the architecture uses "packet replication and

​Ok at least in the criteria descriptions.​

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

​OK with the intention of this change. ​

​
 I might reword it a bit, though.​
​
​​

- Jouni

> 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
> 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.
> Detnet-dp-dt mailing [email-masked]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
> Detnet-dp-dt mailing [email-masked]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 7 Jul 2016 13:17:21 -0400

I think we *really* need to align the architecture draft with the design
team draft ASAP.

Norm/Pascal,

is this possible to do before tomorrow's deadline?  I'm happy to help
edit if you want?

Lou

On 7/7/2016 12:58 PM, János Farkas wrote:
> Do we have DetNet transport edge node? Isn't each DetNet edge node is
> a DetNet relay edge node?
>
>            be a router, /*transit node*/, bridge, /*Label Switch
> Router (LSR)*/,
> (My understanding from the call yesterday and from the data plane
> draft is that a relay node is rather a LER than an LSR.)
>
>
> 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:
> 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.
>

---

From: Lou Berger <[email-masked]>
Date: Thu, 7 Jul 2016 14:53:18 -0400

Norm,

    In addition to the terminology, I have the following suggestions:

OLD

4.6.  Protocol Stack Model
    Figure 3 illustrates the DetNet data plane layering model. 
NEW
4.6.  Representative Protocol Stack Model
    Figure 3 illustrates a conceptual DetNet data plane layering model.

OLD
           number for packet replication and elimination (Section 3.4)
NEW
           number for providing DetNet reliability via packet
replication and elimination (Section 3.4)

OLD
           As part of the DetNet service layer, based on the sequenced
NEW
           As part of DetNet reliability, based on the sequenced

OLD
     As part of the DetNet network layer
NEW
     As part of DetNet reliability

OLD
   Whether a distributed alternative without a PCE can be valuable
   should be studied as well.  Such an alternative could for instance
   inherit from the Resource ReSerVation Protocol [RFC3209] (RSVP-TE)
   flows.
NEW
    Significant work on distributed path setup can be leveraged from
MPLS Traffic Engineering, in both its GMPLS and non-GMPLS forms.  The
protocols within scope are Resource Reservation Protocol with Traffic
Engineering (RSVP-TE) [RFC3209] [RFC3473], OSPF-TE [RFC4203] [RFC5392], 
and ISIS-TE [RFC5307] [RFC5316].  These should be viewed as starting
points as there are feature specific extensions defined that may be
applicable to DetNet.

Lou

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jul 2016 12:10:38 +0000

I pushed those changes to the bitbucket repo, Lou.

Thanks for all!

Pascal

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou
> Berger
> Sent: jeudi 7 juillet 2016 20:53
> To: Norman Finn (nfinn) <[email-masked]>; [email-masked]
> Subject: Re: [Detnet-dp-dt] New architecture draft
> 
> Norm,
> 
>            number for packet replication and elimination (Section 3.4) NEW
>            number for providing DetNet reliability via packet replication and
> elimination (Section 3.4)
> 
> OLD
>            As part of the DetNet service layer, based on the sequenced NEW
>      As part of the DetNet network layer NEW
>     Significant work on distributed path setup can be leveraged from MPLS Traffic
> Engineering, in both its GMPLS and non-GMPLS forms.  The protocols within
> scope are Resource Reservation Protocol with Traffic Engineering (RSVP-TE)
> [RFC3209] [RFC3473], OSPF-TE [RFC4203] [RFC5392], and ISIS-TE [RFC5307]
> [RFC5316].  These should be viewed as starting points as there are feature
> specific extensions defined that may be applicable to DetNet.
> 
> Lou
> 
> > Big differences are the simplified stack diagram and terminology
> > revised to better match dp-alt, in accordance with last two dial-in meetings.
> >
> > — Norm
> >

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jul 2016 12:37:41 +0000

Related:

Do you think we need to publish 06 for these updates?
Should we sync the pictures in the DT doc into the architecture?

Cheers,

Pascal

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> Pascal Thubert (pthubert)
> Sent: vendredi 8 juillet 2016 14:11
> To: Lou Berger <[email-masked]>; Norman Finn (nfinn) <[email-masked]>;
> [email-masked]
> > From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> > Lou Berger
> > Engineering (RSVP-TE) [RFC3209] [RFC3473], OSPF-TE [RFC4203]
> > [RFC5392], and ISIS-TE [RFC5307] [RFC5316].  These should be viewed as
> > starting points as there are feature specific extensions defined that may be
> applicable to DetNet.
> >
> > Lou
> >
> > > https://www.dropbox.com/s/9kc1ingqtnwgb49/draft-finn-detnet-architec
> > > tu
> > > re-05
> > > .txt?dl=0
> > >

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Jul 2016 08:58:24 -0400

Thank you!

---

From: Lou Berger <[email-masked]>
Date: Fri, 08 Jul 2016 09:00:55 -0400

Pascal,

Getting the arch and dt docs as in sync as possible before the meeting will 
be helpful.

Either way, I think publishing the most current version before today's 
cutoff is important - even if it's just the updates you have made so far.

Thank you!!!

Lou

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 8 Jul 2016 19:24:36 +0000

Anyone can call me at +1-925-980-6430.  I’ll make sure that all the stuff
is in sync and that Lou’s comments are in there (thanks, Pascal) and will
officially upload -06.

THANK YOU for making it better.

— Norm

-----Original Message-----
From: Lou Berger <[email-masked]>
Date: Friday, July 8, 2016 at 06:00 AM
To: Pascal Thubert <[email-masked]>, Norman Finn <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: RE: [Detnet-dp-dt] New architecture draft

>>> > > revised to better match dp-alt, in accordance with last two
>>>dial-in 
>>> meetings.
>>> > >
>>> > > — Norm
>>> > >

---

From: Lou Berger <[email-masked]>
Date: Fri, 8 Jul 2016 15:29:00 -0400

Norm,

    Thank you.  To echo Pat's point - it's time to upload (it's almost
19:30 UTC).  Better to capture what you have than to miss the deadline.

Thank you again!

Lou

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 8 Jul 2016 20:01:30 +0000

János,

I’d like to get these things aligned.

See in-line

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

Hi,

DetNet intermediate node

DetNet transport 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.

   DetNet relay edge node

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

           be a router, transit node, bridge, Label Switch Router (LSR),

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:

for the Transport layer

DetNet service layer

DetNet transport layer

  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.)

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

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

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

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

Norm,

Lou

— Norm

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

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

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 8 Jul 2016 20:06:50 +0000

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 <[email-masked]<mailto:[email-masked]>> on behalf of Norman Finn <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 8, 2016 at 13:01 PM
To: János Farkas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet-dp-dt] New architecture draft

János,

See in-line

Hi,

DetNet intermediate node

DetNet transport node

   DetNet relay edge node

for the Service layer:

for the Transport layer

DetNet service layer

DetNet transport layer

for the Service layer:

for the Transport layer

 DetNet node

Regards,
Janos

Norm,

Lou

— Norm

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 8 Jul 2016 20:10:55 +0000

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 <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 8, 2016 at 13:06 PM
To: Norman Finn <[email-masked]<mailto:[email-masked]>>, János Farkas <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Detnet-dp-dt] New architecture draft

Forgot,

I’l remove it.

— Norm

János,

See in-line

Hi,

DetNet intermediate node

DetNet transport node

   DetNet relay edge node

for the Service layer:

for the Transport layer

DetNet service layer

DetNet transport layer

for the Service layer:

for the Transport layer

 DetNet node

Regards,
Janos

Norm,

Lou

— Norm

---

From: "Norman Finn (nfinn)" <[email-masked]>
Date: Fri, 8 Jul 2016 21:09:46 +0000

Made some small changes, as indicated in email threads.  Left out transit edge node; it can come back if needed.  Did change “DetNet reliability” to “DetNet loss prevention”.  Made more of a deal about replication/elimination is just the best-explored form of loss prevention, but more will be needed there, both to make that more clear, and to examine viable alternatives.

In bitbucket as -06, uploaded to datatracker, clicked on the email, and verified it’s there on the DetNet WG page.

— Norm

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

— Norm

Forgot,

I’l remove it.

— Norm

János,

See in-line

Hi,

DetNet intermediate node

DetNet transport node

   DetNet relay edge node

for the Service layer:

for the Transport layer

DetNet service layer

DetNet transport layer

for the Service layer:

for the Transport layer

 DetNet node

Regards,
Janos

Norm,

Lou

— Norm

---

From: Lou Berger <[email-masked]>
Date: Fri, 8 Jul 2016 17:20:13 -0400

Thanks Norm!!! (and Pascal)

On 7/8/2016 5:09 PM, Norman Finn (nfinn) wrote:
> Made some small changes, as indicated in email threads.  Left out
> transit edge node; it can come back if needed.  Did change “DetNet
> reliability” to “DetNet loss prevention”.  Made more of a deal about
> replication/elimination is just the best-explored form of loss
> prevention, but more will be needed there, both to make that more
> clear, and to examine viable alternatives.
>
> In bitbucket as -06, uploaded to datatracker, clicked on the email,
> and verified it’s there on the DetNet WG page.
>
> — Norm
>
> From: Norman Finn <[email-masked] <mailto:[email-masked]>>
> To: Norman Finn <[email-masked] <mailto:[email-masked]>>, János
> Farkas <[email-masked] <mailto:[email-masked]>>,
> "[email-masked] <mailto:[email-masked]>"
> <[email-masked] <mailto:[email-masked]>>
>     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 <[email-masked] <mailto:[email-masked]>>
>     To: Norman Finn <[email-masked] <mailto:[email-masked]>>, János
>     Farkas <[email-masked]
>     <mailto:[email-masked]>>, "[email-masked]
>     <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>         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 <[email-masked]
>         <mailto:[email-masked]>> on behalf of Norman
>         Finn <[email-masked] <mailto:[email-masked]>>
>         To: János Farkas <[email-masked]
>         <mailto:[email-masked]>>, "[email-masked]
>         <mailto:[email-masked]>" <[email-masked]
>         <mailto:[email-masked]>>
>             From: Detnet-dp-dt <[email-masked]
>             <mailto:[email-masked]>> on behalf of János
>             Farkas <[email-masked]
>             <mailto:[email-masked]>>
>             To: "[email-masked] <mailto:[email-masked]>"
>             <[email-masked] <mailto:[email-masked]>>
>             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.
>
>                 Do we have DetNet transport edge node? Isn't each
>                 DetNet edge node is a DetNet relay edge node?
>
>                            be a router, /*transit node*/, bridge,
>                 /*Label Switch Router (LSR)*/,
>                 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:
>              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.
>
>                 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
>                 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.)
>
>                 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.
>                 #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
>                 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
>                 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.
>>                 [email-masked]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>                 [email-masked]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 8 Jul 2016 22:30:37 +0000

😊

Regards,

Pascal

Le 8 juil. 2016 à 23:09, Norman Finn (nfinn) <[email-masked]<mailto:[email-masked]>> a écrit :

— Norm

— Norm

Forgot,

I’l remove it.

— Norm

János,

See in-line

Hi,

DetNet intermediate node

DetNet transport node

   DetNet relay edge node

for the Service layer:

for the Transport layer

DetNet service layer

DetNet transport layer

for the Service layer:

for the Transport layer

 DetNet node

Regards,
Janos

Norm,

Lou

— Norm

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