Subject: [Detnet-dp-dt] question on section 4.1

From: Lou Berger <[email-masked]>
Date: Tue, 20 Jun 2017 13:34:05 -0400

Does anyone know what the following is intended to mean:

  However, transit nodes may have limited capabilities to recognize DetNet
  specific fields (e.g., in case of MPLS the PW label). Therefore,
identifying each
  individual DetNet flow on a transit node may not be achieved in some
network
  scenarios.

Thanks,

Lou

---

From: Balázs Varga A <[email-masked]>
Date: Wed, 21 Jun 2017 06:15:19 +0000

Hi Lou,

This text in the draft is a very short summary of a somewhat longer discussion we have had on the calls. 
It seems to be too short ... It intends to refer to the following:

In case of PWoMPLS there may be many labels in the label stack (SR labels, etc.) of a DetNet packet. 
Transit (P) nodes should ensure zero-congestion-loss by allocating resources for the DetNet flows.
In order to identify a given DetNet flow (and using the for the flow allocated resources) transit 
nodes need to walk through the whole label stack, what may not be supported by the transit node 
or may impact the packet forwarding capabilities of the node. Furthermore it requires per DetNet 
flow states on transit nodes.

These requirements could be simplified by putting together multiple DetNet flows e.g., in a tunnel 
and allocate resources on a transit node only for such an "aggregate DetNet flow". So, the transit 
node has to identify only the tunnel and not each individual DetNet flow, what results in simplified 
operation and less states. 

Cheers
Bala'zs

-----Original Message-----
From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: 2017. június 20. 19:34
To: [email-masked]
Subject: [Detnet-dp-dt] question on section 4.1

  However, transit nodes may have limited capabilities to recognize DetNet
  specific fields (e.g., in case of MPLS the PW label). Therefore, identifying each
  individual DetNet flow on a transit node may not be achieved in some network
  scenarios.

Thanks,

Lou

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

---

From: Lou Berger <[email-masked]>
Date: Wed, 21 Jun 2017 08:34:34 -0400

Bala'zs

This is an important point to capture, and not at all what I expected from 
what was written. I think there was some text on this in the Alternatives 
document. I'll try to pull it over into a new subsection of additional 
considerations.

Lou

---

From: Lou Berger <[email-masked]>
Date: Thu, 22 Jun 2017 12:00:19 -0400

> document. I'll try to pull it over into a new subsection of additional 

Here's what I just checked in - does it appropriately capture the intent?

commit 164ae8326553bb2b2c2c3ee6fbcd13a8391e03fb
    Fix a typo
    Clarified existing text associated with aggregation/hierarchy
    Added other considerations section on aggregation/hierarchy

diff --git a/draft-dt-detnet-dp-sol-01.xml b/draft-dt-detnet-dp-sol-01.xml
index ef6a5c1..19f5672 100755
--- a/draft-dt-detnet-dp-sol-01.xml
+++ b/draft-dt-detnet-dp-sol-01.xml
@@ -460,14 +460,18 @@ System  |    +--------+       +--------+      
+--------+   | System
   Each node (edge, relay and transit) use a local-ID of the
DetNet-(compound)-flow in
   order to accomplish its role during transport. Recognizing the DetNet
flow is more
   relaxed for edge and relay nodes, as they are fully aware of both the
DetNet
-  service and transport layers. The DetNet role of intermediate
transport nodes is
+  service and transport layers. The primary DetNet role of intermediate
transport nodes is
   limited to ensuring congestion protection and latency control for the
above listed DetNet
   functions.
-  <!-- LB: unclear what the following means.  Perhaps restate or drop. -->
-  However, transit nodes may have limited capabilities to recognize DetNet
-  specific fields (e.g., in case of MPLS the PW label). Therefore,
identifying each
-  individual DetNet flow on a transit node may not be achieved in some
network
-  scenarios.
+ </t>
+ <t>
+  The DetNet data plane allows for the aggregation of DetNet flows,
+  e.g., via MPLS hierarchical LSPs, to improved scaling.  When DetNet
+  flows are aggregated, transit nodes may have limited ability to
+  provide service on per-flow DetNet identifiers. Therefore, identifying
+  each individual DetNet flow on a transit node may not be achieved in
+  some network scenarios, but DetNet service can still be assured in
+  these scenarios through resource allocation and control.
  </t>
 
  <t>
