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

[Balázs Varga A <[e-mail]>]

+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:[e-mail]] 
Sent: 2017. június 26. 15:11
To: Balázs Varga A <[e-mail]>om>; [e-mail]
Subject: Re: [Detnet-dp-dt] question on section 4.1



On 6/26/2017 8:19 AM, Balázs Varga A wrote:
>
> Hi Lou,
>
>  
>
> Yes, confirm. These changes capture our discussions.
>
> Adding the " Cross-DetNet flow resource aggregation " section provides 
> all the necessary details.
>
>  
>
great
>
> 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
>
>  
>
okay, I'll fix this.

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

> Should we rename the “L-Label” to “H-Label” as it practically 
> represent a tunnel between DA-*-PE
>
> devices?
>
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  -->



>  
>
> Cheers
>
> Bala'zs
>
>  
>
> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: 2017. június 22. 18:00
> To: Balázs Varga A <[e-mail]>om>; 
> [e-mail]
> Subject: Re: [Detnet-dp-dt] question on section 4.1
>
>  
>
>  
>
>  
>
> On 6/21/2017 8:34 AM, Lou Berger wrote:
>
> > 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
>
> > 
>
>  
>
> 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>
>
>  
>