Subject: Re: [Detnet-dp-dt] Relay vs Transit

From: Jouni Korhonen <[email-masked]>
Date: Fri, 1 Jul 2016 13:09:44 -0700

A quick question.. I am not quite sure about the description for "DetNet 
Transport". It reads to me like just a "function", which does not imply 
necessarily any additional headers/excapsulation on wire. Is this a 
correct interpretation?

- Jouni

6/30/2016, 9:51 PM, Lou Berger kirjoitti:
> Wednesday's discussion was very enlightening, at least to me. I had
> previously been reading the definition of relay node fairly literally
> based on the architecture doc:
>
>    relay node
>            A router, transit node, bridge, Label Switch Router (LSR),
>            firewall, or any other system that forwards packets from one
>            interface to another.
>
> Which to me is a typical transit/intermediate node/router/LSR, or just
> transit node for short. That is, it provided functions that would
> normally be expected from the underlying Network layer, e.g., IP or MPLS
> with appropriate QoS mechanisms.
>
> Jouni's comment on other ietf usage of relays brought in a completely
> different perspective, where relays are application aware functions that
> reside in the network.  Examples of such relays include DHCP relays and
> (IMO) S-PEs in multi-segment pseudo wires.  The important distinction
> here is that (IETF) relay nodes include application/service aware functions.
>
> Looking at the layering in the DP document we have
>
> +-----------+
> |  Service  | PW, RTP, UDP, GRE
> ~~~~~~~~~~~~~
> | Transport | IPv6, IPv4, MPLS LSPs, BIER, BIER-TE
> +-----------+
>
> I don't think this maps so well into the three concepts we now have of
> end to end service, relay nodes (which may provide DetNet reliability)
> and, transit nodes.  Perhaps it would be better to include three layers:
>
> +-----------+
> |  Service  | Detnet Service: PW, RTP, UDP, GRE
> ~~~~~~~~~~~~~
> | Transport | DetNet Transport: e.g., replication/elimination
> ~~~~~~~~~~~~~                                or network coding
> |  Network  | IPv6, IPv4, MPLS LSPs, BIER, BIER-TE
> +-----------+
>
> Which in a network look like
>
>    +---------+                                           +---------+
>    | Service |                                           | Service |
>    +~~~~~~~~~+                +~~~~~~~~~+                +~~~~~~~~~+
>    |Transport|                |Transport|                |Transport|
>    +~~~~~~~~~+   +~~~~~~~~~+  +~~~~~~~~~+  +~~~~~~~~~+   +~~~~~~~~~+
>    | Network |---| Network |--| Network |--| Network |---| Network |
>    +---------+   +---------+  +---------+  +---------+   +---------+
>        End         Transit       Relay       Transit          End
>      System         Node         Node         Node          System
>
>
> Keep in mind that the links interconnecting the network layers are
> composed of NICs and other subnetworking technologies, e.g., 802.1 TSN.
> If we include these, the more complex figure is
>
>  +---------+                                           +---------+
>  | Service | <------- End to End DetNet Service -----> | Service |
>  +~~~~~~~~~+                +~~~~~~~~~+                +~~~~~~~~~+
>  |Transport|                |Transport|                |Transport|
>  +~~~~~~~~~+   +~~~~~~~~~+  +~~~~~~~~~+  +~~~~~~~~~+   +~~~~~~~~~+
>  | Network |   | Network |  |Net| |Net|  | Network |   | Network |
>  +-------.-+   +-.--.----+  +--.+ +-.-+  +--.---.---+   +---.----+
>          | Link  |  |  ,-----.  \   | Link  |   |  ,-----.  |
>          .........  +-[  Sub  ]-+   .........   +-[  Sub  ]-+
>                       [Network]                   [Network]
>                        `-----'                     `-----'
>      End         Transit       Relay       Transit          End
>    System         Node         Node         Node          System
>
> So I suggest we keep the terms:
> - Detnet Service	
> 	Provides end to end mechanisms needed to deliver a Detnet flow
>
> - DetNet Transport
> 	Provides mechanisms to support a Detnet flow across a
> 	particular network technology, e.g., IP or MPLS.
>
> - Network layer (protocol)
> 	Encapsulation, forwarding and QoS-related mechanisms for a
> 	particular network technology, e.g., IP or MPLS.
>
> - Link
> 	A dedicated set of resources interconnecting two nodes
>
> - Sub-Network
> 	A switched infrastructure interconnecting a collection of
> 	nodes, e.g., 802.1 TSN or OTN.
>
> - End station
> 	A device that supports a DetNet Service end point
>
> - Relay node
> 	A DetNet Service aware middle box that interconnects different
> 	network layer protocols or networks (instances). It may provide
> 	service supporting functions such as  DetNet reliability.
>
> - Transit node
> 	A node that provide network layer switching across multiple
> 	links and/or sub-networks, e.g., and MPLS LSR.
>
> - DetNet reliability function
> 	A set of mechanisms to increase the probability of lossless
> 	DetNet flow transport across a network. Example mechanisms
> 	include replication/elimination and network coding.
>
> There are still more terms, e.g., DetNet flow, but I'm out of steam.
> What do people think?
>
> Lou
>
>
>
>
> _______________________________________________
> Detnet-dp-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt
>

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 1 Jul 2016 13:39:36 -0700

