Subject: [Detnet-dp-dt] data plane draft comments

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

Hi,

I've been checking the data plane draft and the architecture draft.
Attached are my comments on the data plane draft in a pdf.
Many comments and changes are to improve consistency in the document.
In order to speed progress, I've implemented the ones that seems 
straight for ward to me in the version I uploaded to github.
Only the comments that are checkmarked in the pdf are implemented in the 
xml.
Some of the inconsistency was my fault, i.e., being loose by just using 
IP in the text proposed for summary. Jouni made it IPv[46]. I've 
replaced those with IPv6. I guess we want to have there  IPv6 in 2016.

Regards,
Janos

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 7 Jul 2016 09:28:11 -0700

Thanks Janos,

I'll be going through the comments now. Regarding the IPv4 comments.. I
recall at some point there was a comment that we still cannot neglect IPv4
and that's why I still kept it in there (note.. I got no love towards IPv4
so I would be happy not to recommend it in any way ;)

- Jouni

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

> In order to speed progress, I've implemented the ones that seems straight
> for ward to me in the version I uploaded to github.
> Some of the inconsistency was my fault, i.e., being loose by just using IP
> in the text proposed for summary. Jouni made it IPv[46]. I've replaced
> those with IPv6. I guess we want to have there  IPv6 in 2016.
>
> Regards,
> Janos
>
> _______________________________________________
> 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: Thu, 7 Jul 2016 12:36:03 -0400

sorry v4 and v6 should both be covered/included

On 7/7/2016 12:28 PM, Jouni Korhonen wrote:
> Thanks Janos,
>
> I'll be going through the comments now. Regarding the IPv4 comments..
> I recall at some point there was a comment that we still cannot
> neglect IPv4 and that's why I still kept it in there (note.. I got no
> love towards IPv4 so I would be happy not to recommend it in any way ;)
>
> - Jouni
>
> On Thu, Jul 7, 2016 at 9:09 AM, János Farkas
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     Only the comments that are checkmarked in the pdf are implemented
>     in the xml.
>     Some of the inconsistency was my fault, i.e., being loose by just
>     using IP in the text proposed for summary. Jouni made it IPv[46].
>     I've replaced those with IPv6. I guess we want to have there  IPv6
>     in 2016.
>
>     Regards,
>     Janos
>
>     [email-masked] <mailto:[email-masked]>

---

From: Jouni Korhonen <[email-masked]>
Date: Thu, 7 Jul 2016 09:53:03 -0700

Comment resolution..

1) "IS a transit node really avare of DetNet? A transit node can be that
simple it does not know taht it transorts DetNEt"

I recall the discussion went like.. a transit node needs to be DetNet aware
to a point it can comply with required queuing and reservations needed for
DetNet flows and be able to distinguish those flows somehow from non-DetNet
flows (e.g., based on the label). So it is a dump transport node but it
most likely need to understand portion of the DetNet that concerns
transport, which can be very little.

2) "Do we need admin domains in this figure?"

No.

3-7) "#8 should/could be removed from this section. #8 is listed for the
Service layer whereas IPv6 is Transport"

Should this actually be in the transport layer and not in the service
layer? The current description of the #8 is very much towards the transport.

8) "#4 is not listed for the Service layer"

Agree - should be removed.

9) "#9 is not listed for the Service layer"

Agree. And in general we could move #9 into OAM bucket..

- Jouni

---

From: János Farkas <[email-masked]>
Date: Thu, 7 Jul 2016 19:02:30 +0200

On 7/7/2016 6:53 PM, Jouni Korhonen wrote:
> Comment resolution..
>
> 1) "IS a transit node really avare of DetNet? A transit node can be 
> that simple it does not know taht it transorts DetNEt"
>
> I recall the discussion went like.. a transit node needs to be DetNet 
> aware to a point it can comply with required queuing and reservations 
> needed for DetNet flows and be able to distinguish those flows somehow 
> from non-DetNet flows (e.g., based on the label). So it is a dump 
> transport node but it most likely need to understand portion of the 
> DetNet that concerns transport, which can be very little.
OK.
No need to dig into these details at that part of the doc. We can leave 
as is.

> 2) "Do we need admin domains in this figure?"
Maybe we could remove, to avoid comments. ;-)

