Re: [Detnet] DetNet - Migration path

"Grossman, Ethan A." <eagros@dolby.com> Fri, 07 October 2016 20:21 UTC

Return-Path: <prvs=1088c9010c=eagros@dolby.com>
X-Original-To: detnet@ietfa.amsl.com
Delivered-To: detnet@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB0412966C for <detnet@ietfa.amsl.com>; Fri, 7 Oct 2016 13:21:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.621
X-Spam-Level:
X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 kNvJHVqzdkjY for <detnet@ietfa.amsl.com>; Fri, 7 Oct 2016 13:21:35 -0700 (PDT)
Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92ABB129410 for <detnet@ietf.org>; Fri, 7 Oct 2016 13:21:35 -0700 (PDT)
Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u97KK6Fk031540; Fri, 7 Oct 2016 13:21:35 -0700
Received: from dlb-xchpw04.dolby.net (dcd-outbound.dolby.com [67.216.187.124]) by mx0a-000fd501.pphosted.com with ESMTP id 25wjfxuc6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 07 Oct 2016 13:21:35 -0700
Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW04.dolby.net (10.233.7.4) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 7 Oct 2016 13:21:08 -0700
Received: from DLB-XCHPW03.dolby.net ([10.103.9.186]) by DLB-XCHPW03.dolby.net ([10.103.9.186]) with mapi id 15.00.1210.000; Fri, 7 Oct 2016 13:21:08 -0700
From: "Grossman, Ethan A." <eagros@dolby.com>
To: Rodney Cummings <rodney.cummings@ni.com>, "detnet@ietf.org" <detnet@ietf.org>
Thread-Topic: DetNet - Migration path
Thread-Index: AdIgvkdlhjCePJ4uTnmkqpgisHkSYwABeyngAATYncA=
Date: Fri, 07 Oct 2016 20:21:08 +0000
Message-ID: <9f45b25660254b6ba5aba48808723589@DLB-XCHPW03.dolby.net>
References: <857af1285c294744ae69f939e2a991cf@DLB-XCHPW03.dolby.net> <BN1PR04MB424C95BAB740059BFF03FE392C60@BN1PR04MB424.namprd04.prod.outlook.com>
In-Reply-To: <BN1PR04MB424C95BAB740059BFF03FE392C60@BN1PR04MB424.namprd04.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.233.7.60]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-10-07_09:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/detnet/t-XM7H8w_StI8HKgbgqty9G9YQw>
Subject: Re: [Detnet] DetNet - Migration path
X-BeenThere: detnet@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussions on Deterministic Networking BoF and Proposed WG <detnet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/detnet>, <mailto:detnet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/detnet/>
List-Post: <mailto:detnet@ietf.org>
List-Help: <mailto:detnet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/detnet>, <mailto:detnet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 Oct 2016 20:21:37 -0000

Thanks Rodney. On a peripherally related note, one thing you mention below about 802.1Qcc is "the user ... requests a maximum latency". In another current DetNet discussion there is the distinction between the user requesting a specific latency (presumably implying a reply from the network saying whether it was available or not) vs only being able to query the network about its latency performance. I thought we were converging on the latter model, but now I'm not as clear. Am I missing something here? 
Thanks,
Ethan. 

-----Original Message-----
From: Rodney Cummings [mailto:rodney.cummings@ni.com] 
Sent: Friday, October 07, 2016 11:23 AM
To: Grossman, Ethan A.; detnet@ietf.org
Subject: RE: DetNet - Migration path

Great topic,

I'm not completely clear on what it would mean for a router to support DetNet, but let's assume it means that the router:
1. Uses one of the solutions from draft-dt-detnet-dp-alt to identify flows of DetNet data.
2. Uses queuing/shaping/scheduling techniques from 802.1Q to provide DetNet guarantees for that data (e.g. max latency).
3. Provides YANG management for #1 and #2.

All of this could be done today using vendor-specific YANG modules, with centralized network management software from that vendor. That's not ideal of course, but it is useful.

How would a user application (protocol from draft-ietf-detnet-use-cases) use this?

I would argue that the user applications should use the "API" specified in 802.1Qcc clause 46 (currently in draft). That API is agnostic of layer 2/3 details and the data-plane encoding. The user simply identifies the flows from the host perspective (e.g. UDP header fields), and requests a maximum latency. The API is used between the user's application and the centralized network management software. The API specifies YANG, so it can be implemented as a RESTful API or similar.

AVnu Alliance's goal is to certify conformance to standards (i.e. multiple vendors).

Can AVnu Alliance certify the vendor-specific router implementation? No Can AVnu Alliance certify the 802.1Qcc API between the user application and the vendor-specific network manager? Yes As time goes on and DetNet standards are published, can AVnu Alliance certification do deeper into the routers? Yes

That's one hypothetical intermediate plan.

Rodney

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Friday, October 7, 2016 12:42 PM
To: detnet@ietf.org
Subject: [Detnet] DetNet - Migration path

Hi Folks,
 
I did a brief "DetNet Status" presentation to the AVnu Alliance Technical Working Group, which is an industry group that promotes AVB/TSN. The attendance at this particular meeting was mostly Pro Audio people, and their main line of questioning was "What is the plan for incrementally migrating users from where they are today to increasingly improved network performance, which would eventually culminate in "full DetNet"?"  Another way to put it might be "Can we leverage the work of DetNet to improve networking capabilities between now and when DetNet is implemented on most routers?"  
 
As far as I know, we don't have a plan to roll out a "migration path" with intermediate performance levels, using today's protocols, perhaps with "minor" changes to support DetNet. We are designing an architecture and protocol extensions that will do the job, leveraging existing  protocols to the extent possible, but it is an end goal, not a roadmap. 
 
Having said that, do we have any other more helpful reply to this line of questioning? 
 
Thanks,
Ethan.