In general I am fine with this. I find the latter network picture very 
informative. I just do not like the "DetNet reliability function". Why 
that needs to be called out explicitly?

Anyway, I am holding my further editing on the DP draft until there are 
more voices than just me.

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Fri, 1 Jul 2016 16:56:24 -0400

I didn't want to preclude new headers here, for example if network
coding used there certainly will be added headers...

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 1 Jul 2016 13:58:52 -0700

So the interpretation was kind of correct. It does not necessarily imply 
but does preclude either added headers.

- Jouni

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Jul 2016 12:49:59 +0000

Dear all

We need to agree on this picture and move it to the architecture. 
People will probably not be that surprised, since the relays there look like proxies in a traditional 5-layers architecture. 

And I agree we must  be extra careful on terms like relay.

Note that a gateway is intelligent, and a proxy may be too, whereas a relay if more of a Layer-X forwarding thing, passing the request further in the network because the original request could not reach there, for, say, scope reasons. The relay does not impersonate the original requester.

If we are talking signaling, how to propagate a path setup between domains, then the term relay may be appropriate.

But I think the original intent for relay was really a layer (and SDO) -  independent abstraction for a forwarding engine. If we are talking about the data path, connecting a detnet domain with another and piping a tunnel into another above the service layer, then gateway may be better.

If so, maybe the use of the term relay was confusing at the IETF and another term like forwarding engine should be considered? 

Pascal

> -----Original Message-----
> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou
> Berger
> Sent: vendredi 1 juillet 2016 06:51
> To: [email-masked]
> Subject: [Detnet-dp-dt] Relay vs Transit
> 
> Wednesday's discussion was very enlightening, at least to me. I had previously
> been reading the definition of relay node fairly literally based on the architecture
> doc:
> 
>    relay node
> Which to me is a typical transit/intermediate node/router/LSR, or just transit
> node for short. That is, it provided functions that would normally be expected
> from the underlying Network layer, e.g., IP or MPLS with appropriate QoS
> mechanisms.
> 
> Jouni's comment on other ietf usage of relays brought in a completely different
> perspective, where relays are application aware functions that reside in the
> network.  Examples of such relays include DHCP relays and
> (IMO) S-PEs in multi-segment pseudo wires.  The important distinction here is
> that (IETF) relay nodes include application/service aware functions.
> 
> I don't think this maps so well into the three concepts we now have of end to
> end service, relay nodes (which may provide DetNet reliability) and, transit
> nodes.  Perhaps it would be better to include three layers:
> 
> +-----------+
> Keep in mind that the links interconnecting the network layers are composed of
> NICs and other subnetworking technologies, e.g., 802.1 TSN.

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 4 Jul 2016 16:32:49 +0000

Hi Lou and All,

I agree that defining a relay node for DetNet could help to sort out terminology and I like Lou' example
("Examples of such relays ... (IMO) S-PEs in multi-segment pseudo wires."). I think S-PE implements a
very similar function for PWs what we envision for nodes with DetNet functionalities along the forwarding
path.

However I have some issues with the definitions below:

- Relay node

        service supporting functions such as  DetNet reliability.
If we use this definition than IMO all nodes must be "relay node" in the figure below as the transit nodes of the figure
"interconnects different networks" (they are connected to a sub-network!).

 +---------+                                           +---------+

                      [Network]                   [Network]

                       `-----'                     `-----'

I have also found somewhat strange that we have no edge nodes on the figure, but that can be scenario specific,
as the figure shows a scenario where DetNet service starts in the end-host (if I read it correctly).

My intention is to keep layering and definitions as simple as possible. The original intention of the introduction of the
two layers was just to group the data plane protocols and show that only their combination can fulfill the requirements
of DetNet.

So, let's group DetNet related functions and parameters to find out the root of our difficulties in terminology.

We have three DetNet functions:
1, Zero congestion loss (proper queuing),
2, Explicit path (static forwarding),
3, Packet-level reliability (replication, merging, elimination)
The main question for implementing DetNet functions: Q1 - What services are provided by the underlying data plane layer(s)?
The more service the underlying layers provide, the less DetNet specific modification is needed for transport/relay nodes.
(E.g., if p2mp LSPs are provided than we may use it for "replication" and not implement a similar DetNet function ...)