>
> 3-7) "#8 should/could be removed from this section. #8 is listed for 
> the Service layer whereas IPv6 is Transport"
>

I've implemented the removals by making the text comments in the xml.

Thanks,
Janos

---

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

I just merged/pushed some changes.  Most are just language tweaks (see
diff at end).  The one substantive change is to Figure 1, where I added
the Service proxy and TSN in place of service on the left side:
  TSN              Edge          Transit        Relay        DetNet
  End System       Node            Node         Node         End System

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

Also does it make sense to immediately follow with the discussion on
layers and move the PW like figures after that.  Ether way perhaps each
should be their own subsections:
 - Detnet Data Plane Layers
 - DetNet Service Scenarios   // the PW pictures

Lou

diff --git a/draft-dt-detnet-dp-alt-01.xml b/draft-dt-detnet-dp-alt-01.xml
index 096628a..16fbc37 100755
--- a/draft-dt-detnet-dp-alt-01.xml
+++ b/draft-dt-detnet-dp-alt-01.xml
@@ -212,7 +212,8 @@
      <list style="symbols">
       <t>Bandwidth reservation and enforcement,</t>
       <t>explicit routes,</t>
-      <t>packet replication and elimination.</t>
+      <t>packet loss protection, initially provided by replication and
+      elimination.</t>
      </list>
    This document identifies existing IP and Multiprotocol Label
Switching (MPLS)
    <xref target="RFC3031"/>, layer-2 or layer-3 encapsulations and
transport
@@ -235,20 +236,22 @@
 
  <section title="Terminology">
   <t>
-   This document uses the terminology established in the DetNet
architecture
-   <xref target="I-D.finn-detnet-architecture"/> with the following
-   clarifications and/or additions:
+   This document will eventually use the terminology established in the
DetNet architecture
+   <xref target="I-D.finn-detnet-architecture"/>.  Currently the following
+   terms are used:
   </t>
    <t hangText="DetNet Reliability"><vspace blankLines="1"/>
-    A set of mechanisms to increase the probability of lossless DetNet
-    flow transport across a network.  Example mechanisms include
+    A set of mechanisms to increase the probability of lossless (i.e.,
+    zero loss) DetNet
+    flow delivery across a network.  Example mechanisms include
     packet replication and dulpicate elimination.
     <vspace blankLines="1"/></t>
   <t><list style="hanging">
    <t hangText="Transit Node"><vspace blankLines="1"/>
     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.
+    multiple links and/or sub-networks. Transit nodes provide packet
+    forwarding services to DetNet nodes.   An MPLS LSR, or IP router
are example
+    transit nodes.
     <vspace blankLines="1"/></t>
    <t hangText="Relay Node"><vspace blankLines="1"/>
     A DetNet Service aware middle box that interconnects different
@@ -260,7 +263,8 @@
     <vspace blankLines="1"/></t>
    <t hangText="Edge Node"><vspace blankLines="1"/>
     A relay node with application level knowledge (i.e., basically a
-    "proxy" node). Egde nodes are needed when interfacing with nodes or
+    "proxy" node). Egde nodes include DetNet application level
+    functions and are needed when interfacing (or inter-working) with
nodes and
     end systems that are not DetNet-enabled.
     </t>
   </list></t>
@@ -268,13 +272,17 @@
 
 <section title="DetNet Data Plane Overview" anchor="sec_dt_dp">
  <t>
-   A "Deterministic Network" will be composed of DetNet enabled node
i.e., End
-   Systems, Edge Nodes, Relay Nodes and Transit Nodes.  DetNet enabled
nodes
-   will provide a DetNet services.  All DetNet enabled nodes are
interconnected
-   by sub-networks (a link is also considered as a sub-network). These
+   A "Deterministic Network" will be composed of DetNet enabled nodes
i.e., End
+   Systems, Edge Nodes, Relay Nodes and collectively deliver DetNet
+   services.  DetNet enabled nodes are interconnected via Transit Nodes
+   (i.e., routers) which support DetNet, but are not DetNet service
+   aware.  Transit nodes see DetNet nodes as end points.  
+   All DetNet enabled nodes are connect to
+   sub-networks, where a point-to-point link is also considered as a
+   simple sub-network. These
    sub-networks will provide DetNet compatible service for support of
