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
- [Detnet-dp-dt] question on section 4.1 Lou Berger
- Re: [Detnet-dp-dt] question on section 4.1 Balázs Varga A
- Re: [Detnet-dp-dt] question on section 4.1 Lou Berger
- Re: [Detnet-dp-dt] question on section 4.1 Lou Berger
- Re: [Detnet-dp-dt] question on section 4.1 Balázs Varga A
- Re: [Detnet-dp-dt] question on section 4.1 Lou Berger
- Re: [Detnet-dp-dt] question on section 4.1 Balázs Varga A
- Re: [Detnet-dp-dt] question on section 4.1 Jouni