We have two DetNet data flow related attributes:
A, Flow-ID and
B, Sequence number.
The main question regarding the attributes are: Q2 - What part of the encapsulation should be used to encode the attributes?
These attributes are local to DetNet nodes and are extracted from the ingress packets of the node. Flow-ID
is used by all the three DetNet functions, but sequence number is used only by the duplicate elimination functionality.

These two questions have a common thing: the answer depends on the underlying forwarding paradigm (data plane). As both
(i) the flow attribute encoding format and (ii) the services of the underlying layer(s) are specific to the forwarding paradigm of
the domain. This is what we have to keep in mind during the terminology discussions.

Moving towards a conclusion:
The layering used in the data-plane discussion are used only to select proper encapsulation formats (i.e. combination of protocols)
for DetNet data flows (i.e. answering Q2). Such a layering is not relevant for the DetNet functions and does not help to answer Q1.
Therefore two layers should be enough.
- DetNet service layer: implements the DetNet functions
- Transport layer: underlying layer that provides service according to the forwarding paradigm of the network (e.g. TE-tunnels, P2MP connectivity, etc.)

For the nodes we should distinguish at least tree types (analogously to MS-PW):
- Transit node: recognizes DetNet data flow attributes to handle DetNet traffic separate from other data flows but has no DetNet specific function
- Relay node: may change DetNet data flow attributes or has DetNet specific function(s) (typical example: a node in the forwarding path with Packet-level reliability function)
- Edge node: first/last hop of a technology domain, may change the forwarding paradigm and may transcode/adapt ingress and egress DetNet flow attributes (typical example: MPLS "PE" node)
A node can be both "relay node" and "edge node" simultaneously.

Just as an example let's have a scenario where an IP endhosts (using RTP-over-IP encapsulation for a DetNet data flow) are connected over an MPLS network (using PW-over-MPLS). Just some examples for the nore types are:
- Edge node: an MPLS PE node, that "creates" the PW for the DetNet flow (generates PW-label and Control-word), it is fully aware of the DetNet flow and its parameters - such a node is the T-PE analogy in case of MS-PW
- Transit node: an MPLS P node just forwarding traffic without special care (maybe for proper queuing it recognize DetNet packets  based on TC-field, but it is not aware of the DetNet flow parameters) - such a node is similar to the P node in the MS-PW scenario
- Relay-node: an MPLS nodes merging member flows to a compound flow (for packet-level-reliability), that may change the DetNet Flow-ID (members --> compound) - such a node is similar to the S-PE for MS-PW, where the PW label is switched (changed) during forwarding

Cheers
Bala'zs

-------- Original Message --------
Subject:

[Detnet-dp-dt] Relay vs Transit

Date:

Fri, 1 Jul 2016 00:51:17 -0400

From:

Lou Berger <[email-masked]<mailto:[email-masked]>>

To:

[email-masked]<mailto:[email-masked]> <[email-masked]<mailto:[email-masked]>>

   relay node

           interface to another.

+-----------+

~~~~~~~~~~~~~

+-----------+

+-----------+

~~~~~~~~~~~~~

+-----------+

   +---------+                                           +---------+

   | Service |                                           | Service |

 +---------+                                           +---------+

                      [Network]                   [Network]

                       `-----'                     `-----'

- Detnet Service

- DetNet Transport

- Link

- Sub-Network

- End station

- Relay node

- Transit node

What do people think?

Lou

[email-masked]<mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 4 Jul 2016 13:38:24 -0700

My 0.02 ZWD here. I like Lou's picture in a sense it makes things look
"easier" to me. However, I do not feel comfortable with the new layering it
has. I really could not get my head around the new added "transport" layer.
I think if we stick with the layering in DP-alt two layers should be enough
- and the division of functions we already had in DP-alt was close enough.
Also the picture lacks the edge node as also noted in Balazs' mail.

The proposed three roles below are OK to me. They are close enough to other
similar cases I have worked with in other circumstances.

With my wip version of the document I already took steps towards something
that is a blend of Lou's and Balazs' recent mails late last week. I have
cleaned away all that SAP text, Det-Service etc. I am very uncomfortable
with those and really think the DP-alt do not need to talk about them. The
layering and the three roles of the DetNet nodes should really do the same.

This brings me to another (rather) naive question that I need clarity:
Would a "legacy" 802.1TSN only aware end system be part of the DetNet
Domain and able to talk "DetNet flows"? Or would it be only part of the
DetNet through an edge node?

- JOuni

On Mon, Jul 4, 2016 at 9:32 AM, Balázs Varga A <[email-masked]>
wrote:

> Hi Lou and All,
>
>
>
> I agree that defining a relay node for DetNet could help to sort out
> terminology and I like Lou’ example
> (“Examples of such relays … (IMO) S-PEs in multi-segment pseudo wires.”).
> I think S-PE implements a
>
> If we use this definition than IMO all nodes must be “relay node” in the
> figure below as the transit nodes of the figure
>
> “interconnects different networks” (they are connected to a sub-network!).
>
>
>
>  +---------+                                           +---------+
>
> I have also found somewhat strange that we have no edge nodes on the
> figure, but that can be scenario specific,
>
> My intention is to keep layering and definitions as simple as possible.
> The original intention of the introduction of the
>
> two layers was just to group the data plane protocols and show that only
> their combination can fulfill the requirements
>
> of DetNet.
>
>
>
> So, let’s group DetNet related functions and parameters to find out the
> root of our difficulties in terminology.
>
>
>
> *We have three DetNet functions:*
>
> The main question for implementing DetNet functions: *Q1 – What services
> are provided by the underlying data plane layer(s)?*
>
> The more service the underlying layers provide, the less DetNet specific
> modification is needed for transport/relay nodes.
>
> (E.g., if p2mp LSPs are provided than we may use it for “replication” and
> not implement a similar DetNet function …)
>
>
>
> *We have two DetNet data flow related attributes:*
>
> A, Flow-ID and
>
> B, Sequence number.
>
> The main question regarding the attributes are: *Q2 – What part of the
> encapsulation should be used to encode the attributes?*
>
> is used by all the three DetNet functions, but sequence number is used
> only by the duplicate elimination functionality.
>
>
>
> These two questions have a common thing: the answer depends on the
> underlying forwarding paradigm (data plane). As both
>
> (i) the flow attribute encoding format and (ii) the services of the
> underlying layer(s) are specific to the forwarding paradigm of
>
> *Moving towards a conclusion:*
>
> The layering used in the data-plane discussion are used only to select
> proper encapsulation formats (i.e. combination of protocols)
>
> for DetNet data flows (i.e. answering Q2). Such a layering is not relevant
> for the DetNet functions and does not help to answer Q1.
>
> - Transport layer: underlying layer that provides service according to the
> forwarding paradigm of the network (e.g. TE-tunnels, P2MP connectivity,
> etc.)
>
>
>
> - Transit node: recognizes DetNet data flow attributes to handle DetNet
> traffic separate from other data flows but has no DetNet specific function
>
> - Relay node: may change DetNet data flow attributes or has DetNet
> specific function(s) (typical example: a node in the forwarding path with
> Packet-level reliability function)
>
> - Edge node: first/last hop of a technology domain, may change the
> forwarding paradigm and may transcode/adapt ingress and egress DetNet flow
> attributes (typical example: MPLS “PE” node)
>
> A node can be both “relay node” and “edge node” simultaneously.
>
>
>
> Just as an example let’s have a scenario where an IP endhosts (using
> RTP-over-IP encapsulation for a DetNet data flow) are connected over an
> MPLS network (using PW-over-MPLS). Just some examples for the nore types
> are:
>
> - Edge node: an MPLS PE node, that “creates” the PW for the DetNet flow
> (generates PW-label and Control-word), it is fully aware of the DetNet flow
> and its parameters – such a node is the T-PE analogy in case of MS-PW
>
> - Transit node: an MPLS P node just forwarding traffic without special
> care (maybe for proper queuing it recognize DetNet packets  based on
> TC-field, but it is not aware of the DetNet flow parameters) – such a node
> is similar to the P node in the MS-PW scenario
>
> - Relay-node: an MPLS nodes merging member flows to a compound flow (for
> packet-level-reliability), that may change the DetNet Flow-ID (members à
> compound) – such a node is similar to the S-PE for MS-PW, where the PW
> label is switched (changed) during forwarding
>
>
>
> Cheers
>
> Bala’zs
>
>
>
>
> *Subject: *
> *Date: *
> *From: *
> Lou Berger <[email-masked]>
>
> *To: *
>
> [email-masked] <[email-masked]>
>
>
>

-- 
Jouni Korhonen, Broadcom Ltd.

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 4 Jul 2016 16:37:24 -0700

This is how I have been thinking the nodes, flows etc.

"Legacy"                                                DetNet-aware
  End           Edge          Transit        Relay          End
 System         Node            Node         Node          System

+---------+                                              +---------+
|  Appl.  |<--------- End to End DetNet Service -------->|  Appl.  |
+---------+   +---------+                  +---------+   +~~~~~~~~~+
| Service |<--| Service |--- DetNet flow --| Service |-->| Service |
+---------+   +---------+   +---------+    +---------+   +---------+
|Transport|   |Trp| |Trp|   |Transport|    |Transport|   |Transport|
+-------.-+   +-.-+ +-.-+   +---.---.-+    +--.---.--+   +----.----+
        : Link  :    /  ,-----.  \  : Link    :   :   Link    :
        +.......+    +-[  Sub  ]-+  +.........+   +...........+
                       [Network]
                        `-----'

|------ Domain 1 ------|     |------- Domain 2 --------------------|

- JOuni

On Mon, Jul 4, 2016 at 1:38 PM, Jouni Korhonen <[email-masked]>
wrote:

> The proposed three roles below are OK to me. They are close enough to
> other similar cases I have worked with in other circumstances.
>
> On Mon, Jul 4, 2016 at 9:32 AM, Balázs Varga A <
> [email-masked]> wrote:
>
>> Hi Lou and All,
>>
>>
>>
>> for DetNet data flows (i.e. answering Q2). Such a layering is not
>> relevant for the DetNet functions and does not help to answer Q1.
>>
>> - Transport layer: underlying layer that provides service according to
>> the forwarding paradigm of the network (e.g. TE-tunnels, P2MP connectivity,
>> etc.)
>>
>>
>>

---

From: Lou Berger <[email-masked]>
Date: Tue, 5 Jul 2016 12:17:54 -0400

> Also the picture lacks the edge node as also noted in Balazs' mail.

Here's a version with edge nodes

 .........                                                         .........
 | TSN   |                                                         | TSN   |
 |Station|.  <------- End to End 802.1 TSN Service ------------>  /|Station|
 '-------'\                                                      / '-------'
       ,---`-.                                               ,-----.
      [  TSN  ]                                             [  TSN  ]
      [Network]                                             [Network]
       `--.--                                                `--.--'
          |   <-------------------- L2 VPN  Service ------->    |
     +----'----+                                           +----+----+
     | Service | <------- End to End DetNet Service -----> | Service |
     +~~~~~~~~~+                +~~~~~~~~~+                +~~~~~~~~~+
     |Transport|                |Transport|                |Transport|
     +~~~~~~~~~+   +~~~~~~~~~+  +~~~~~~~~~+  +~~~~~~~~~+   +~~~~~~~~~+
     | Network |   | Network |  |Net| |Net|  | Network |   | Network |
     +-------.-+   +-.--.----+  +--.+ +-.-+  +--.---.---+   +---.----+
             | Link  |  |  ,-----.  \   | Link  |   |  ,-----.  |
             .........  +-[  Sub  ]-+   .........   +-[  Sub  ]-+
                          [Network]                   [Network]
                           `-----'                     `-----'
       DetNet        Transit       Relay       Transit        DetNet
        Edge          Node         Node         Node           Edge

Note that this example is TSN<->TSN over detnet.  To do TSN<->DETNet ES, I think we need an interworking function that translates between each -- should be doable but need to figure out how things like addressing works.

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 5 Jul 2016 14:47:01 -0400

Jouni and I had a good talk and thought would be useful to try to go
back to some of our earlier discussions and reuse some of the MS-PW
figures discussed back in dallas and yokahama.  Here are some raw notes
of what we came up with -- he's going off to turn this into more formal
text:

DetNet-aware                                              DetNet-aware

Figure 1: DetNet Layers

Appl = real end application, e.g. audio
    Alternative = network application,
e.g., tsn<->detnet interworking or TSN over DetNet (~= L2VPN+ detent qos)
   
Service = function that provides duplication/removal (reliability),
        sequencing (in order delivery), e.g., MS-PW

Transport = MPLS, IP, PW-segment, Tunnel tech x, y and z.

Relay node = understands a bit of the detnet service to make intelligent
processing decision. Understands semantics of service parameters, but
not application details.