DetNet
-   traffic.  Examples of sub-networks include IEEE 802.1TSN and a
point-to-point
-   OTN links.  Of course, multi-layer DetNet systems may also be
possible, where
+   traffic.  Examples of sub-networks include IEEE 802.1TSN and
+   OTN.  Of course, multi-layer DetNet systems may also be possible, where
    one DetNet appears as a sub-network, and provides service to, a
higher layer
    DetNet system. A simple DetNet concept network is shown in <xref
    target="fig_detnet"/>.
@@ -286,10 +294,10 @@ title="A Simple DetNet Enabled Network">
 TSN              Edge          Transit        Relay        DetNet
 End System       Node            Node         Node         End System
 
-+---------+                                                +---------+
-|  Appl.  |<-------------- End to End Service ------------>|  Appl.  |
++---------+    +.........+                                 +---------+
+|  Appl.  |<---:Svc Proxy:-- End to End Service ---------->|  Appl.  |
 +---------+    +---------+                   +---------+   +---------+
-|         |    | Service :<-- DetNet flow ---: Service :-->: Service |
+|   TSN   |    |TSN| |Svc|<-- DetNet flow ---: Service :-->| Service |
 +---------+    +---------+    +---------+    +---------+   +---------+
 |Transport|    |Trp| |Trp|    |Transport|    |Trp| |Trp|   |Transport|
 +-------.-+    +-.-+ +-.-+    +--.----.-+    +-.-+ +-.-+   +---.-----+
@@ -303,12 +311,17 @@ End System       Node            Node        
Node         End System
 ]]></artwork>
 </figure>
 
+<t>
+  [LB: Perhaps move layering from below here???]
+</t>
+
  <t>
-  In an attempt to concretize DetNet date plane this document uses
Multi-Segment
+  In an attempt to illustrate a DetNet date plane, this document uses the
+  Multi-Segment
   Pseudowire Emulation Edge-to-Edge (PWE3) <xref target="RFC5254"/>
reference
-  model shown in <xref target="fig_pw_detnet"/> as an analogue for
different
-  DetNet data plane deployment options and to illustrate layering could
work.
-  Other reference models are possible but not explicitly referenced in
this
+  model shown in <xref target="fig_pw_detnet"/> as the foundation for
different
+  DetNet data plane deployment options and how layering could work.
+  Other reference models are possible but not covered in this
   document. Note that other technologies can be also used to implement
DetNet,
   Multi-Segment PW is only used here to illustrate functions, features and
   layering from the perspective of the architecture.
@@ -337,11 +350,13 @@ title="Pseudo Wire switching reference model">
 </figure>
 
  <t>
-  <xref target="fig_8021_detnet"/> illustrates how DetNet provides
services for
-  IEEE 802.1TSN end systems over packet switched, potentially routed
network.
-  The edge nodes insert and also remove required DetNet data plane
-  encapsulation. The 'X' in the edge and relay nodes represents a potential
-  DetNet flow packet replication and elimination point.  
+  <xref target="fig_8021_detnet"/> illustrates how DetNet can provide
services for
+  IEEE 802.1TSN end systems over a DetNet enabled network. 
+  The edge nodes insert and remove required DetNet data plane
+  encapsulation.  The 'X' in the edge and relay nodes represents a
potential
+  DetNet flow packet replication and elimination point.  This
+  conceptually parallels L2VPN services, and could leverage existing
+  related solutions as discussed below.
  </t>
 
 <figure align="center" anchor="fig_8021_detnet"
@@ -366,11 +381,14 @@ System  |     +-----+          +-----+         
+---- +   |    System
 
  <t>
   <xref target="fig_native_detnet"/> illustrates how end to end native
DetNet
-  service could be deployed. The assumption here is that end systems
are able
-  to source and receive native DetNet flows, which in the example case of
-  PseudoWires (PW) would mean adequete PW encapsulation.  Like earlier
the 'X'
+  service can be provided. In this case, the end systems are able
+  to send and receive native DetNet flows.  For example, as PseudoWire
+  (PW) encapsulated IP.  Like earlier the 'X'
   in the end systems, edge and relay nodes represents potential DetNet flow
-  packet replication and elimination points.  
+  packet replication and elimination points. Here the relay nodes may
+  change the underlying transport, for example replacing IP with MPLS or
+  tunneling IP over MPLS (e.g., via L3VPNs), or simply interconnect
+  network domains.
  </t>
 
 <figure align="center" anchor="fig_native_detnet"
@@ -395,8 +413,10 @@ System   |    +-----+          +-----+         
+-----+   |    System
 
  <t>
   <xref target="fig_iw_detnet"/> illustrates how a IEEE 802.1TSN end system
-  could communicate with a native DetNet end system through an edge
node, which
-  adds and removes required DetNet data plane encapsulation.  Just like
earlier
+  could communicate with a native DetNet end system through an edge node
+  which provides a TSN to DetNet inter-working capability.  The edge
+  node would adds and removes required DetNet data plane encapsulation
+  as well as provide any needed address mapping. As in previous figures,
   the 'X' in the end systems, edge and relay nodes represents potential
DetNet
   flow packet duplication and elimination points.  
  </t>
@@ -441,12 +461,15 @@ System   |     +-----+          +-----+         
+-----+   |    V System
      which are needed during forwarding. DetNet enabled end systems
originate
      and terminate the DetNet Service layer and are peers at the DetNet
Service
      layer. DetNet relay and edge nodes also implement DetNet Service layer
-     functions.
+     functions. The DetNet service layer is used to
+     deliver traffic end to end across a DetNet domain.
     <vspace blankLines="1"/></t>
     <t hangText="DetNet Transport Layer"><vspace blankLines="1"/>
-     The DetNet transport layer is supported by all DetNet nodes.  It
operates
-     below the DetNet Service layer. The DetNet Transport layer is used to
-     forward traffic end to end across a DetNet domain.
+     The DetNet transport layer is required on all DetNet nodes. All
+     DetNet nodes are end points and the transport layer. Non-DetNet
+     service aware transit nodes deliver traffic between DetNet nodes.
+     The DetNet transport layer operates below and supports the DetNet
+     Service layer. 
     </t>
    </list>
    Distinguishing the function of these two DetNet data plane layers
helps to

---

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

Ok from my side with the edits (language is much better now ;)
I just pushed a new version that corrected broken lists in terminology.

Another question. Is the criteria #8 in a correct place to start with?

- Jouni

---

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

Okay -- just added "Example DetNet Service Scenarios" as a subsection
(PW drawings) and moved it to after the layering description (which I
did not make a subsection).

pushed to github...
On 7/7/2016 1:36 PM, Jouni Korhonen wrote:
> On Thu, Jul 7, 2016 at 10:14 AM, Lou Berger <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>      +---------+
>     -+---------+                                               
>     +---------+
>      +---------+

---

From: János Farkas <[email-masked]>
Date: Fri, 8 Jul 2016 08:59:28 +0200

I do not want to remove IPv4.
My only point is that I'd prefer to have only IPv6 there when it comes 
to recommendation or sg like that. I'd not promote IPv4. Evaluating both 
is fine of course.
Janos

---

From: János Farkas <[email-masked]>
Date: Fri, 8 Jul 2016 09:07:48 +0200

I like the new figure.
I also had trouble with the figure. Looking at the previous version, I 
was thinking that the "End to End Service" should end up at the edge 
port of the left hand side edge node (as was mentioned on the call too). 
Then, the problem was: it is called End to End.
I think this update resolves the concern.

We can always make further updates in a future revision if the group 
does not like it.

Thanks,
Janos

---

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

That's a fair position to hold, but I don't think represents a consensus 
position.  To date, my take on this from all perspectives is that v4 and v6 
need to be supported equally.

Lou

---

From: János Farkas <[email-masked]>
Date: Fri, 8 Jul 2016 12:43:18 +0200

On 7/8/2016 12:34 PM, Lou Berger wrote:
> That's a fair position to hold, but I don't think represents a 
> consensus position. 
You are right.

> To date, my take on this from all perspectives is that v4 and v6 need 
> to be supported equally.
Fine.

Janos

---

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

>> To date, my take on this from all perspectives is that v4 and v6 need 
sorry...

BTW I do think we have all camps represented in the WG (those who want
only v6, those who want only v4, and those want or willing to do both.)