@@ -906,7 +910,10 @@ Client AC   |    NSP      |           |    Single  
| member Inst.
      and sometimes path control, traffic protection, shaping, policing and
      remarking. Example protocols that support QoS control include <xref
      target="RFC2205">Resource ReSerVation Protocol (RSVP)</xref>
(RSVP) and
-     RSVP-TE <xref target="RFC3209"/> and <xref target="RFC3473"/>.
+     RSVP-TE <xref target="RFC3209"/> and <xref target="RFC3473"/>.  The
+     existing MPLS mechanisms defined to support CoS <xref
+     target="RFC3270"/> can also be used to reserve resources for
+     specific traffic classes.
     </t>
     <t>
       In addition to path pinning and packet replication and
@@ -936,7 +943,7 @@ Client AC   |    NSP      |           |    Single  
| member Inst.
      of flows requiring DetNet QoS.
    </t>
    <t>
-     CoS for DetNet flows carried in IPv6 MUST be provided locally by
+     QoS for DetNet flows carried in IPv6 MUST be provided locally by
      the DetNet aware hosts and routers supporting DetNet flows.  Such
      support will leverage the underlying network layer such as
      802.1TSN.  The traffic control mechanisms used to deliver QoS for
@@ -965,7 +972,54 @@ Client AC   |    NSP      |           |    Single  
| member Inst.
   </t>
  </section>
 
-
+ <section title="Cross-DetNet flow resource aggregation"
anchor="Aggregation">
+   <t>
+     The ability to aggregate individual flows, and their associated
+     resource control, into a larger aggregate is an important technique
+     for improving scaling of control in the data, management and
+     control planes.  This document identifies the traffic identification
+     related aspects of aggregation of DetNet flows.  The resource
+     control and management aspects of aggregation (including the
+     queuing/shaping/policing implications) will be covered in other
+     documents.  The data plane implications of aggregation are
+     independent for PW/MPLS and IP encapsulated DetNet flows.
+   </t>
+   <t>
+     DetNet flows transported via MPLS can leverage MPLS-TE's existing
+     support for hierarchical LSPs (H-LSPs), see <xref
+     target="RFC4206"/>.  H-LSPs are typically used to aggregate control
+     and resources, they may also be used to provide OAM or protection
+     for the aggregated LSPs.  Arbitrary levels of aggregation naturally
+     falls out of the definition for hierarchy and the MPLS label stack
+     <xref target="RFC3032"/>.  DetNet nodes which support aggregation
+     (LSP hierarchy) map one or more LSPs (labels) into and from an
+     H-LSP.  Both carried LSPs and H-LSPs may or may not use the TC
+     field, i.e., L-LSPS or E-LSPS.  Such nodes will need to ensure that
+     traffic from aggregated LSPs are placed (shaped/policed/enqueued)
+     onto the H-LSPs in a fashion that ensures the required DetNet
+     service is preserved.
+   </t>
+   <t>
+     DetNet flows transported via IP have more limited aggregation
+     options, due to the available traffic flow identification fields of
+     the IP solution.  One available approach is to manage the resources
+     associated with a DSCP identified traffic class and to map (remark)
+     individually controlled DetNet flows onto that traffic class.  This
+     approach also requires that nodes support aggregation ensure that
+     traffic from aggregated LSPs are placed (shaped/policed/enqueued)
+     in a fashion that ensures the required DetNet service is preserved.
+   </t>
+   <t>
+     In both the MPLS and IP cases, additional details of the traffic
control
+     capabilities needed at a DetNet-aware node may be covered in the
+     new service descriptions mentioned above or in separate future
+     documents.  Management and control plane mechanisms will also need
+     to ensure that the service required on the aggregate flow (H-LSP or
+     DSCP) are provided, which may include the  discarding or remarking
+     mentioned in the previous sections.
+   </t>
+ </section>
+
  <section title="Bidirectional traffic">
   <t>
     Some DetNet applications generate bidirectional traffic.  Using MPLS
@@ -1007,7 +1061,7 @@ Client AC   |    NSP      |           |   
Single   | member Inst.
          Destination Option.. etc]
      </t>
  </section>
-
+
  <section title="Layer 2 addressing and QoS Considerations">
     <t>
         The Time-Sensitive Networking (TSN) Task Group of the IEEE
802.1 Working Group have
@@ -1116,7 +1170,9 @@ Client AC   |    NSP      |           |   
Single   | member Inst.
   <t>
    [Editor's note: This section is a work in progress.
    discuss here what kind of enhancements are needed for DetNet
-   and specifically for PREF and DetNet zero congest loss and latency
control.]
+   and specifically for PREF and DetNet zero congest loss and latency
+   control. Need to cover both traffic control (queuing) and connection
+   control (control plane).]
  </t>
 
  <section title="PW Label and IPv6 Flow Label assignment and distribution">
@@ -1149,6 +1205,11 @@ Client AC   |    NSP      |           |   
Single   | member Inst.
          [TBD]
      </t>
  </section>
+ <section title="Flow aggregation control">
+     <t>
+         [TBD]
+     </t>
+ </section>
 </section>

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 26 Jun 2017 12:19:45 +0000

Hi Lou,

Yes, confirm. These changes capture our discussions.

Adding the " Cross-DetNet flow resource aggregation " section provides all the necessary details.

One typo:

> 1003    use the TC field, i.e., L-LSPS or E-LSPS.  Such nodes will need to

> 1003    use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will need to

I have one concern, that our "L-Label" terminology may be confusing as it does not refer to "L-LSP".

Should we rename the “L-Label” to “H-Label” as it practically represent a tunnel between DA-*-PE

devices?

Cheers

Bala'zs

-----Original Message-----
From: Lou Berger [mailto:[email-masked]]
Sent: 2017. június 22. 18:00
To: Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] question on section 4.1

> This is an important point to capture, and not at all what I expected

> from what was written. I think there was some text on this in the

> Alternatives document. I'll try to pull it over into a new subsection

> of additional considerations.

    Fix a typo

diff --git a/draft-dt-detnet-dp-sol-01.xml b/draft-dt-detnet-dp-sol-01.xml index ef6a5c1..19f5672 100755

+--------+   | System

   Each node (edge, relay and transit) use a local-ID of the DetNet-(compound)-flow in

   order to accomplish its role during transport. Recognizing the DetNet flow is more

   relaxed for edge and relay nodes, as they are fully aware of both the DetNet

-  service and transport layers. The DetNet role of intermediate transport nodes is

transport nodes is

   limited to ensuring congestion protection and latency control for the above listed DetNet

   functions.

-  specific fields (e.g., in case of MPLS the PW label). Therefore, identifying each

-  individual DetNet flow on a transit node may not be achieved in some network

-  scenarios.

+ </t>

+ <t>

  </t>

  <t>

| member Inst.

(RSVP) and

     </t>

     <t>

| member Inst.

    </t>

    <t>

| member Inst.

   </t>

  </section>

-

anchor="Aggregation">

+   <t>

+   </t>

+   <t>

+     service is preserved.

+   </t>

+   <t>

+   </t>

+   <t>

control

+   </t>

+ </section>

+

   <t>

Single   | member Inst.

      </t>

  </section>

-

+

     <t>

802.1 Working Group have

Single   | member Inst.

   <t>

control.]

  </t>

Single   | member Inst.

          [TBD]

      </t>

  </section>

+     <t>

+         [TBD]

+     </t>

+ </section>

</section>

---

From: Lou Berger <[email-masked]>
Date: Mon, 26 Jun 2017 09:11:18 -0400

> all the necessary details.
great
> > 1003    use the TC field, i.e., L-LSPs or E-LSPs.  Such nodes will
okay, I'll fix this.

> it does not refer to "L-LSP".
I completely agree.

> represent a tunnel between DA-*-PE
I think S-Label or Svc-Label would be better as it is aligned with
Figure 12 of RFC5921 and also represents a label added as part of
supporting the DetNet Service.

Thanks,
Lou

BTW the following comment is in the xml

    <!-- LB: why is this called L-Label, I think it'll be confused with
         the current DiffServ L-LSPs, perhaps a using "(S)vc" would be
         better and is aligned with Figure 12 of RFC5921  -->

> diff --git a/draft-dt-detnet-dp-sol-01.xml
> b/draft-dt-detnet-dp-sol-01.xml index ef6a5c1..19f5672 100755
>

---

From: Balázs Varga A <[email-masked]>
Date: Mon, 26 Jun 2017 13:54:24 +0000

+1 vote for S-Label. (I have read the txt version, so I have missed your comment ... )
Cheers Bala'zs

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 2017. június 26. 15:11
To: Balázs Varga A <[email-masked]>; [email-masked]
Subject: Re: [Detnet-dp-dt] question on section 4.1

great
okay, I'll fix this.

I completely agree.

> represent a tunnel between DA-*-PE
I think S-Label or Svc-Label would be better as it is aligned with Figure 12 of RFC5921 and also represents a label added as part of supporting the DetNet Service.

Thanks,
Lou

> +  service and transport layers. The primary DetNet role of 
> + intermediate
>
> transport nodes is
>
> + provide service on per-flow DetNet identifiers. Therefore, 
> + identifying
>
> +     RSVP-TE <xref target="RFC3209"/> and <xref target="RFC3473"/>.  
> + The
>
> +     resource control, into a larger aggregate is an important 
> + technique
>
> +     control planes.  This document identifies the traffic 
> + identification
>
> +     DetNet flows transported via MPLS can leverage MPLS-TE's 
> + existing
>
> +     target="RFC4206"/>.  H-LSPs are typically used to aggregate 
> + control
>
> +     and resources, they may also be used to provide OAM or 
> + protection
>
> +     for the aggregated LSPs.  Arbitrary levels of aggregation 
> + naturally
>
> +     falls out of the definition for hierarchy and the MPLS label 
> + stack
>
> +     <xref target="RFC3032"/>.  DetNet nodes which support 
> + aggregation
>
> +     field, i.e., L-LSPS or E-LSPS.  Such nodes will need to ensure 
> + that
>
> +     traffic from aggregated LSPs are placed 
> + (shaped/policed/enqueued)
>
> +     options, due to the available traffic flow identification fields 
> + of
>
> +     the IP solution.  One available approach is to manage the 
> + resources
>
> +     associated with a DSCP identified traffic class and to map 
> + (remark)
>
> +     individually controlled DetNet flows onto that traffic class.  
> + This
>
> +     approach also requires that nodes support aggregation ensure 
> + that
>
> +     traffic from aggregated LSPs are placed 
> + (shaped/policed/enqueued)
>
> +     documents.  Management and control plane mechanisms will also 
> + need
>
> +     to ensure that the service required on the aggregate flow (H-LSP 
> + or
>
> +     DSCP) are provided, which may include the  discarding or 
> + remarking
>
> +   control. Need to cover both traffic control (queuing) and 
> + connection
>

---

From: "Jouni" <[email-masked]>
Date: Mon, 26 Jun 2017 20:00:22 +0300

WFM.

> From: Detnet-dp-dt [mailto:[email-masked]] On Behalf Of
> Balázs Varga A
> Sent: Monday, June 26, 2017 16:54 PM
> To: Lou Berger <[email-masked]>; [email-masked]
> I think S-Label or Svc-Label would be better as it is aligned with Figure
> 12 of RFC5921 and also represents a label added as part of supporting the
> DetNet Service.
> 
> Thanks,
> Lou
>