Edge node (ala B2bua or proxy node) A middlebox / an end system with
multiple interfaces, relay node + application knowledge

        Native  |<--------Multi-Segment Pseudowire----->|  Native
         Service |         PSN              PSN          |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)
           |     V     V     1    V     V     2    V     V   |
           |     +-----+          +-----+          +---- +   |
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|........PW1.......... |...PW3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........PW2...........|...PW4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |                             |                            |
       |                             |                            |
       |                     PW switching point                   |
       |                                                          |
       |                                                          |
       |<------------------- Emulated Service ------------------->|

                Figure 2: PW Switching Reference Model [RFC5254]

        TSN   |<--------End to End DetNet Service ------->|  TSN
         Service |        Transit          Transit       |  Service
   TSN    (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)   TSN
   End     |     V     V     1    V     V     2    V     V   |     End
  System   |     +-----+          +-----+          +---- +   |    System
   +---+   |     |T-PE1|==========|S-PE1|==========|T-PE2|   |    +---+
   |   |---------|.......DetNet Flow1.X.|...DF3..........|---|----|   |
   |CE1|   |     |     |          |     |          |     |   |    |CE2|
   |   |---------|........DF2........X..|...DF4..........|--------|   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |          Edge Node          |            Edge Node       |
       |                             |                            |
       |                     PW switching point                   |
       |                         Relay Node                       |
       |                                                          |
       |<--------------- Emulated TSN Service ------------------->|

                Figure 3: 802.1 TSN over DetNet

        DetNet |<--------End to End DetNet Service ------->|  DetNet
         Service |        Transit          Transit       |  Service
          (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)   DetNet
   DetNet  |     V     V     1    V     V     2    V     V   |     End
  System   |     +-----+          +-----+          +---- +   |    System
   +---+   |     |S-PE1|==========|S-PE1|==========|S-PE2|   |    +---+
   |  .....DFa...|.X...|....DF1...|..X..|...DF3....|...X.|...DFa....  |
   |CE1|   |     |  \  |          |     |          |  /  |   |    |CE2|
   |   |   |     |   X.|...DF2....|..X..|...DF4....|.X...|   |    |   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |          Relay Node         |           Relay Node       |
       |                             |                            |
       |                     PW switching point                   |
       |                         Relay Node                       |
       |                                                          |
       |<------------- End to End DetNet Service ---------------->|
                Figure 4:  Native DetNet

        TSN    |<-----------End to End Service ---------->|  DetNet
         Service |        Transit          Transit       |  Service
   TSN    (AC)   |     |<-Tunnel->|     |<-Tunnel->|     |  (AC)   DetNet
   End     |     V     V     1    V     V     2    V     V   |     End
  System   |     +-----+          +-----+          +---- +   |    System
   +---+   |     |T-PE1|==========|S-PE1|==========|S-PE2|   |    +---+
   |   |---------|DFa. |          |     |          |    .|...DFa....  |    
   |   |         | \X..|....DF1...|..X..|...DF3....|...X |   |    |   |
   |CE1|   |     |   \ |          |     |          |  /  |   |    |CE2|
   |   |         |    X|...DF2....|..X..|...DF4....|.X...|   |    |   |
   +---+   |     |     |==========|     |==========|     |   |    +---+
       ^         +-----+          +-----+          +-----+        ^
       |     Provider Edge 1         ^        Provider Edge 3     |
       |          Edge Node          |           Relay Node       |
       |                             |                            |
       |                     PW switching point                   |
       |                         Relay Node                       |
       |                                                          |
       |<-TSN Svc->|<----------------------DetNet Service  ------>|

                   Figure 5: 802.1 TSN over DetNet

---

From: Pat Thaler <[email-masked]>
Date: Tue, 5 Jul 2016 13:23:39 -0700

I like where the figures are going.

It would be good if we could come up with a term other than "relay", but
not sure what might replace it.

In the transit node definition:
"A node that provide*s* network layer switching across multiple
        links and/or sub-networks, e.g., and MPLS LSR"
Is it the intent to leave layer 2 bridges out of the transit node
definition?

Regards,
Pat

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Jul 2016 13:33:54 -0700

Hi,

Inline..

> not sure what might replace it.

I actually find relay rather good choice. There's exisiting presedence 
of "relay nodes" with similar semantics in IETF.

> "A node that provide_s_ network layer switching across multiple

No. The example is just given from a LSR point of view.

- Jouni

>
> Regards,
> Pat
>
> On Tue, Jul 5, 2016 at 11:47 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      DetNet
>     [email-masked] <mailto:[email-masked]>

---

From: Pat Thaler <[email-masked]>
Date: Tue, 5 Jul 2016 13:54:06 -0700

I was concerned with definition not the example. "Network layer switching"
would exclude devices doing layer 2 switching, i.e., bridges.
To include bridges, wouldn't it need to say "network or link layer
switching"?

On Tue, Jul 5, 2016 at 1:33 PM, Jouni Korhonen <[email-masked]>
wrote:

> I actually find relay rather good choice. There's exisiting presedence of
> "relay nodes" with similar semantics in IETF.
>

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Jul 2016 13:59:00 -0700

Probably it should state that.

- Jouni

