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

[Lou Berger <[e-mail]>]

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 <[e-mail] <mailto:[e-mail]>>
> Date: Friday, July 8, 2016 at 13:10 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
>
>     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]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>                 _______________________________________________
>                 Detnet-dp-dt mailing list
>                 [e-mail]://www.ietf.org/mailman/listinfo/detnet-dp-dt
>
>
>
>
> _______________________________________________
> Detnet-dp-dt mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt