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

"Jouni" <jouni.nospam@gmail.com> Mon, 26 June 2017 17:00 UTC

Return-Path: <jouni.nospam@gmail.com>
X-Original-To: detnet-dp-dt@ietfa.amsl.com
Delivered-To: detnet-dp-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD7A112EA74 for <detnet-dp-dt@ietfa.amsl.com>; Mon, 26 Jun 2017 10:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sSCgrPSU5fqK for <detnet-dp-dt@ietfa.amsl.com>; Mon, 26 Jun 2017 10:00:25 -0700 (PDT)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC094129B7A for <Detnet-dp-dt@ietf.org>; Mon, 26 Jun 2017 10:00:25 -0700 (PDT)
Received: by mail-pg0-x233.google.com with SMTP id j186so2966783pge.2 for <Detnet-dp-dt@ietf.org>; Mon, 26 Jun 2017 10:00:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=KF/I3aaoVb0WCryU5At/RGTXhWttafypdslBzmxI07o=; b=AbMqzPjvpfMK1AjG7Jo3e5FEWArrWdT6wYlw66E77zoGElWTD9A5Tu3/r+xDqRKhlH 5wp4CRMy5XmQyknt6nbwiVXRf1BNtoDBnnfwR9lIeHUaRbWMniDtzLJMN3rjRdn3/vyM GOnM+nMmAoYbxw9Itq+4S4/o+ngrB125o4V6HIg12SrLetEHdSbTdlNTY4+ZEEMrADz2 Cu0i8PP9UI3BZqQejY/so9Yy9MBDTsiNyslPNMuJnQ3NWXFPXlEXPiT93jJsXt4jwkNl MHSkpVUrJY1bSnSi8qcXSzgth9Df8E5+zpiWf/wjNv3ZSWfGiyYP9ZhG0xBlrwY/xn7A GAVg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=KF/I3aaoVb0WCryU5At/RGTXhWttafypdslBzmxI07o=; b=b4VKpKNSh5toUjZMubEzxsnE6XJv9xx/BN7W1iVxwqDVzxq1NlWP/cIFI8krro1sVT d8X1tPdYt7aBFiwDXVDnR+xcV4OrQ4uQ4uNw3EgCWcVO030PRdpFEU4+d4nPppCymyD/ /D5exSeUr1BVj3XipMJ+v/RGDzVAAkE2qlMZ+F7F9vrnVZ90hYX91sI4oy3B5vLujEKO hS3OHlE5GIr8rSynrCPnhHtrYf8kJHqcCzo3Iv5RfyheqG58TZKv8fsoJHWwDcKsCxZl QdUotI+mnahtWGaQKhhSluc6gFs9nbXD2U+nSU35qYMSddM4LM75cleVTfjrQQkHZYGs N+cw==
X-Gm-Message-State: AKS2vOxgmB7RkWWFPKk8wMR7FBhnYzkOQZOuWohV3+GJXFzC8c7305IM AQE8mQP5KpzMng==
X-Received: by 10.84.232.207 with SMTP id x15mr1167056plm.173.1498496425339; Mon, 26 Jun 2017 10:00:25 -0700 (PDT)
Received: from JOKO ([2601:647:4200:e520:f954:f5be:cbcc:4249]) by smtp.gmail.com with ESMTPSA id l63sm1053128pfc.132.2017.06.26.10.00.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Jun 2017 10:00:23 -0700 (PDT)
From: Jouni <jouni.nospam@gmail.com>
To: 'Balázs Varga A' <balazs.a.varga@ericsson.com>, 'Lou Berger' <lberger@labn.net>, Detnet-dp-dt@ietf.org
References: <33e35865-2399-65f8-b52f-c7b82c64e842@labn.net> <DBXPR07MB128751366F6D337CF9137EEACDA0@DBXPR07MB128.eurprd07.prod.outlook.com> <15ccaa5ab90.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <f1ffad76-8d9e-c403-ecea-5fd83a867b58@labn.net> <DBXPR07MB12826257D3FF8F484F63BEDACDF0@DBXPR07MB128.eurprd07.prod.outlook.com> <67297b37-698f-d714-0930-61ecf83c6b23@labn.net> <DBXPR07MB1289EDACB8A9356D6DBF978ACDF0@DBXPR07MB128.eurprd07.prod.outlook.com>
In-Reply-To: <DBXPR07MB1289EDACB8A9356D6DBF978ACDF0@DBXPR07MB128.eurprd07.prod.outlook.com>
Date: Mon, 26 Jun 2017 20:00:22 +0300
Message-ID: <054801d2ee9d$b3d65510$1b82ff30$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQJn75mNZHUd2sgjmFx0Qv6mHHEfxAGPZwQZAmVNl/EBr4mMugGhZI/RAY0Ngy8BIoZRNKC9snbw
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet-dp-dt/Q90GqWpFv9nozGCb9Z9VUEUWMkY>
Subject: Re: [Detnet-dp-dt] question on section 4.1
X-BeenThere: detnet-dp-dt@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DetNet WG Data Plane Design Team <detnet-dp-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet-dp-dt/>
List-Post: <mailto:detnet-dp-dt@ietf.org>
List-Help: <mailto:detnet-dp-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet-dp-dt>, <mailto:detnet-dp-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Jun 2017 17:00:29 -0000

WFM.

> -----Original Message-----
> From: Detnet-dp-dt [mailto:detnet-dp-dt-bounces@ietf.org] On Behalf Of
> Balázs Varga A
> Sent: Monday, June 26, 2017 16:54 PM
> To: Lou Berger <lberger@labn.net>; Detnet-dp-dt@ietf.org
> Subject: Re: [Detnet-dp-dt] question on section 4.1
> 
> +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:lberger@labn.net]
> Sent: 2017. június 26. 15:11
> To: Balázs Varga A <balazs.a.varga@ericsson.com>; Detnet-dp-dt@ietf.org
> 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:lberger@labn.net]
> > Sent: 2017. június 22. 18:00
> > To: Balázs Varga A <balazs.a.varga@ericsson.com>;
> > Detnet-dp-dt@ietf.org
> > 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>
> >
> >
> >
> 
> _______________________________________________
> Detnet-dp-dt mailing list
> Detnet-dp-dt@ietf.org
> https://www.ietf.org/mailman/listinfo/detnet-dp-dt