7/5/2016, 1:54 PM, Pat Thaler kirjoitti:
> I was concerned with definition not the example. "Network layer
> switching" would exclude devices doing layer 2 switching, i.e., bridges.
> On Tue, Jul 5, 2016 at 1:33 PM, Jouni Korhonen
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Inline..
>
>     I actually find relay rather good choice. There's exisiting
>     presedence of "relay nodes" with similar semantics in IETF.
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             DetNet-aware
>         DetNet-aware
>             +---------+
>         +---------+
>             e.g., tsn<->detnet interworking or TSN over DetNet (~=
>         L2VPN+ detent
>             qos)
>
>                |
>          |---------|........PW2...........|...PW4..........|--------|   |
>               |
>               |
>                    |                     PW switching point
>              |
>                    |
>               |
>                    |
>               |
>                |
>          |---------|........DF2........X..|...DF4..........|--------|   |
>                    |          Edge Node          |            Edge Node
>              |
>               |
>                    |                     PW switching point
>              |
>                    |                         Relay Node
>              |
>                    |
>               |
>                |
>         .....DFa...|.X...|....DF1...|..X..|...DF3....|...X.|...DFa....  |
>                |CE1|   |     |  \  |          |     |          |  /  |
>          |    |CE2|
>               |
>                    |                     PW switching point
>              |
>                    |                         Relay Node
>              |
>                    |
>               |
>               |
>                    |                     PW switching point
>              |
>                    |                         Relay Node
>              |
>                    |
>               |
>         <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Janos Farkas <[email-masked]>
Date: Tue, 5 Jul 2016 21:03:48 +0000

Hi Lou and Jouni,

I agree that it is very useful to take a look at multi-segment PW.
I'm glad to see now the T-PE as well in the figures not only S-PE.
I think, one aspect that may help the mental exercise is where the PW actually ends (the PW that ends at T-PE) in case of the different alternatives if PW is used to implement DetNet. Does it end at the End System in some cases?

Just my 2cents after a quick look at the figures, in case helps progress by any means,
Janos

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, July 05, 2016 8:47 PM
To: Jouni Korhonen <[email-masked]>; Balázs Varga A <[email-masked]>
Cc: [email-masked]
Subject: Re: [Detnet-dp-dt] Relay vs Transit

Jouni and I had a good talk and thought would be useful to try to go back to some of our earlier discussions and reuse some of the MS-PW figures discussed back in dallas and yokahama.  Here are some raw notes of what we came up with -- he's going off to turn this into more formal
text:

Figure 1: DetNet Layers

Relay node = understands a bit of the detnet service to make intelligent processing decision. Understands semantics of service parameters, but not application details.

Edge node (ala B2bua or proxy node) A middlebox / an end system with multiple interfaces, relay node + application knowledge

---

From: Lou Berger <[email-masked]>
Date: Tue, 5 Jul 2016 17:05:52 -0400

We may have a disconnect here.  A detnet relay node would need to
understand detnet service semantics, which are likely to be be IP based
at some level -- just like MPLS service semantics are.  Now detnet relay
nodes may be interconnected via N# 802.1 TSN relays/bridges.   The
detnet relay nodes would appear as end stations to the 802.1 TSN devices
/layer.

Does this make sense?

Lou

---

From: Lou Berger <[email-masked]>
Date: Tue, 5 Jul 2016 17:11:24 -0400

Hi Janos,

On 7/5/2016 5:03 PM, Janos Farkas wrote:
> I think, one aspect that may help the mental exercise is where the PW actually ends (the PW that ends at T-PE)
in the figures below PW endpoints are identified at a box level, for
within the box RFCs 6215 and 7274 provide some nice concepts / drawings
that we could leverage

>  in case of the different alternatives if PW is used to implement DetNet. Does it end at the End System in some cases?
Yes, in both 4 and 5.
Note Figure 5's legend should read " 802.1 TSN and DetNet Service
Inter-working"

> Just my 2cents after a quick look at the figures, in case helps progress by any means,
Thank you!
Lou

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Jul 2016 14:11:42 -0700

Wasn't Pat referring to a transit node below regarding the definition?

- Jouni

---

From: Lou Berger <[email-masked]>
Date: Tue, 5 Jul 2016 17:16:52 -0400

I agree it would be a transit node, but we don't have that in the
drawing anymore...

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 5 Jul 2016 15:11:12 -0700

Hi,

Not in the "PW modeled" figures but in the overall concept figure we still
have the transit node (that does not have the service layer).

- Jouni

On Tue, Jul 5, 2016 at 2:16 PM, Lou Berger <[email-masked]> wrote:

> >>>>             of what we came up with -- he's going off to turn this
> into
> >>>>         more formal
> >>>>             text:
> >>>>
> >>>>
> >>>>
> >>>>             DetNet-aware
> >>>>         DetNet-aware
> >>>>               End           Edge          Transit        Relay
>   End
> >>>>              System         Node            Node         Node
> >>>>         System
> >>>>             +---------+
> >>>>         +---------+
> >>>>             Relay node = understands a bit of the detnet service to
> make
> >>>>         intelligent
> >>>>                        |     V     V     1    V     V     2    V
>  V   |
> >>>>                    |     Provider Edge 1         ^        Provider
> Edge
> >>>>         3     |
> >>>>                    |                             |
> >>>>               |
> >>>>                    |                             |
> >>>>               |
> >>>>                    |                     PW switching point
> >>>>              |
> >>>>                    |
> >>>>               |
> >>>>                    |
> >>>>               |
> >>>>                    |     Provider Edge 1         ^        Provider
> Edge
> >>>>         3     |
> >>>>                    |          Edge Node          |            Edge
> Node
> >>>>              |
> >>>>                    |                             |
> >>>>               |
> >>>>                    |                     PW switching point
> >>>>              |
> >>>>                    |                         Relay Node
> >>>>              |
> >>>>                    |
> >>>>               |
> >>>>                    |     Provider Edge 1         ^        Provider
> Edge
> >>>>         3     |
> >>>>                    |          Relay Node         |           Relay
> Node
> >>>>              |
> >>>>                    |                             |
> >>>>               |
> >>>>                    |                     PW switching point
> >>>>              |
> >>>>                    |                         Relay Node
> >>>>              |
> >>>>                    |
> >>>>               |
> >>>>                     TSN    |<-----------End to End Service
> ---------->|
> >>>>         DetNet
> >>>>                TSN    (AC)   |     |<-Tunnel->|     |<-Tunnel->|
>  |  (AC)
> >>>>              DetNet
> >>>>                End     |     V     V     1    V     V     2    V     V
> >>>>          |     End
> >>>>                    |     Provider Edge 1         ^        Provider
> Edge
> >>>>         3     |
> >>>>                    |          Edge Node          |           Relay
> Node
> >>>>              |
> >>>>                    |                             |
> >>>>               |
> >>>>                    |                     PW switching point
> >>>>              |
> >>>>                    |                         Relay Node
> >>>>              |
> >>>>                    |
> >>>>               |

---

From: Lou Berger <[email-masked]>
Date: Tue, 05 Jul 2016 20:10:45 -0400

Great. I *think* we're in sync and your updated Rev will confirm...

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 6 Jul 2016 14:47:06 +0000

Hi Jouni,

Just two short comment regarding the new figures (copy paste typos ?):
- Figure4: I think here node naming should be changed due to the two “native DetNet end systems” (CE1 and CE2):
T-PE1 should be S-PE1 and T-PE2 should be S-PE3 (and S-PE1 in the middle S-PE2)

- Figure5: similarly due to the “native DetNet end system” (CE2): T-PE2 should be S-PE2

See You soon in the call
Bala’zs

From: Lou Berger [mailto:[email-masked]]
Sent: Wednesday, July 06, 2016 2:11 AM
To: Jouni Korhonen <[email-masked]>
Cc: Pat Thaler <[email-masked]>; Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] Relay vs Transit

On July 5, 2016 6:12:14 PM Jouni Korhonen <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Not in the "PW modeled" figures but in the overall concept figure we still have the transit node (that does not have the service layer).

- Jouni

On Tue, Jul 5, 2016 at 2:16 PM, Lou Berger <[email-masked]<mailto:[email-masked]>> wrote:
I agree it would be a transit node, but we don't have that in the
drawing anymore...

On 7/5/2016 5:11 PM, Jouni Korhonen wrote:
>>>> <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>>>>
>>>>     Hi,
>>>>
>>>>     Inline..
>>>>
>>>>         On Tue, Jul 5, 2016 at 11:47 AM, Lou Berger <[email-masked]<mailto:[email-masked]>
>>>>         <mailto:[email-masked]<mailto:[email-masked]>>
>>>>         <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>> wrote:
>>>>
>>>>             [email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>
>>>>         <mailto:[email-masked]<mailto:[email-masked]> <mailto:[email-masked]<mailto:[email-masked]>>>

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 6 Jul 2016 13:37:21 -0700

Thanks. These are now corrected.

- Jouni

On Wed, Jul 6, 2016 at 7:47 AM, Balázs Varga A <[email-masked]>
wrote:

> - Figure4: I think here node naming should be changed due to the two
> “native DetNet end systems” (CE1 and CE2):
>
> *From:* Lou Berger [mailto:[email-masked]]
> *Sent:* Wednesday, July 06, 2016 2:11 AM
> *To:* Jouni Korhonen <[email-masked]>
> *Cc:* Pat Thaler <[email-masked]>; Balázs Varga A <
> [email-masked]>; [email-masked]
> *Subject:* Re: [Detnet-dp-dt] Relay vs Transit
>
>
>