From nobody Fri Apr 1 14:30:21 2016 Return-Path: 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 97F8C12D701 for ; Fri, 1 Apr 2016 14:30:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 Gls4KjjlUKns for ; Fri, 1 Apr 2016 14:30:18 -0700 (PDT) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (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 4FDEC12D712 for ; Fri, 1 Apr 2016 14:29:47 -0700 (PDT) Received: by mail-pf0-x22e.google.com with SMTP id e128so77961278pfe.3 for ; Fri, 01 Apr 2016 14:29:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=zpmtUb7jp1/3k/0C+AI7ZDyKwYMEvrRjReto7qaOOCs=; b=BAS+7gvRg0V6HR91qOQHPf94n8ge0EjsNaN8dxrjp512kj8t8g3ZnoDkmjweojagXE 7BS/dFu25ROzgDLbeMKvTvTuMVar+VOddYYLNZtKUS0ufLgSQnJ0IeHsT6+WkDhCJMJx zqDunq0pHlCnJyd3lZZcWzJslLldl48xcsUzk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=zpmtUb7jp1/3k/0C+AI7ZDyKwYMEvrRjReto7qaOOCs=; b=Cu7GSsByWt1rTNcB8DtvCq8HUJnB35GLynveB/gUsQVTSIPjw2+9ESjTEGk9WcEZC8 ZNjpjpHcFoNiUrP7B7L9W2GQiaGA4xqgvN/bt3O5NOJqB2WXnfosfCUIet0qgCwAVj1F 5TSb2z6j1KlPuj+sq3nSuw4E2VuhN9jtYuQ8Sa9MRVm2cAXP2TjenYetxhgLmNWPbKAN FqqCvuN1x+B2Thl5lqVNOjSoSF3jTsd8U2kd3Plymsc384sL38ZfDJie2nCyLXnj4lzG 846BA/w71c2KlVPrF5Eu9F47bu44Qkx/LFJJlHjaTP0I8xDl8mfs53D4xq2hlFQTUrjs cvxA== X-Gm-Message-State: AD7BkJKsUDB/VSuo8Y2mjdjph3LivpqnsvGdxQvS882wLELxD5FOcZwywkcdqFPfxaIryvIs X-Received: by 10.98.19.195 with SMTP id 64mr32720295pft.62.1459546186779; Fri, 01 Apr 2016 14:29:46 -0700 (PDT) Received: from [10.240.244.237] (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by smtp.gmail.com with ESMTPSA id w27sm22061878pfa.67.2016.04.01.14.29.45 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Apr 2016 14:29:45 -0700 (PDT) To: DetNet WG References: <56DDC2C1.4020305@broadcom.com> <56F047F1.3090901@broadcom.com> From: Jouni Korhonen Message-ID: <56FEE844.4090603@broadcom.com> Date: Fri, 1 Apr 2016 14:29:40 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56F047F1.3090901@broadcom.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Lou Berger , "Pat \(Patricia\) Thaler" Subject: Re: [Detnet] Draft agenda uploaded; was Re: Agenda requests for IETF95 in Buenos Aires X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2016 21:30:20 -0000 Folks, Just a reminder that remember to send your slide material to me/Lou/Pat in time. - Jouni 3/21/2016, 12:13 PM, Jouni Korhonen kirjoitti: > Folks, > > The draft agenda for IETF95 DetNet WG meeting has been uploaded: > https://www.ietf.org/proceedings/95/agenda/agenda-95-detnet > > Lou, Pat, Jouni > > > 3/7/2016, 10:04 AM, Jouni Korhonen kirjoitti: >> Folks, >> >> The preliminary agenda was published last Friday, >> seehttps://datatracker.ietf.org/meeting/95/agenda.html. DetNet WG is >> on air from 10:00 - 12:30 on Tuesday April 5th in Buen Ayre A. >> >> If you'd like to have a presentation slot in Buenos Aires, please send >> a request to the chairs and me by Friday March 18th. Also pay >> attention to the important dates listed below. Specifically, the >> document submission deadline is UTC 23:59 on March 21st. When >> requesting a slot having a draft that has alrady been seen and >> discussed on the list is highly encouraged. >> >> Any WG draft not being discussed/presented needs to a status update >> sent to the list by Sunday March 27th. Please also provide a summary >> slide by Saturday, April 2nd. >> >> We'll need all slides for presentations by Saturday, April 2nd. The >> earlier, the better, though. >> >> Cheers, >> Jouni, Lou & Pat >> >> >> 2016-03-21 (Monday): Internet Draft submission cut-off (for all >> drafts, including -00) by UTC 23:59, upload using IETF ID Submission >> Tool. >> 2016-03-21 (Monday): Draft Working Group agendas due by UTC 23:59, >> upload using IETF Meeting Materials Management Tool. >> 2016-03-25 (Friday): Early Bird registration and payment cut-off at >> UTC 23:59. >> 2016-03-28 (Monday): Revised Working Group agendas due by UTC 23:59, >> upload using IETF Meeting Materials Management Tool. >> 2016-03-28 (Monday): Registration cancellation cut-off at UTC 23:59. >> 2016-04-01 (Friday): Final Pre-Registration and Pre-Payment cut-off at >> 17:00 local meeting time. >> 2016-04-03 - 2016-04-08: IETF 95 in Buenos Aires, Argentina >> > From nobody Sat Apr 2 03:48:45 2016 Return-Path: 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 D5B1612D770 for ; Sat, 2 Apr 2016 03:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 pdUfSOD0NvO5 for ; Sat, 2 Apr 2016 03:48:41 -0700 (PDT) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) by ietfa.amsl.com (Postfix) with SMTP id 9CF1C12D76E for ; Sat, 2 Apr 2016 03:48:41 -0700 (PDT) Received: (qmail 13809 invoked by uid 0); 2 Apr 2016 10:48:41 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy10.mail.unifiedlayer.com with SMTP; 2 Apr 2016 10:48:41 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id dVoZ1s0032SSUrH01VocTb; Sat, 02 Apr 2016 11:48:38 -0600 X-Authority-Analysis: v=2.1 cv=Maz/5fPf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=-NfooI8aBGcA:10 a=qqXk6dxrMykA:10 a=kziv93cY1bsA:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=KxafS7LfTB6AemBfankA:9 a=CjuIK1q_8ugA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From; bh=cFL+PJF2TYatvAsCG/8mmA0mYWWAX2un1YTE8OtD/i0=; b=MX7cDDGRX4NgRiNS6om+JF3VeR ACeHKhrpUhOnuctftz0WfVpCQgkcak4teirPiwfBw1RfcA6Y4RzUgSYKlRHx3XcyC9ugn5zgTx3hl JGkdMVuZ3C0btSb4M1h0/CecI; Received: from [100.15.91.238] (port=58106 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1amJ6Z-0007PH-V0; Sat, 02 Apr 2016 04:48:36 -0600 From: Lou Berger To: DetNet WG Date: Sat, 02 Apr 2016 06:48:33 -0400 Message-ID: <153d696afe8.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <56EC8C60.8060308@labn.net> References: <56EC8C60.8060308@labn.net> User-Agent: AquaMail/1.6.1.5 (build: 26000005) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.91.238 authed with lberger@labn.net} Archived-At: Cc: DetNet Chairs Subject: Re: [Detnet] WG adoption poll draft-finn-detnet-problem-statement X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2016 10:48:44 -0000 All, This poll is complete and the document is adopted, Authors, Please resubmit the draft with the only change being to rename the draft to draft-ietf-detnet-problem-statement-00. Thank you! Lou (and Pat) On March 18, 2016 7:17:36 PM Lou Berger wrote: > All, > > This is start of a two week poll on making > draft-finn-detnet-problem-statement-05 a working group document. Please > send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd > like to see addressed once the document is a WG document. > > The poll ends April 1, 2016 > > Thanks, > > Lou and Pat > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Sun Apr 3 18:19:59 2016 Return-Path: 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 4F03512D103 for ; Sun, 3 Apr 2016 18:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 MySdXxP6xCz3 for ; Sun, 3 Apr 2016 18:19:56 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD45B12D11A for ; Sun, 3 Apr 2016 18:19:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10322; q=dns/txt; s=iport; t=1459732795; x=1460942395; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=LGUwqIdCbCxQ7zRi87syCRhlWypb0WS14HsQU4Z8aQc=; b=NmfLo+0xZaZcYfYi0mLZyDWC0Hyu8HD/im0b4kWFMkvp9Mq4mQJo9fHq q9f1ym2aEDE2fSBpkqWDmuabnLLsiEMiekFvVJndBJcCKKmmb40AOfsVt OHHIJwSzVs4guSK9smCg2CKFBtaWo9qmTOkMCW/TA7uO2cURMVgQnAgZi M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAgAQwAFX/4oNJK1dgmtMU30GhB23A?= =?us-ascii?q?QENgXIhhWwCgSU4FAEBAQEBAQFlJ4RBAQEBBC1cAgEIEQECAQIoBzIUAwYIAgQ?= =?us-ascii?q?BEh+ICA67NgEBAQEBAQEBAQEBAQEBAQEBAQEBAREEhiCESoQjPA2FKQWOBYUTh?= =?us-ascii?q?GkBhXKIFYFohE2DKIUyjxkBHgEBQoIEGRWBNWyHDH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,438,1454976000"; d="scan'208,217";a="256156497" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Apr 2016 01:19:54 +0000 Received: from XCH-RTP-018.cisco.com (xch-rtp-018.cisco.com [64.101.220.158]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u341JrXL013778 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 4 Apr 2016 01:19:54 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-018.cisco.com (64.101.220.158) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 3 Apr 2016 21:19:53 -0400 Received: from xch-rtp-014.cisco.com ([64.101.220.154]) by XCH-RTP-014.cisco.com ([64.101.220.154]) with mapi id 15.00.1104.009; Sun, 3 Apr 2016 21:19:53 -0400 From: "Patrick Wetterwald (pwetterw)" To: "Norman Finn (nfinn)" , "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Cases - Starting the "what is in scope for DetNet" discussion Thread-Index: AQHRjhAXdmYRz87R/UiPBDiPX/UXow== Date: Mon, 4 Apr 2016 01:19:53 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.79.100] Content-Type: multipart/alternative; boundary="_000_D327458A68FA4pwetterwciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Cases - Starting the "what is in scope for DetNet" discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 01:19:58 -0000 --_000_D327458A68FA4pwetterwciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ethan, Norm, Agree for the non support of the Big-I Internet with the following precisio= n: Utilities may ask a SP to provide them with a "deterministic" link (like= a leased line) with a guarantee of max delay, Jitter and packet loss. But= I guess this use case is included in "enterprise" right ? Thanks, Patrick From: detnet > on b= ehalf of "Norman Finn (nfinn)" > Date: Thursday 31 March 2016 at 19:46 To: "Grossman, Ethan A." >, "detn= et@ietf.org" > Subject: Re: [Detnet] DetNet Use Cases - Starting the "what is in scope for= DetNet" discussion Ethan, Making DetNet work over the Big-I Internet is not one of my goals, at least= . I often use the term "enterprise" for the scope in which I'm interested. Timekeeping is an essential part of many, probably most, of the application= s that also find DetNet useful. That having been said, so is protection ag= ainst EMI and electrical power saving. Let's concentrate DetNet on reliable= , on-time delivery of packets. I'm not even sure that "a way to specify th= e required accuracy" need be in scope. - Norm From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Tuesday, March 29, 2016 at 12:13 PM To: "detnet@ietf.org" > Subject: [Detnet] DetNet Use Cases - Starting the "what is in scope for Det= Net" discussion Hi Folks, I claim that we have brought the DetNet Use Cases draft up to a state where= I can say with a straight face "please read this document, it won't hurt y= ou". So if you haven't already done so, please look it over. https://tools.ietf.org/html/draft-ietf-detnet-use-cases-09 Moving on to the next step, we need to start the discussion on which aspect= s of the use cases will be within scope of the DetNet work. Or, perhaps it = is easier to enumerate which ones are not in scope, at least for a start. The most obvious first item to decide on is requests to have DetNet work on= the open Internet - I think we're pretty clear that that is "not in scope"= because our architecture depends on there being "centralized control" (whi= ch may be distributed among multiple network entities, but which together c= onstitute a single point of control). I have also heard this phrased as "co= rporate networks". Do we agree on this? Another example is timekeeping - this will be specified by other existing m= eans, right? The only explicit DetNet Ask for this is in M2M as "Precise ti= me synchronization accuracy (1us)" and I think the intent (as in other use = cases) is that the DetNet Ask is for a way to specify the required accuracy= , not how to achieve that accuracy. Anyone else see anything that might not be in scope? I plan to ask this que= stion in the Use Cases part of the IETF session, so if you have any thought= s please send them to the list (or if that doesn't happen, bring them to th= e live discussion). Thanks, Your faithful Use Cases Editor, Ethan. --_000_D327458A68FA4pwetterwciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <61F46FE79E13464EAA7EBB096487B1F3@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Ethan, Norm,

Agree for the non support of the Big-I Internet with the following pre= cision: Utilities may ask a SP to provide them with a “deterministic&= #8221; link (like a leased line) with a guarantee of max delay,  Jitte= r and packet loss. But I guess this use case is included in “enterprise” right ?

Thanks,

Patrick

From: detnet <detnet-bounces@ietf.org> on behalf of "= ;Norman Finn (nfinn)" <nfinn@cis= co.com>
Date: Thursday 31 March 2016 at 19:= 46
To: "Grossman, Ethan A." = <eagros@dolby.com>, "detnet@ietf.org" <detnet@ietf.org>
Subject: Re: [Detnet] DetNet Use Ca= ses - Starting the "what is in scope for DetNet" discussion

Ethan,

Making DetNet work over the Big-I Internet is not one of my goals, at = least.  I often use the term “enterprise” for the scope in= which I’m interested.

Timekeeping is an essential part of many, probably most, of the applic= ations that also find DetNet useful.  That having been said, so is pro= tection against EMI and electrical power saving. Let’s concentrate De= tNet on reliable, on-time delivery of packets.  I’m not even sure that “a way to specify the required ac= curacy” need be in scope.

— Norm

From: detnet <detnet-bounces@ietf.org> on behalf of "= ;Grossman, Ethan A." <eagros@do= lby.com>
Date: Tuesday, March 29, 2016 at 12= :13 PM
To: "detnet@ietf.org" <= detnet@ietf.org>
Subject: [Detnet] DetNet Use Cases = - Starting the "what is in scope for DetNet" discussion

Hi Folks,
 
I claim that we have brought the DetNet Use Cases draft up to a state = where I can say with a straight face “please read this document, it w= on’t hurt you”. So if you haven’t already done so, please= look it over.
 
 
Moving on to the next step, we need to start the discussion on which a= spects of the use cases will be within scope of the DetNet work. Or, perhap= s it is easier to enumerate which ones are not in scope, at least for a start.
 
The most obvious first item to decide on is requests to have DetNet wo= rk on the open Internet – I think we’re pretty clear that that = is “not in scope” because our architecture depends on there bei= ng “centralized control” (which may be distributed among multiple network entities, but which together constitute a single point of= control). I have also heard this phrased as “corporate networks̶= 1;. Do we agree on this?
 
Another example is timekeeping – this will be specified by other= existing means, right? The only explicit DetNet Ask for this is in M2M as = “Precise time synchronization accuracy (1us)” and I think the i= ntent (as in other use cases) is that the DetNet Ask is for a way to specify the required accuracy, not how to achieve that acc= uracy.
 
Anyone else see anything that might not be in scope? I plan to ask thi= s question in the Use Cases part of the IETF session, so if you have any th= oughts please send them to the list (or if that doesn’t happen, bring= them to the live discussion).
 
Thanks,
Your faithful Use Cases Editor,
Ethan.
 
 
 
 --_000_D327458A68FA4pwetterwciscocom_-- From nobody Sun Apr 3 18:28:30 2016 Return-Path: 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 2993712D103 for ; Sun, 3 Apr 2016 18:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 4I8JYOBuhQDo for ; Sun, 3 Apr 2016 18:28:26 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4A8412D0E6 for ; Sun, 3 Apr 2016 18:28:26 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u341Pwkf032765 for ; Sun, 3 Apr 2016 18:28:26 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 222xg4rk3s-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Sun, 03 Apr 2016 18:28:26 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Sun, 3 Apr 2016 18:28:24 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Sun, 3 Apr 2016 18:28:23 -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.1076.000; Sun, 3 Apr 2016 18:28:23 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Cases preso preview Thread-Index: AdGODeU7MEUMZ7ffRuSIoq27Ee+oLQ== Date: Mon, 4 Apr 2016 01:28:23 +0000 Message-ID: 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.207.133.62] Content-Type: multipart/alternative; boundary="_000_c3eeffa9ce5a495b9cdf01d38f61fd5bDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-03_11:2016-04-01,2016-04-03,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Cases preso preview X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2016 01:28:29 -0000 --_000_c3eeffa9ce5a495b9cdf01d38f61fd5bDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, To provide a little advance time for thought, here is what I am planning fo= r the DetNet Use Cases time slot on Tuesday. I went through the Use Cases draft 09 and singled out any statements for wh= ich I couldn't see a direct correspondence to the Problem Statement and/or = Architecture drafts, and I enumerated them so that we could identify sooner= rather than later any meaningful gaps between the expectations of the use = case authors and the intentions of the architects. Admittedly there are twenty-something statements in my list (reproduced bel= ow from my PPT preso) so we probably won't get through all of them, however= presumably most of them are either "obvious" or would be obvious given a b= etter understanding of the significance of the statements, which I confess = I don't necessarily always have. So I expect we can "hand wave" through a = bunch of them as long as the room/list is content with the collective under= standing of the statement and its implications. But even if we flush out only a couple of real items from the bunch I think= it will have been a worthwhile exercise. So what I plan to do is go throug= h the statements "in order" (which is the order they appear in the draft) b= ut first I'll ask if anyone has a particular one(s) that they believe to be= "significant" such that we should make sure we get to it (i.e. start with = it). And of course if you want to respond to this thread that would be enti= rely appropriate. Best, Ethan. P.S. I also need to apologize in advance for not proofreading my PPT slides= as well as I should have, as I have since noted there are some typos and o= missions (such as I accidentally left Janos Farkas off the Authors list on = the first slide - sorry bro!) ------------------------------------------- The Open Internet - (not in scope) -->But does future planning for this affect DetNet? Providing Synchronized Time (not in scope) Plug-And-Play (case of new device, case of replace e.g. failed device) Stream Start-up (or re-start) Time Link Authentication/Encryption (Pro Audio case of specific protocols) Link Aggregation Latency matching - single- or bi-directional Traffic Segregation (multicast to many devices) DetNet consideration of 6TiSCH expectations: path set/get protocol, must be direct from/to PCE (vs along path) Push neighbor info to PCE over CoAP? CoAP: Constrained Application Protocol [RFC 7252] Multiple metrics same as RPL Ops (RFC6551) One-Shot vs Update of paths (e.g. at runtime due to malfunctioning de= vice) Read energy data from devices (app layer?) Extensible protocol - vendor specific? ARQ protocol (auto retry, specific to wireless) DetNet consistency with 802 TSN Hard or soft requirement? Delay accuracy +/-8ns (jitter?) --> Jouni says "yes, jitter" so that's clea= r now, but still a small value, which caught my eye. Transport contrib to RF error +/- 2PPB (2ns) Security must allow for long leases Data plane xport std "unified among xhauls" Is there any special meaning to this for DetNet? --> (Jouni says "This boils down to traffic and resource isolation i.e., = different flows with diverse "DetNet" requirements have to coexists in the = same network and traverse the same nodes without interfering each other." -= -> So AFAICT there is no disconnect there, i.e. this is supported by the pr= oposed architecture. ------------------------------------------- --_000_c3eeffa9ce5a495b9cdf01d38f61fd5bDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
 
To provide a little advance time for thought, here is what I am planni= ng for the DetNet Use Cases time slot on Tuesday.
 
I went through the Use Cases draft 09 and singled out any statements f= or which I couldn’t see a direct correspondence to the Problem Statem= ent and/or Architecture drafts, and I enumerated them so that we could iden= tify sooner rather than later any meaningful gaps between the expectations of the use case authors and the intentions of= the architects.
 
Admittedly there are twenty-something statements in my list (reproduce= d below from my PPT preso) so we probably won’t get through all of th= em, however presumably most of them are either “obvious” or wou= ld be obvious given a better understanding of the significance of the statements, which I confess I don’t necessarily a= lways have.  So I expect we can “hand wave” through a bunc= h of them as long as the room/list is content with the collective understan= ding of the statement and its implications.
 
But even if we flush out only a couple of real items from the bunch I = think it will have been a worthwhile exercise. So what I plan to do is go t= hrough the statements “in order” (which is the order they appea= r in the draft) but first I’ll ask if anyone has a particular one(s) that they believe to be “significant” s= uch that we should make sure we get to it (i.e. start with it). And of cour= se if you want to respond to this thread that would be entirely appropriate= .
 
Best,
Ethan.
 
P.S. I also need to apologize in advance for not proofreading my PPT s= lides as well as I should have, as I have since noted there are some typos = and omissions (such as I accidentally left Janos Farkas off the Authors lis= t on the first slide – sorry bro!)
 
-------------------------------------------
The Open Internet – (not in scope)
àBut does future planning for = this affect DetNet?
Providing Synchronized Time (not in scope)
Plug-And-Play (case of new device, case of replace e.g. failed device)=
Stream Start-up (or re-start) Time
Link Authentication/Encryption (Pro Audio case of specific protocols)<= /div>
Link Aggregation
Latency matching – single- or bi-directional
Traffic Segregation (multicast to many devices)
 
DetNet consideration of 6TiSCH expectations:
path set/get protocol, must be direct fro= m/to PCE (vs along path)
Push neighbor info to PCE over CoAP?
CoAP: Constrained Application Protocol [R= FC 7252]
Multiple metrics same as RPL Ops (RFC6551= )
One-Shot vs Update of paths (e.g. at runt= ime due to malfunctioning device)
Read energy data from devices (app layer?= )
Extensible protocol – vendor specif= ic?
ARQ protocol (auto retry, specific to wir= eless)
 
DetNet consistency with 802 TSN
Hard or soft requirement?
Delay accuracy +/-8ns (jitter?) à<= /font> Jouni says “yes, jitter” so that’s clear now, but = still a small value, which caught my eye.
Transport contrib to RF error +/- 2PPB (2ns)
Security must allow for long leases
Data plane xport std ”unified among xhauls”
Is there any special meaning to this for = DetNet? à
(Jouni says “This boils down to tra= ffic and resource isolation i.e., different flows with diverse "DetNet= " requirements have to coexists in the same network and traverse the s= ame nodes without interfering each other.” &= agrave; So AFAICT there is no disconnect there, i.e. this is supported by the propo= sed architecture.
-------------------------------------------
 
 
 
 --_000_c3eeffa9ce5a495b9cdf01d38f61fd5bDLBXCHPW03dolbynet_-- From nobody Tue Apr 5 07:28:11 2016 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6449212D14D; Tue, 5 Apr 2016 07:28:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.18.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160405142808.25887.54700.idtracker@ietfa.amsl.com> Date: Tue, 05 Apr 2016 07:28:08 -0700 Archived-At: Cc: detnet@ietf.org Subject: [Detnet] I-D Action: draft-ietf-detnet-problem-statement-00.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 14:28:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking of the IETF. Title : Deterministic Networking Problem Statement Authors : Norm Finn Pascal Thubert Filename : draft-ietf-detnet-problem-statement-00.txt Pages : 15 Date : 2016-04-04 Abstract: This paper documents the needs in various industries to establish multi-hop paths for characterized flows with deterministic properties . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-problem-statement/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-detnet-problem-statement-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 5 08:37:06 2016 Return-Path: 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 E380B12D640 for ; Tue, 5 Apr 2016 08:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 9qW2x7ZHoLXU for ; Tue, 5 Apr 2016 08:36:59 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) by ietfa.amsl.com (Postfix) with SMTP id 7462C12D618 for ; Tue, 5 Apr 2016 08:36:59 -0700 (PDT) Received: (qmail 22181 invoked by uid 0); 5 Apr 2016 15:36:56 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy6.mail.unifiedlayer.com with SMTP; 5 Apr 2016 15:36:56 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id efcq1s0172SSUrH01fctHk; Tue, 05 Apr 2016 09:36:55 -0600 X-Authority-Analysis: v=2.1 cv=G/WPTbU5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=uEJ9t1CZtbIA:10 a=kziv93cY1bsA:10 a=48vgC7mUAAAA:8 a=MS9lWKYfkuiWvtlPg1cA:9 a=9zNG0qTv7DA8TRpU:21 a=BrvNcVYZHl2QOEtW:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Subject:From:To; bh=zSZZydX6GbIjrH3YInjLs1Gn+wwgUxXOphny3lM+r7g=; b=TVh4JuoGqE4bg0iFQFSnenBC2bwkZhOZlUKX5EezlzZwLtdOwx0cDqQz90HSTXKRLOPzzGLKy4 at8d4JpuOT2+FLJRWwxNvEQtqwM0dbKOcsjatjOHMcCBAUcSWqaBw/; Received: from box313.bluehost.com ([69.89.31.113]:54778 helo=[127.0.0.1]) by box313.bluehost.com with esmtpa (Exim 4.86_2) (envelope-from ) id 1anT2B-0005mc-Ap for detnet@ietf.org; Tue, 05 Apr 2016 09:36:51 -0600 To: DetNet WG From: Lou Berger Message-ID: <5703DB8D.8040408@labn.net> Date: Tue, 5 Apr 2016 11:36:45 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 69.89.31.113 authed with lberger@labn.net} Archived-At: Subject: [Detnet] raw notes from session X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 15:37:06 -0000 Here are the raw notes from today's session. Please review and correct (at http://etherpad.tools.ietf.org:9000/p/notes-ietf-95-detnet). Just a reminder the notes should only cover what was actually said at mics in the session, and these are input to the final minutes. Recordings of the session is also available. Thanks to Pascal and Jouni and all others who contributed to the notes and the successful meeting! Lou and Pat > IETF-95 detnet agenda > Session 2016-04-05 1000-1230: Buen Ayre A - Audio stream - detnet chatroom > Agenda > ** IETF 95 DetNet Agenda - version 4/4/2016 ** > > Tuesday April 5, 2016 > 10:00-12:30 Tuesday Morning session I > Room: Buen Ayre A > > > Start Time Information > 10:00 (15) Title: Administrivia & Status > Presenter: Chairs > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-0.pdf Document status: 2 WG documents 1 candidate (architecture) NOtes done by Jouni, Pascal Thubert, > 10:15 (20) Title: Use cases - update > Presenter: Ethan Grossman > Draft: http://tools.ietf.org/html/draft-ietf-detnet-use-cases-08 > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-1.pdf Ethan gives the presentation of the use cases draft. Goal: provide industry context per use case, how it is addressed today and what we need from IETF for the future. Line up use cases and architecture. Ethan lists use cases, one is new, M2M for industrial, Ethan presents the use case in more details. Ethan describes classical control loop, orders of magnitude for time and volumes; expresses the requirement for a convergence to IP. Ethan lists asks to IETF in slide 10, and compiles common themes in slides 11 and 12. Slides 14-16: Looking for disconnects between existing architecture and pb statement and the use cases. Bringing the mismatches to attention, suggest discussions on the ML to resolve. Ethan lists the issues one by one to stimulate feeback Open internet: not in scope Clock sync: not in scope Plug and play: most use cases expect that the devce is pre provisionned. But then there's the failure/replacement scenario. Ethan suggests that - Stuart Bryant on Jabber: Re bullet 2 - isn't detnet useful in providing the time sync conduit - Norm Finn: people use 1588 to schedule packets. In that case, sync'ing time is a service that detnet uses. detnet may have requirements on sync time. Would be great to have that in the use cases. about P&P, if there is a use case, suggestion to write it down there. - Patrick Wetterwald: in utility there is a use case of connecting substations. They may us an SP network for that connection. Even if we do not support internet at large, we must support 2 interconnected networks. - Ethan Grossman: Noted Ethan: Link aquthentication/encryption is a service on top of detnet. Link Aggregation: streams being synchronized together - Lou Berger: what is your objective for this (slide 14 discussion) - Ethan Grossman: to raise topics that may not be covered in other documents - Subir Das: are you asking about mismatches with architecture? - Ethan: I'm listing what I'm not matching Norm Finn: the P&P is mentionned in the architectue draft about P2P protocol, havng the ability for an end system to request a service is an important compoinent for exactly that reason. Encryption: architecture says we do not want to break security, but also that detnet presents new aspects since encryption does not protect on time delivery. Link aggregagtion: so far the discussions have been about making sure a flow stay on a same path because of the need to keep packets in order. Aggregation has to place one flow on one link. - John Dowdell: is it more a question of whether current link authentication, encryption and aggregation technology does not support detnet use case, is there something that is lacking? - Ethan: exactly what we are after - Lou Berger: then a good discussion topic for the list - Pat Thaler: as contributor, plug and play is important. There are cases like A/V where there's enough bandwidth to reserve for flows along the network (note taker understanding: as opposed to central optimization). There are use cases where everything is preprogrammed and thus no issue e.g., with the start times. Link aggregation has a specific meaning at L2, there's a link aggregation standard. Having a flow along multiple path, not sure that's something we nned to involve ourselves in - Tim Chown: is this applicable to network-intensive applications that might use 1-20Gbit/s, or only for low speed, time-sensitive applications? - Ethan: no restriction on that. - Pat Thaler: - Paul ??: define how we reuse existing mechanisms of detnet, not creating new ones. (context of link agg, multicast, etc) - Pascal Thubert: I think we need to keep aggregation in scope. Putting back together a flow that was split over different paths is an extreme form on the elimination operaion that the det layer does for the replication/elimination service, where packets may be lost on either side and have to be recombined and reordered - Norm Finn: On sync between 802.1TSN. Norm Finn thinks there is enough overlap with participation to keep DetNet and 802.1TSN aligned. > (10:42 actual) > 10:35 (20) Title: DetNet service model - discussion > Presenters: Lou Berger, Balazs Varga > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-2.pdf Lou introduces chair-initiated discussions. Next two topics are chair introduced and spun off the design team and architecture document work. First topic by Balazs is related to service mode: Lou explains the distinction whether the detent service is from the end node (app/ systems) or network edge nodes (end nodes not participating). Or do we need / want both. Balazs suggests work may be needed on terminology. Flows can be of different nature, IP, ethernet, ... and end systems are connected to the network with different tyes of interfaces (L2/L3) Balazs reviews the use cases and discusses how the service models apply. In radio use case, radio and transport layers are often integrated for this service, but not for xVPN services. Discussion: - Subir Das: can you explain what links are? (on slide titled "purpose of this discussion") - Lou: this is one way to draw the line ofwhre the flows exist. Links are connections between network devices, We have P2P links and subnets in this drawing. - Subir Das: are they physical or logical? - Lou: we do not constrain that. We include exemples. - Subir Das: - Lou: if you do not like the picture tell how it should be like. - Subir Das: hopw many nodes need to run the detnet service in the network? - Lou: I understand that you favor eddge to edge (2 to 2 on the picture) - Subir yes - Norm: hope we can do it that way. the end station is expected to place the reservation and mark the packets. we have use cases today where the end piouint are requesting the service. The nodes recognize they are the specific detnet flows. end systems are makking the apckets specifically. - Lou: how does the end node see that? - Norm: I'm talking about TSN. In general, there's something in the host that is aware that there is TSN. That something is aware of 2 ports; one for normal traffic but capable to use boths. My choice is absolutely 3, both cases 1 and 2. keeping L2 and L3 separate is extremely important, bu detnet is not forwarding. A detnet service is a chain of boxes and wires and queues. They are not necessarily of one type, L2 vs. L3. The service we are offering is QoS not forwarding, not layer specific. A relay system has to pick a packet and apply a service, it does not matter which technology/layer got the packet in the relay system. - Samita Chakrabarti: TSN island conected to non-TSN island - Lou: that's a form of case 2 - SC: One edge node could host application - Lou: true. An edge node is a special case of application - SC : could be a point of policy enforcement - Lou: true - Subir Das: are we going to do detnet as an application service? - Lou: will not do a socket interface - Lou: asking the sense in the room. only one or two. Who in the room believes we should do a network box application (case 1) - few Case 2 - more - Pat Thaler: who thinks case 1 is important to cover: several hand - Pat Thaler: who thinks case 2 is important to cover: several hand (slightly more) - Lou: asks the sense of room on prioritization between case 1 and 2. Hands shown.. no real winner. > (Actual 11:08) > 10:55 (15) Title: DetNet terminology - discussion > Presenter: Norm Finn > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-3.pdf > Norm Finn on terminology discussion Norm notes that Lou contributed heavily on this slideware Norm note sthat there are many ways to nail a path down. If we pick a term taht coincides with some existing draft (eg from segment routing) it does not mean that we chose to work with segment routing. Norm shows terms that are used in various technologies. Would be nice to pick some. Another angle shows a source on the left (maybe not aware of detnet) and on the right, a listener that is aware and terminating the service. We definitely have use cases like that. Norm expresses desire to pick terms. eg determinitic flow end to end going over a detnet service <...> - Lou: pick your favorite technology - Norm: drawingissue. In the architecture we do not make a difference by layer. - Lou: you are at the detnet layer and the subnet is the network that you are using. That does not mean an IP subnet. - Norm: great. the subnet on the picture may operate at any layer, as long as it provides tha servcies that detnet needs. - Loa Andersson: why not call subnet as a detnet subnetwork. - L A where d the arrows on 7 start? - Lou: we kept the arrows endpoints vague to get the discussion going. - L A: on arrow 6 that's is clearly ending - Lou: yes because that is the end to end service 1. End system -> 2. Edge node -> 3. Network node -> 4. Sub network -> detnet sub network 5. link -> 6. Deterministic flow -> 7. DeNet Flow -> - Tim Chown: Need 2 diagrams? (one end to end, one edge to edge) It seems odd to have a 'Deterministic flow' end to end where only part of the path is a DetNet flow. - Norm Finn: confusion is that this diagram looks like a stack diagram but it is not, it is looking at the network from above. - Balazs Varga: detnet flow can be the same as deterministic flow. There are cases where they are also different and we need to be able to distinguish netween those. Thus two arrows. Norm brings up slide "simple example:..." Norm Finn: proposes that the detnet dataplane alernatives draft hs the most people working on it, and that it should be the reference to align to. - Lou Berger: good idea. We should not constrain the specifics of that yet. Would be a shame if the terminology does not align with the solution. We should start with the dataplane and keep it open. - Janos: back to both options. If we provide both, a single name becomes confusing. - Lou Berger: We will propose to follow Norm's proposal of aligning DetNet terminology with the data plane terminology > 11:10 (20) Title: DetNet architecture - update > Presenter: Norm Finn > Draft: http://tools.ietf.org/html/draft-finn-detnet-architecture-03 > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-4.pdf Norm presents architecture draft. Slides unchanged mostly from last meeting. Presents slide "objective/goals". We want to invent the least possible. There are assumptions like fixed throughput and no throttling. Norm gives a status. Biggest change is terminology, eg stream-> detnet flow, seamless redundancy became packet replication and deletion. Norm presents essential aspects. We are not talking about fault detection and remediation, which could be future work. We are talking about sending the packets twice. the model allows both end station and central controllers palcing reservations. Norm presents open issues: Norm thinks that zero congestion loss requires per flow state. TBD is the stream identification. The (dt) data plane document provides infromation on that which the architecture needs to echo. - Roland Bless: Maybe diffser could provide required quarantees. - Norm Finn: Erm no. ..goes into explaining reservations, etc. - Shahram Davari: is one of the goals not to keep the order of the packets. - Norm Finn: if you look into this we may discover that we can add as a goal easily. - Sharam Davari: it is not cheap. - Norm Finn: done at the upper layers. - Sharam Davari: diffserv is preferable and achoieveable if we shape on every node and enough buffering. - Norm Finn: if you have enough buffering and know topology diffser can do the job. In some topologies just don't do it (example of ring in indistrial) - Pat Thaler: going back to architecture.. non engineered plug and play is part of the scope. - Lou Berger: it important the architecture document does not go too much into specific implementations. - Lou Berger: one revs of the architecture and then adopt. - Norm Finn: having an architecture doc is important to keep assumptions aligned. - Tim Chown: do we want an environment with privacy support (e.g. might have dynamic L2 addresses, or 5-tuple hidden due to IPsec etc) - Lou Berger: good opportunity to look at doc and see where there are concerns and post to the list. To Norm: do you want to address comments as individual so you place your own ideas, or do you want to be the editor for the WG after adoption? - Norm Finn: Alignment is better now with terminology. Better put the call out to get opinions sooner than later. - Lou Berger: Poll -- asks how many has read the arch doc. A good number. - Lou Berger: Poll -- how many thinks it is a good basis for the WG document. More. - Lou Berger: ask Norm to do one more round to align with meeting discussions and then will call for adoption. - Lou Berger: (to WG) when supporting adoption please mention what you want addressed in the first WG rev. This raises the importantce of the issue raised. > 11:30 (30) Title: Data Plane Alternatives Design Team - report > Presenter: Jouni korhonen > Draft: https://tools.ietf.org/html/draft-dt-detnet-dp-alt-00 > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-5.pdf Jouni presents the status of the design team work on dataplane. Disclaimers, doc is far from ready, WIP. Jouni presents the design team. Jouni presents the goals, evaluate suitability of existing technologies for detnet. Also non goals: the document does not select technologies, does not consider the control plane. Jouni introduces the detnet view of layering, with a "detnet service layer" and a "detnet transport layer". This partition is used to structure the document. Jouni presents "Why?" technologies are selected and studied, which properties were found of interest for detnet services. Observes that a lot of discussion was focused on replication and deletion, which layer does what. Goal is to call for adoption after 01, which may add/remove alternatives. - Lou Berger: what should the DT do after that? Is there a logical next step? - Jouni Korhonen: Follow normal WG process - Lou Berger: people do not need to be in the DT to contribute. Send text to the chairs. Now is the time for everyone concerned to speak up. - Stewart Bryant: PWs don't really have sequencing - last slide - it's only there for the TDM PWs in practise - Uma Chundury: is goal to pick up a technology and then fix the gaps? - Jouni Korhonen: yes - Erik Normark: how would things work together, detnet and RTP - Jouni Korhonen: RTP provides services that do most of what we need here in detnet, seqencing, duplicate elimination... - Lou: there are things in the dc that will need to be thrown out. - Ilya Vershkov: packets out of order, reordering. Is that a goal? list of requirements. - Pat: we put them in order - Lou: we'll determinie wihch we are really gonna do. - Yuanlong Jiang: number 9: what do you mean? - Jouni: receiving packet that you are not supposed to received. which node is misbehaving? eg if there is duplication in the network, need to determine the node that performed the duplication. - Yuanlong Jiang: not sure we need to distinguish ??? - John Messenger: it's OAM part of time synchronization. The dataplane is the only place wwhere you can do that. - Yuanlong Jiang: time flows of MPLS packets. - Lou: yes, there's 1588 out there, discussion is whether there are gaps that we identify. If there was nothing to do we would not have a WG ;) > 12:00 (15) Title: Deterministic Networking Requirements on Data and Control Plane > Presenter: Yiyong Zha > Draft: https://tools.ietf.org/html/draft-zha-detnet-requirments-00 > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-6.pdf Yiyong Zha presents requirement draft Yiyong Zha reviews the architecture and then MPLS as a candicate to support detnet transport. Analyses open questions to get there. LSP setup. Support L2 tech such as PW. Yiyong Zha presents needs and issues for detnet flow identification, and proposes alternatives like network added. Yiyong Zha presents TSN. - Greg Mirsky: you assume that a particular technology can guarantee delay. I believe that we need performance measurement to confirm that the service level conforms SLA, else actions are to be taken. I do not think that a dataplane technology is a guarantee and removes the need for validation through measurement. - Lou little time left, comments through the list. - Lou: what goal for this doc: - Yiyong Zha: need feedback from the group for that > > 12:15 (15) Title: Integrated Mobile Fronthaul and Backhaul > Presenter: James Huang > Draft: https://tools.ietf.org/html/draft-huang-detnet-xhaul-00 > Slides: http://www.ietf.org/proceedings/95/slides/slides-95-detnet-7.pdf James Huang presents ethernet as a candidate for detnet transport (fronthaul and backhaul) and compares with others like IP and MPLS. For MPLS: missing radio over MPLS. Then discusses support of / CPRI awareness - Janos: work going on in 802.1CA (note taker: name to be confirmed) to carry Common Public Radio Interface (CPRIâ„¢) James discusses packet loss / BER impact on CPRI - Janos: again look at 802.1CA - James: yes, aware of this work - Lou: what's next - James: new version. - Lou: please look at use cases document - Lou closes the meeting (2 minutes early!!!) > 12:30 Adjourn From nobody Tue Apr 5 09:43:34 2016 Return-Path: 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 4981912D12B for ; Tue, 5 Apr 2016 09:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.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 OzxUwA4dP_If for ; Tue, 5 Apr 2016 09:43:25 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A20012D769 for ; Tue, 5 Apr 2016 09:43:25 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1lrp0010.outbound.protection.outlook.com [213.199.154.10]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-36-qOT-sE8FSwWc2Aryb6qevQ-1; Tue, 05 Apr 2016 17:43:18 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=U7MvqlmD3bhJ2qNAcxe+IpQsEIAOl0gIoXcU+nPdwuA=; b=ZQtyLlpHUc7nK2WOwpVd0zB1O/xkb8xqWWVIXNa2sICVK0g6BAytxrNmkJEoNk1YTYQ0kE27MqG2OjizHMMDGyD0FblEkjFJzY3KuOaaZHdqB7rQ2eO7eTQqqY/Ue/z1PUSWRKpRC+FtQJH7MVOKjLBK29jnHjqHr4FHvOUhUPQ= Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB456.eurprd07.prod.outlook.com (10.242.106.149) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 16:43:14 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0447.028; Tue, 5 Apr 2016 16:43:14 +0000 From: Tim Chown To: "detnet@ietf.org" Thread-Topic: detnet architecture, and privacy considerations Thread-Index: AQHRj1o/wsTj9M/QdkGwPgafJ5ZwqA== Date: Tue, 5 Apr 2016 16:43:14 +0000 Message-ID: <86494F1C-0448-4447-AE73-55C10ED86755@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3112) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [31.133.155.215] x-ms-office365-filtering-correlation-id: b7c640f3-5b9a-452c-3019-08d35d716235 x-microsoft-exchange-diagnostics: 1; AMSPR07MB456; 5:wTKGsbJrqSFdlrXs+e+3kTMsphvUvsYZifM36lr21mdfsYD3PKgSRs7KESfe+/I9k7AL3Og08GkDG0gr6iT2y/xmbhgyDYapb8cdOi7aP7iWFkgMvvhKelLtui+0BD47AM8lsmheAQfYABJNTaojOQ==; 24:G0/MKVqAv+anHwZjz9Y08EQQzJasKkDtlDo4xw4HHzgO6JkWMAsEc+UwMYsnayHOSAUTLQElz0Sxn3iXoEf8nB6USSlWkcCbmSz13nZK92I=; 20:TC70dUVzL/jcPytR1OMg1/MkOHqLS/Hlc9eZhftM+o1BTWEykNtH+0ZTpHZBSF/NPnav0C9UL0XPXH5/g0dXGg1sGaLKO6WB1U3Fn9lHraWcOLV8H8/BNg5els8Je9NG7svgLhA7ymeOb6i19Z0UrZd6vc0l8sa4aTR3M9+f3vM= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB456; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:AMSPR07MB456; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB456; x-forefront-prvs: 0903DD1D85 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(92566002)(86362001)(83716003)(74482002)(106116001)(57306001)(33656002)(82746002)(122556002)(450100001)(110136002)(107886002)(11100500001)(3660700001)(2906002)(5008740100001)(5002640100001)(50986999)(189998001)(2351001)(19617315012)(87936001)(3280700002)(229853001)(81166005)(50226001)(77096005)(1096002)(1220700001)(6116002)(102836003)(3846002)(1730700002)(15975445007)(5640700001)(5004730100002)(66066001)(36756003)(2900100001)(10400500002)(19580395003)(586003)(2501003)(16236675004); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB456; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Apr 2016 16:43:14.9087 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB456 X-MC-Unique: qOT-sE8FSwWc2Aryb6qevQ-1 Content-Type: multipart/alternative; boundary="_000_86494F1C04484447AE7355C10ED86755jiscacuk_" Archived-At: Subject: [Detnet] detnet architecture, and privacy considerations X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2016 16:43:30 -0000 --_000_86494F1C04484447AE7355C10ED86755jiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClRoZSBxdWVzdGlvbiBJIGFza2VkIGF0IHRoZSBtaWMgdG9kYXkgd2FzIGRyaXZlbiBi eSBzZWVpbmcgYW4gYXJjaGl0ZWN0dXJlIHRleHQgKGRyYWZ0LWZpbm4tZGV0bmV0LWFyY2hpdGVj dHVyZS0wNCkgd2hlcmUgdGhlcmXigJlzIG5vIGV4cGxpY2l0IG1lbnRpb24gb2YgcHJpdmFjeSBo YW5kbGluZywgYW5kIGJlaW5nIGF3YXJlIHRoYXQgc2luY2UgUkZDIDcyNTggd2FzIHB1Ymxpc2hl ZCB3ZSBzaG91bGQgYmUgdGhpbmtpbmcgYWJvdXQgYXBwcm9wcmlhdGUgcHJpdmFjeSBjb25zaWRl cmF0aW9ucyBpbiBzdWNoIGRvY3VtZW50cy4NCg0KU28sIGZvciBleGFtcGxlLCBvbmUg4oCYb3Bl biBpc3N1ZScgc2xpZGUgaW4gTm9ybWFu4oCZcyB0YWxrIGFza2VkIGFib3V0IGlkZW50aWZ5aW5n IHN0cmVhbXMsIGFuZCBMMiBhZGRyZXNzZXMgb3IgdGhlIDUtdHVwbGUgd2VyZSBtZW50aW9uZWQs IGJ1dCBpbiBhIHdvcmxkIHdoZXJlIEwyIGFkZHJlc3NlcyBhcmUgcmFuZG9taXNlZCBvdmVyIHRp bWUsIGFuZCBlbmNyeXB0aW9uIGlzIG1vcmUgd2lkZXNwcmVhZCwgb3RoZXIgbWVjaGFuaXNtcyBt YXkgYmUgcmVxdWlyZWQsIG9uZXMgdGhhdCBvbmUgbWlnaHQgYXJndWUgc2hvdWxkIGJlIG9wYXF1 ZSB0byB0aGUgbmV0d29yayBvcGVyYXRvci4NCg0KV2VhcmluZyBteSBkbnNzZCBXRyBjaGFpciBo YXQsIHdl4oCZdmUgZGlzY3Vzc2VkIHNpbWlsYXIgaXNzdWVzIHRoaXMgd2Vlaywgc3BlY2lmaWNh bGx5IGhvdyB5b3UgbWlnaHQgZG8gZGV2aWNlIG5hbWluZyBhbmQgc2VydmljZSBkaXNjb3Zlcnkg d2l0aCBwcml2YWN5LCB3aGlsZSB1c2luZyDigJhicm9hZGNhc3TigJkgcHJvdG9jb2xzIHN1Y2gg YXMgbUROUyBhbmQgRE5TLVNEIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTUvc2xpZGVzL3NsaWRlcy05NS1kbnNzZC0wLnBkZiwgaWYgaW50ZXJlc3RlZCkuDQoNCldoYXRl dmVyIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXJlIHB1dCBpbnRvIHRoZSBhcmNoaXRlY3R1cmUs IEkgdGhpbmsgd2Ugc2hvdWxkIGF0IGxlYXN0IGVuc3VyZSB3ZSBkaXNjdXNzIHRoZW0sIG5vdGlu ZyB0aGF0IHdoaWxlIGRldG5ldCBpcyBzY29wZWQgYnkgY2hhcnRlciB0byBpbml0aWFsbHkgb25s eSBiZSBhcHBsaWNhYmxlIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHVz ZSBvZiB0aGUgd29yZCDigJhpbml0aWFsbHnigJkgaW1wbGllcyBpdHMgc2NvcGUgbWF5L3dpbGwg Z3JvdyBsYXRlci4NCg0KVGltDQoNCg0KDQo= --_000_86494F1C04484447AE7355C10ED86755jiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5UaGUgcXVlc3Rpb24gSSBhc2tlZCBh dCB0aGUgbWljIHRvZGF5IHdhcyBkcml2ZW4gYnkgc2VlaW5nIGFuIGFyY2hpdGVjdHVyZSB0ZXh0 IChkcmFmdC1maW5uLWRldG5ldC1hcmNoaXRlY3R1cmUtMDQpIHdoZXJlIHRoZXJl4oCZcyBubyBl eHBsaWNpdCBtZW50aW9uIG9mIHByaXZhY3kgaGFuZGxpbmcsIGFuZCBiZWluZyBhd2FyZSB0aGF0 IHNpbmNlIFJGQyA3MjU4IHdhcyBwdWJsaXNoZWQgd2Ugc2hvdWxkIGJlIHRoaW5raW5nDQogYWJv dXQgYXBwcm9wcmlhdGUgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBpbiBzdWNoIGRvY3VtZW50cy48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlNvLCBmb3IgZXhhbXBsZSwgb25lIOKAmG9wZW4gaXNzdWUnIHNsaWRlIGluIE5vcm1hbuKAmXMg dGFsayBhc2tlZCBhYm91dCBpZGVudGlmeWluZyBzdHJlYW1zLCBhbmQgTDIgYWRkcmVzc2VzIG9y IHRoZSA1LXR1cGxlIHdlcmUgbWVudGlvbmVkLCBidXQgaW4gYSB3b3JsZCB3aGVyZSBMMiBhZGRy ZXNzZXMgYXJlIHJhbmRvbWlzZWQgb3ZlciB0aW1lLCBhbmQgZW5jcnlwdGlvbiBpcyBtb3JlIHdp ZGVzcHJlYWQsIG90aGVyIG1lY2hhbmlzbXMNCiBtYXkgYmUgcmVxdWlyZWQsIG9uZXMgdGhhdCBv bmUgbWlnaHQgYXJndWUgc2hvdWxkIGJlIG9wYXF1ZSB0byB0aGUgbmV0d29yayBvcGVyYXRvci4m bmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNs YXNzPSIiPldlYXJpbmcgbXkgZG5zc2QgV0cgY2hhaXIgaGF0LCB3ZeKAmXZlIGRpc2N1c3NlZCBz aW1pbGFyIGlzc3VlcyB0aGlzIHdlZWssIHNwZWNpZmljYWxseSBob3cgeW91IG1pZ2h0IGRvIGRl dmljZSBuYW1pbmcgYW5kIHNlcnZpY2UgZGlzY292ZXJ5IHdpdGggcHJpdmFjeSwgd2hpbGUgdXNp bmcg4oCYYnJvYWRjYXN04oCZIHByb3RvY29scyBzdWNoIGFzIG1ETlMgYW5kIEROUy1TRCAoc2Vl Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVz L3NsaWRlcy05NS1kbnNzZC0wLnBkZiIgY2xhc3M9IiI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1kbnNzZC0wLnBkZjwvYT4sDQogaWYgaW50ZXJl c3RlZCkuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBj bGFzcz0iIj5XaGF0ZXZlciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFyZSBwdXQgaW50byB0aGUg YXJjaGl0ZWN0dXJlLCBJIHRoaW5rIHdlIHNob3VsZCBhdCBsZWFzdCBlbnN1cmUgd2UgZGlzY3Vz cyB0aGVtLCBub3RpbmcgdGhhdCB3aGlsZSBkZXRuZXQgaXMgc2NvcGVkIGJ5IGNoYXJ0ZXIgdG8g aW5pdGlhbGx5IG9ubHkgYmUgYXBwbGljYWJsZSB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRp dmUgZG9tYWluLCB1c2Ugb2YgdGhlIHdvcmQNCiDigJhpbml0aWFsbHnigJkgaW1wbGllcyBpdHMg c2NvcGUgbWF5L3dpbGwgZ3JvdyBsYXRlci48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNz PSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGltPC9kaXY+DQo8ZGl2IGNsYXNz PSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBsZS1pbnRlcmNoYW5nZS1u ZXdsaW5lIj4NCjwvZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_86494F1C04484447AE7355C10ED86755jiscacuk_-- From nobody Wed Apr 6 09:58:43 2016 Return-Path: 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 3BB2312D67C for ; Wed, 6 Apr 2016 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=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 er57Qz6PWVfQ for ; Wed, 6 Apr 2016 09:58:36 -0700 (PDT) Received: from relais-inet.orange.com (relais-nor35.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14BF12D5E2 for ; Wed, 6 Apr 2016 09:58:35 -0700 (PDT) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id DF7F5180170; Wed, 6 Apr 2016 18:58:33 +0200 (CEST) Received: from Exchangemail-eme3.itn.ftgroup (unknown [xx.xx.50.113]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id B9BB5120073; Wed, 6 Apr 2016 18:58:33 +0200 (CEST) Received: from OPEXCNORMAD.corporate.adroot.infra.ftgroup ([fe80::f1a0:3c6b:bc7b:3aaf]) by OPEXCNORM2D.corporate.adroot.infra.ftgroup ([fe80::7919:5bec:48cc:ccdf%21]) with mapi id 14.03.0279.002; Wed, 6 Apr 2016 18:58:33 +0200 From: To: Tim Chown , "detnet@ietf.org" Thread-Topic: OFFLIST RE: detnet architecture, and privacy considerations Thread-Index: AdGQJYoT+N0X6uEBSnGcYBQtD3OcVg== Date: Wed, 6 Apr 2016 16:58:33 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933008D4B095@OPEXCNORMAD.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933008D4B095OPEXCNORMADcorp_" MIME-Version: 1.0 Archived-At: Subject: [Detnet] OFFLIST RE: detnet architecture, and privacy considerations X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 16:58:42 -0000 --_000_787AE7BB302AE849A7480A190F8B933008D4B095OPEXCNORMADcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltLA0KDQpJIGRvIGZ1bGx5IGFncmVlIHdpdGggdGhpcyBjb21tZW50Lg0KDQpGV0lXLCB0 aGVyZSBhcmUgc29tZSBjb25zaWRlcmF0aW9ucyB0aGF0IGFyZSBkaXNjdXNzZWQgaW4gaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyOTcjc2VjdGlvbi0zLjggdGhhdCBtYXkgYmUgcmV1 c2VkIGluIHRoZSBjb250ZXh0IG9mIGRldG5ldC4NCg0KSU1ITywgdGhlIHByaXZhY3kgcmVxdWly ZW1lbnQgc2hvdWxkIGJlIGV4cGxpY2l0bHkgY2FwdHVyZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0 LCBidXQgYXMgdGhhdCBkcmFmdCBpcyBjdXJyZW50bHkgc2NvcGVkLCBpdCBpcyBoYXJkIHRvIHNl ZSBob3cgcmVxdWlyZW1lbnRzIGFyZSBkZXJpdmVkIGZyb20gdGhlIHVzZSBjYXNlcy4NCg0KQ2hl ZXJzLA0KTWVkDQoNCkRlIDogZGV0bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmdd IERlIGxhIHBhcnQgZGUgVGltIENob3duDQpFbnZvecOpIDogbWFyZGkgNSBhdnJpbCAyMDE2IDEz OjQzDQrDgCA6IGRldG5ldEBpZXRmLm9yZw0KT2JqZXQgOiBbRGV0bmV0XSBkZXRuZXQgYXJjaGl0 ZWN0dXJlLCBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucw0KDQpIaSwNCg0KVGhlIHF1ZXN0aW9u IEkgYXNrZWQgYXQgdGhlIG1pYyB0b2RheSB3YXMgZHJpdmVuIGJ5IHNlZWluZyBhbiBhcmNoaXRl Y3R1cmUgdGV4dCAoZHJhZnQtZmlubi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTA0KSB3aGVyZSB0aGVy ZeKAmXMgbm8gZXhwbGljaXQgbWVudGlvbiBvZiBwcml2YWN5IGhhbmRsaW5nLCBhbmQgYmVpbmcg YXdhcmUgdGhhdCBzaW5jZSBSRkMgNzI1OCB3YXMgcHVibGlzaGVkIHdlIHNob3VsZCBiZSB0aGlu a2luZyBhYm91dCBhcHByb3ByaWF0ZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluIHN1Y2ggZG9j dW1lbnRzLg0KDQpTbywgZm9yIGV4YW1wbGUsIG9uZSDigJhvcGVuIGlzc3VlJyBzbGlkZSBpbiBO b3JtYW7igJlzIHRhbGsgYXNrZWQgYWJvdXQgaWRlbnRpZnlpbmcgc3RyZWFtcywgYW5kIEwyIGFk ZHJlc3NlcyBvciB0aGUgNS10dXBsZSB3ZXJlIG1lbnRpb25lZCwgYnV0IGluIGEgd29ybGQgd2hl cmUgTDIgYWRkcmVzc2VzIGFyZSByYW5kb21pc2VkIG92ZXIgdGltZSwgYW5kIGVuY3J5cHRpb24g aXMgbW9yZSB3aWRlc3ByZWFkLCBvdGhlciBtZWNoYW5pc21zIG1heSBiZSByZXF1aXJlZCwgb25l cyB0aGF0IG9uZSBtaWdodCBhcmd1ZSBzaG91bGQgYmUgb3BhcXVlIHRvIHRoZSBuZXR3b3JrIG9w ZXJhdG9yLg0KDQpXZWFyaW5nIG15IGRuc3NkIFdHIGNoYWlyIGhhdCwgd2XigJl2ZSBkaXNjdXNz ZWQgc2ltaWxhciBpc3N1ZXMgdGhpcyB3ZWVrLCBzcGVjaWZpY2FsbHkgaG93IHlvdSBtaWdodCBk byBkZXZpY2UgbmFtaW5nIGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSB3aXRoIHByaXZhY3ksIHdoaWxl IHVzaW5nIOKAmGJyb2FkY2FzdOKAmSBwcm90b2NvbHMgc3VjaCBhcyBtRE5TIGFuZCBETlMtU0Qg KHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlkZXMvc2xpZGVzLTk1 LWRuc3NkLTAucGRmLCBpZiBpbnRlcmVzdGVkKS4NCg0KV2hhdGV2ZXIgcHJpdmFjeSBjb25zaWRl cmF0aW9ucyBhcmUgcHV0IGludG8gdGhlIGFyY2hpdGVjdHVyZSwgSSB0aGluayB3ZSBzaG91bGQg YXQgbGVhc3QgZW5zdXJlIHdlIGRpc2N1c3MgdGhlbSwgbm90aW5nIHRoYXQgd2hpbGUgZGV0bmV0 IGlzIHNjb3BlZCBieSBjaGFydGVyIHRvIGluaXRpYWxseSBvbmx5IGJlIGFwcGxpY2FibGUgd2l0 aGluIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGRvbWFpbiwgdXNlIG9mIHRoZSB3b3JkIOKAmGlu aXRpYWxseeKAmSBpbXBsaWVzIGl0cyBzY29wZSBtYXkvd2lsbCBncm93IGxhdGVyLg0KDQpUaW0N Cg0KDQoNCg== --_000_787AE7BB302AE849A7480A190F8B933008D4B095OPEXCNORMADcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsN Cgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkhpIFRpbSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JIGRvIGZ1bGx5IGFncmVlIHdpdGggdGhp cyBjb21tZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPkZXSVcsIHRoZXJlIGFyZSBzb21lIGNvbnNpZGVyYXRpb25zIHRoYXQgYXJlIGRpc2N1 c3NlZCBpbg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyOTcjc2Vj dGlvbi0zLjgiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3Mjk3I3NlY3Rpb24tMy44 PC9hPiB0aGF0IG1heSBiZSByZXVzZWQgaW4gdGhlIGNvbnRleHQgb2YgZGV0bmV0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JTUhPLCB0aGUgcHJp dmFjeSByZXF1aXJlbWVudCBzaG91bGQgYmUgZXhwbGljaXRseSBjYXB0dXJlZCBpbiB0aGUgdXNl IGNhc2UgZHJhZnQsIGJ1dCBhcyB0aGF0IGRyYWZ0IGlzIGN1cnJlbnRseSBzY29wZWQsIGl0IGlz IGhhcmQgdG8gc2VlIGhvdyByZXF1aXJlbWVudHMNCiBhcmUgZGVyaXZlZCBmcm9tIHRoZSB1c2Ug Y2FzZXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2si PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3Jn XQ0KPGI+RGUgbGEgcGFydCBkZTwvYj4gVGltIENob3duPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8 L2I+IG1hcmRpIDUgYXZyaWwgMjAxNiAxMzo0Mzxicj4NCjxiPsOAJm5ic3A7OjwvYj4gZGV0bmV0 QGlldGYub3JnPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBbRGV0bmV0XSBkZXRuZXQgYXJjaGl0 ZWN0dXJlLCBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBxdWVzdGlvbiBJIGFza2VkIGF0IHRoZSBtaWMgdG9kYXkg d2FzIGRyaXZlbiBieSBzZWVpbmcgYW4gYXJjaGl0ZWN0dXJlIHRleHQgKGRyYWZ0LWZpbm4tZGV0 bmV0LWFyY2hpdGVjdHVyZS0wNCkgd2hlcmUgdGhlcmXigJlzIG5vIGV4cGxpY2l0IG1lbnRpb24g b2YgcHJpdmFjeSBoYW5kbGluZywgYW5kIGJlaW5nIGF3YXJlIHRoYXQgc2luY2UgUkZDIDcyNTgg d2FzIHB1Ymxpc2hlZCB3ZSBzaG91bGQgYmUgdGhpbmtpbmcNCiBhYm91dCBhcHByb3ByaWF0ZSBw cml2YWN5IGNvbnNpZGVyYXRpb25zIGluIHN1Y2ggZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbywgZm9yIGV4YW1wbGUsIG9u ZSDigJhvcGVuIGlzc3VlJyBzbGlkZSBpbiBOb3JtYW7igJlzIHRhbGsgYXNrZWQgYWJvdXQgaWRl bnRpZnlpbmcgc3RyZWFtcywgYW5kIEwyIGFkZHJlc3NlcyBvciB0aGUgNS10dXBsZSB3ZXJlIG1l bnRpb25lZCwgYnV0IGluIGEgd29ybGQgd2hlcmUgTDIgYWRkcmVzc2VzIGFyZSByYW5kb21pc2Vk IG92ZXIgdGltZSwgYW5kIGVuY3J5cHRpb24gaXMgbW9yZSB3aWRlc3ByZWFkLCBvdGhlcg0KIG1l Y2hhbmlzbXMgbWF5IGJlIHJlcXVpcmVkLCBvbmVzIHRoYXQgb25lIG1pZ2h0IGFyZ3VlIHNob3Vs ZCBiZSBvcGFxdWUgdG8gdGhlIG5ldHdvcmsgb3BlcmF0b3IuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlYXJpbmcgbXkgZG5zc2Qg V0cgY2hhaXIgaGF0LCB3ZeKAmXZlIGRpc2N1c3NlZCBzaW1pbGFyIGlzc3VlcyB0aGlzIHdlZWss IHNwZWNpZmljYWxseSBob3cgeW91IG1pZ2h0IGRvIGRldmljZSBuYW1pbmcgYW5kIHNlcnZpY2Ug ZGlzY292ZXJ5IHdpdGggcHJpdmFjeSwgd2hpbGUgdXNpbmcg4oCYYnJvYWRjYXN04oCZIHByb3Rv Y29scyBzdWNoIGFzIG1ETlMgYW5kIEROUy1TRCAoc2VlJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1kbnNzZC0wLnBkZiI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1kbnNz ZC0wLnBkZjwvYT4sDQogaWYgaW50ZXJlc3RlZCkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXRldmVyIHByaXZhY3kgY29uc2lkZXJhdGlv bnMgYXJlIHB1dCBpbnRvIHRoZSBhcmNoaXRlY3R1cmUsIEkgdGhpbmsgd2Ugc2hvdWxkIGF0IGxl YXN0IGVuc3VyZSB3ZSBkaXNjdXNzIHRoZW0sIG5vdGluZyB0aGF0IHdoaWxlIGRldG5ldCBpcyBz Y29wZWQgYnkgY2hhcnRlciB0byBpbml0aWFsbHkgb25seSBiZSBhcHBsaWNhYmxlIHdpdGhpbiBh IHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHVzZSBvZg0KIHRoZSB3b3JkIOKAmGluaXRp YWxseeKAmSBpbXBsaWVzIGl0cyBzY29wZSBtYXkvd2lsbCBncm93IGxhdGVyLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRpbTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_787AE7BB302AE849A7480A190F8B933008D4B095OPEXCNORMADcorp_-- From nobody Wed Apr 6 12:07:12 2016 Return-Path: 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 AC28E12D7C3 for ; Wed, 6 Apr 2016 12:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 gKe_w61Wt7Ey for ; Wed, 6 Apr 2016 12:07:07 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0B4A12D771 for ; Wed, 6 Apr 2016 12:07:05 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u36Ijx1C009858; Wed, 6 Apr 2016 11:50:16 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 2254errcyw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 06 Apr 2016 11:50:16 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 6 Apr 2016 11:50:14 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 6 Apr 2016 11:50:13 -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.1076.000; Wed, 6 Apr 2016 11:50:13 -0700 From: "Grossman, Ethan A." To: "mohamed.boucadair@orange.com" , Tim Chown , "detnet@ietf.org" Thread-Topic: OFFLIST RE: detnet architecture, and privacy considerations Thread-Index: AdGQJYoT+N0X6uEBSnGcYBQtD3OcVgADTzLA Date: Wed, 6 Apr 2016 18:50:12 +0000 Message-ID: References: <787AE7BB302AE849A7480A190F8B933008D4B095@OPEXCNORMAD.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933008D4B095@OPEXCNORMAD.corporate.adroot.infra.ftgroup> 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.207.133.62] Content-Type: multipart/alternative; boundary="_000_c7bd8ebe21784b76aefd79721ea68d15DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-06_08:2016-04-06,2016-04-06,1970-01-01 signatures=0 Archived-At: Subject: Re: [Detnet] OFFLIST RE: detnet architecture, and privacy considerations X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:07:09 -0000 --_000_c7bd8ebe21784b76aefd79721ea68d15DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltIGFuZCBNb2hhbWVkLA0KVGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVwLiBDbGVhcmx5 IHNlY3VyaXR5IGlzIGEgbWFqb3IgcmVxdWlyZW1lbnQgb2YgRGV0TmV0IHVzZSBjYXNlcy4gUGxl YXNlIHBhcmRvbiBteSBpZ25vcmFuY2UgaGVyZSwgYnV0IGRvZXMgcHJpdmFjeSBhcyBkZWZpbmVk IGluIHRoaXMgY29udGV4dCBhZmZlY3Qgc2VjdXJpdHkgb24gYSDigJxjZW50cmFsbHkgYWRtaW5p c3RlcmVkIGNvcnBvcmF0ZSBuZXR3b3Jr4oCdIChzdWNoIGFzIERldE5ldCBpcyBjdXJyZW50bHkg ZGVmaW5lZCB0byBvcGVyYXRlIG9uKT8gSWYgaXQgZG9lcyB0aGVuIEkgd291bGQgc2F5IHdlIG5l ZWQgdG8gYWRkIGl0IHRvIHRoZSB1c2UgY2FzZXMgZHJhZnQgZXhwbGljaXRseTsgaG93ZXZlciBp ZiBpdCBvbmx5IGJlY29tZXMgYW4gaXNzdWUgaW4gYSBwb3NzaWJsZSBwb3N0LURldE5ldCB0aW1l IGZyYW1lIHRoZW4gaXQgbWlnaHQgYmUgY29uc2lkZXJlZCBhcyBhbiBlbGVtZW50IG9mIHRoZSBj dXJyZW50bHkgb3BlbiBxdWVzdGlvbiDigJx0byB3aGF0IGV4dGVudCBkb2VzIHBsYW5uaW5nIGZv ciBmdXR1cmUgYXBwbGljYXRpb24gb2YgRGV0TmV0IHRvIHB1YmxpYyBuZXR3b3JrcyBhZmZlY3Qg RGV0TmV0IGRlc2lnbiBkZWNpc2lvbnMgdG9kYXk/4oCdDQpUaGFua3MsDQpFdGhhbi4NCg0KRnJv bTogZGV0bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tDQpTZW50OiBXZWRuZXNkYXksIEFwcmlsIDA2LCAy MDE2IDE6NTkgUE0NClRvOiBUaW0gQ2hvd247IGRldG5ldEBpZXRmLm9yZw0KU3ViamVjdDogW0Rl dG5ldF0gT0ZGTElTVCBSRTogZGV0bmV0IGFyY2hpdGVjdHVyZSwgYW5kIHByaXZhY3kgY29uc2lk ZXJhdGlvbnMNCg0KSGkgVGltLA0KDQpJIGRvIGZ1bGx5IGFncmVlIHdpdGggdGhpcyBjb21tZW50 Lg0KDQpGV0lXLCB0aGVyZSBhcmUgc29tZSBjb25zaWRlcmF0aW9ucyB0aGF0IGFyZSBkaXNjdXNz ZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyOTcjc2VjdGlvbi0zLjg8aHR0 cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5p ZXRmLm9yZ19odG1sX3JmYzcyOTctMjNzZWN0aW9uLTJEMy44JmQ9Q3dNR2FRJmM9bEk4WmI2VHpN M2QxdFg0aUV1N2JwZyZyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmbT1ieFNtdHhpUW1IYVVCQTNh cnJjWlRzbVN6WjJZUGRFWkxpcjJTU0EtVXRzJnM9czN6aGI5TXRoM0lKYnREM1ExM0dvcXd5cWZh MGcwMFIwc0plTXJPa2FiWSZlPT4gdGhhdCBtYXkgYmUgcmV1c2VkIGluIHRoZSBjb250ZXh0IG9m IGRldG5ldC4NCg0KSU1ITywgdGhlIHByaXZhY3kgcmVxdWlyZW1lbnQgc2hvdWxkIGJlIGV4cGxp Y2l0bHkgY2FwdHVyZWQgaW4gdGhlIHVzZSBjYXNlIGRyYWZ0LCBidXQgYXMgdGhhdCBkcmFmdCBp cyBjdXJyZW50bHkgc2NvcGVkLCBpdCBpcyBoYXJkIHRvIHNlZSBob3cgcmVxdWlyZW1lbnRzIGFy ZSBkZXJpdmVkIGZyb20gdGhlIHVzZSBjYXNlcy4NCg0KQ2hlZXJzLA0KTWVkDQoNCkRlIDogZGV0 bmV0IFttYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgVGltIENo b3duDQpFbnZvecOpIDogbWFyZGkgNSBhdnJpbCAyMDE2IDEzOjQzDQrDgCA6IGRldG5ldEBpZXRm Lm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPg0KT2JqZXQgOiBbRGV0bmV0XSBkZXRuZXQgYXJj aGl0ZWN0dXJlLCBhbmQgcHJpdmFjeSBjb25zaWRlcmF0aW9ucw0KDQpIaSwNCg0KVGhlIHF1ZXN0 aW9uIEkgYXNrZWQgYXQgdGhlIG1pYyB0b2RheSB3YXMgZHJpdmVuIGJ5IHNlZWluZyBhbiBhcmNo aXRlY3R1cmUgdGV4dCAoZHJhZnQtZmlubi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTA0KSB3aGVyZSB0 aGVyZeKAmXMgbm8gZXhwbGljaXQgbWVudGlvbiBvZiBwcml2YWN5IGhhbmRsaW5nLCBhbmQgYmVp bmcgYXdhcmUgdGhhdCBzaW5jZSBSRkMgNzI1OCB3YXMgcHVibGlzaGVkIHdlIHNob3VsZCBiZSB0 aGlua2luZyBhYm91dCBhcHByb3ByaWF0ZSBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGluIHN1Y2gg ZG9jdW1lbnRzLg0KDQpTbywgZm9yIGV4YW1wbGUsIG9uZSDigJhvcGVuIGlzc3VlJyBzbGlkZSBp biBOb3JtYW7igJlzIHRhbGsgYXNrZWQgYWJvdXQgaWRlbnRpZnlpbmcgc3RyZWFtcywgYW5kIEwy IGFkZHJlc3NlcyBvciB0aGUgNS10dXBsZSB3ZXJlIG1lbnRpb25lZCwgYnV0IGluIGEgd29ybGQg d2hlcmUgTDIgYWRkcmVzc2VzIGFyZSByYW5kb21pc2VkIG92ZXIgdGltZSwgYW5kIGVuY3J5cHRp b24gaXMgbW9yZSB3aWRlc3ByZWFkLCBvdGhlciBtZWNoYW5pc21zIG1heSBiZSByZXF1aXJlZCwg b25lcyB0aGF0IG9uZSBtaWdodCBhcmd1ZSBzaG91bGQgYmUgb3BhcXVlIHRvIHRoZSBuZXR3b3Jr IG9wZXJhdG9yLg0KDQpXZWFyaW5nIG15IGRuc3NkIFdHIGNoYWlyIGhhdCwgd2XigJl2ZSBkaXNj dXNzZWQgc2ltaWxhciBpc3N1ZXMgdGhpcyB3ZWVrLCBzcGVjaWZpY2FsbHkgaG93IHlvdSBtaWdo dCBkbyBkZXZpY2UgbmFtaW5nIGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSB3aXRoIHByaXZhY3ksIHdo aWxlIHVzaW5nIOKAmGJyb2FkY2FzdOKAmSBwcm90b2NvbHMgc3VjaCBhcyBtRE5TIGFuZCBETlMt U0QgKHNlZSBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlkZXMvc2xpZGVz LTk1LWRuc3NkLTAucGRmPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX3Byb2NlZWRpbmdzXzk1X3NsaWRlc19zbGlkZXMtMkQ5 NS0yRGRuc3NkLTJEMC5wZGYmZD1Dd01HYVEmYz1sSThaYjZUek0zZDF0WDRpRXU3YnBnJnI9WmNI QzZ3WF9nRHdQRGNmTWFGTlppUSZtPWJ4U210eGlRbUhhVUJBM2FycmNaVHNtU3paMllQZEVaTGly MlNTQS1VdHMmcz1JX0Y5T2twcnhTdDc3MkdJaDhiYm5vTDVoVjJBZ3YtQl9HdWZNd3M5YzlrJmU9 PiwgaWYgaW50ZXJlc3RlZCkuDQoNCldoYXRldmVyIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXJl IHB1dCBpbnRvIHRoZSBhcmNoaXRlY3R1cmUsIEkgdGhpbmsgd2Ugc2hvdWxkIGF0IGxlYXN0IGVu c3VyZSB3ZSBkaXNjdXNzIHRoZW0sIG5vdGluZyB0aGF0IHdoaWxlIGRldG5ldCBpcyBzY29wZWQg YnkgY2hhcnRlciB0byBpbml0aWFsbHkgb25seSBiZSBhcHBsaWNhYmxlIHdpdGhpbiBhIHNpbmds ZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHVzZSBvZiB0aGUgd29yZCDigJhpbml0aWFsbHnigJkg aW1wbGllcyBpdHMgc2NvcGUgbWF5L3dpbGwgZ3JvdyBsYXRlci4NCg0KVGltDQoNCg0KDQo= --_000_c7bd8ebe21784b76aefd79721ea68d15DLBXCHPW03dolbynet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6 bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1z ZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7 DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkhpIFRpbSBhbmQgTW9oYW1lZCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+VGhhbmtzIGZvciBicmluZ2luZyB0aGlzIHVwLiBDbGVhcmx5IHNlY3VyaXR5IGlz IGEgbWFqb3IgcmVxdWlyZW1lbnQgb2YgRGV0TmV0IHVzZSBjYXNlcy4gUGxlYXNlIHBhcmRvbiBt eSBpZ25vcmFuY2UgaGVyZSwgYnV0IGRvZXMgcHJpdmFjeSBhcyBkZWZpbmVkIGluIHRoaXMNCiBj b250ZXh0IGFmZmVjdCBzZWN1cml0eSBvbiBhIOKAnGNlbnRyYWxseSBhZG1pbmlzdGVyZWQgY29y cG9yYXRlIG5ldHdvcmvigJ0gKHN1Y2ggYXMgRGV0TmV0IGlzIGN1cnJlbnRseSBkZWZpbmVkIHRv IG9wZXJhdGUgb24pPyBJZiBpdCBkb2VzIHRoZW4gSSB3b3VsZCBzYXkgd2UgbmVlZCB0byBhZGQg aXQgdG8gdGhlIHVzZSBjYXNlcyBkcmFmdCBleHBsaWNpdGx5OyBob3dldmVyIGlmIGl0IG9ubHkg YmVjb21lcyBhbiBpc3N1ZSBpbiBhIHBvc3NpYmxlDQogcG9zdC1EZXROZXQgdGltZSBmcmFtZSB0 aGVuIGl0IG1pZ2h0IGJlIGNvbnNpZGVyZWQgYXMgYW4gZWxlbWVudCBvZiB0aGUgY3VycmVudGx5 IG9wZW4gcXVlc3Rpb24g4oCcdG8gd2hhdCBleHRlbnQgZG9lcyBwbGFubmluZyBmb3IgZnV0dXJl IGFwcGxpY2F0aW9uIG9mIERldE5ldCB0byBwdWJsaWMgbmV0d29ya3MgYWZmZWN0IERldE5ldCBk ZXNpZ24gZGVjaXNpb25zIHRvZGF5P+KAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkV0aGFuLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IGRldG5ldCBbbWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5tb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tPGJyPg0KPGI+U2VudDo8L2I+ IFdlZG5lc2RheSwgQXByaWwgMDYsIDIwMTYgMTo1OSBQTTxicj4NCjxiPlRvOjwvYj4gVGltIENo b3duOyBkZXRuZXRAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0RldG5ldF0gT0ZGTElT VCBSRTogZGV0bmV0IGFyY2hpdGVjdHVyZSwgYW5kIHByaXZhY3kgY29uc2lkZXJhdGlvbnM8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJG UiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Y29sb3I6YmxhY2siPkhpIFRpbSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj5JIGRvIGZ1bGx5IGFncmVlIHdpdGggdGhpcyBjb21tZW50Lg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5GV0lXLCB0aGVyZSBhcmUgc29tZSBjb25zaWRlcmF0aW9ucyB0aGF0IGFyZSBk aXNjdXNzZWQgaW4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM3Mjk3LTIzc2VjdGlvbi0y RDMuOCZhbXA7ZD1Dd01HYVEmYW1wO2M9bEk4WmI2VHpNM2QxdFg0aUV1N2JwZyZhbXA7cj1aY0hD NndYX2dEd1BEY2ZNYUZOWmlRJmFtcDttPWJ4U210eGlRbUhhVUJBM2FycmNaVHNtU3paMllQZEVa TGlyMlNTQS1VdHMmYW1wO3M9czN6aGI5TXRoM0lKYnREM1ExM0dvcXd5cWZhMGcwMFIwc0plTXJP a2FiWSZhbXA7ZT0iPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzcyOTcjc2VjdGlv bi0zLjg8L2E+IHRoYXQgbWF5IGJlIHJldXNlZCBpbiB0aGUgY29udGV4dCBvZiBkZXRuZXQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5JTUhPLCB0aGUgcHJpdmFjeSByZXF1aXJlbWVudCBzaG91 bGQgYmUgZXhwbGljaXRseSBjYXB0dXJlZCBpbiB0aGUgdXNlIGNhc2UgZHJhZnQsIGJ1dCBhcyB0 aGF0IGRyYWZ0IGlzIGN1cnJlbnRseSBzY29wZWQsIGl0IGlzIGhhcmQgdG8gc2VlIGhvdyByZXF1 aXJlbWVudHMgYXJlIGRlcml2ZWQNCiBmcm9tIHRoZSB1c2UgY2FzZXMuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk1lZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBkZXRuZXQgWzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91 bmNlc0BpZXRmLm9yZyI+bWFpbHRvOmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPkRl IGxhIHBhcnQgZGU8L2I+IFRpbSBDaG93bjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJk aSA1IGF2cmlsIDIwMTYgMTM6NDM8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IDxhIGhyZWY9Im1haWx0 bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT48YnI+DQo8Yj5PYmpldCZuYnNw Ozo8L2I+IFtEZXRuZXRdIGRldG5ldCBhcmNoaXRlY3R1cmUsIGFuZCBwcml2YWN5IGNvbnNpZGVy YXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+SGksIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRlIiPlRoZSBxdWVzdGlvbiBJIGFza2VkIGF0IHRoZSBtaWMgdG9kYXkg d2FzIGRyaXZlbiBieSBzZWVpbmcgYW4gYXJjaGl0ZWN0dXJlIHRleHQgKGRyYWZ0LWZpbm4tZGV0 bmV0LWFyY2hpdGVjdHVyZS0wNCkgd2hlcmUgdGhlcmXigJlzIG5vIGV4cGxpY2l0IG1lbnRpb24g b2YgcHJpdmFjeSBoYW5kbGluZywgYW5kIGJlaW5nIGF3YXJlIHRoYXQgc2luY2UgUkZDIDcyNTgg d2FzIHB1Ymxpc2hlZA0KIHdlIHNob3VsZCBiZSB0aGlua2luZyBhYm91dCBhcHByb3ByaWF0ZSBw cml2YWN5IGNvbnNpZGVyYXRpb25zIGluIHN1Y2ggZG9jdW1lbnRzLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZS Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+U28sIGZvciBleGFtcGxlLCBvbmUg4oCYb3BlbiBp c3N1ZScgc2xpZGUgaW4gTm9ybWFu4oCZcyB0YWxrIGFza2VkIGFib3V0IGlkZW50aWZ5aW5nIHN0 cmVhbXMsIGFuZCBMMiBhZGRyZXNzZXMgb3IgdGhlIDUtdHVwbGUgd2VyZSBtZW50aW9uZWQsIGJ1 dCBpbiBhIHdvcmxkIHdoZXJlIEwyIGFkZHJlc3NlcyBhcmUgcmFuZG9taXNlZCBvdmVyIHRpbWUs IGFuZCBlbmNyeXB0aW9uIGlzIG1vcmUNCiB3aWRlc3ByZWFkLCBvdGhlciBtZWNoYW5pc21zIG1h eSBiZSByZXF1aXJlZCwgb25lcyB0aGF0IG9uZSBtaWdodCBhcmd1ZSBzaG91bGQgYmUgb3BhcXVl IHRvIHRoZSBuZXR3b3JrIG9wZXJhdG9yLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJGUiI+V2VhcmluZyBteSBkbnNzZCBXRyBjaGFpciBoYXQsIHdl4oCZdmUg ZGlzY3Vzc2VkIHNpbWlsYXIgaXNzdWVzIHRoaXMgd2Vlaywgc3BlY2lmaWNhbGx5IGhvdyB5b3Ug bWlnaHQgZG8gZGV2aWNlIG5hbWluZyBhbmQgc2VydmljZSBkaXNjb3Zlcnkgd2l0aCBwcml2YWN5 LCB3aGlsZSB1c2luZyDigJhicm9hZGNhc3TigJkgcHJvdG9jb2xzIHN1Y2ggYXMgbUROUyBhbmQg RE5TLVNEIChzZWUmbmJzcDs8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19wcm9jZWVkaW5nc185NV9zbGlkZXNf c2xpZGVzLTJEOTUtMkRkbnNzZC0yRDAucGRmJmFtcDtkPUN3TUdhUSZhbXA7Yz1sSThaYjZUek0z ZDF0WDRpRXU3YnBnJmFtcDtyPVpjSEM2d1hfZ0R3UERjZk1hRk5aaVEmYW1wO209YnhTbXR4aVFt SGFVQkEzYXJyY1pUc21TeloyWVBkRVpMaXIyU1NBLVV0cyZhbXA7cz1JX0Y5T2twcnhTdDc3MkdJ aDhiYm5vTDVoVjJBZ3YtQl9HdWZNd3M5YzlrJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcv cHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1kbnNzZC0wLnBkZjwvYT4sDQogaWYgaW50 ZXJlc3RlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkZSIj5XaGF0 ZXZlciBwcml2YWN5IGNvbnNpZGVyYXRpb25zIGFyZSBwdXQgaW50byB0aGUgYXJjaGl0ZWN0dXJl LCBJIHRoaW5rIHdlIHNob3VsZCBhdCBsZWFzdCBlbnN1cmUgd2UgZGlzY3VzcyB0aGVtLCBub3Rp bmcgdGhhdCB3aGlsZSBkZXRuZXQgaXMgc2NvcGVkIGJ5IGNoYXJ0ZXIgdG8gaW5pdGlhbGx5IG9u bHkgYmUgYXBwbGljYWJsZSB3aXRoaW4gYSBzaW5nbGUgYWRtaW5pc3RyYXRpdmUNCiBkb21haW4s IHVzZSBvZiB0aGUgd29yZCDigJhpbml0aWFsbHnigJkgaW1wbGllcyBpdHMgc2NvcGUgbWF5L3dp bGwgZ3JvdyBsYXRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJGUiI+ VGltPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRlIi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_c7bd8ebe21784b76aefd79721ea68d15DLBXCHPW03dolbynet_-- From nobody Wed Apr 6 12:51:22 2016 Return-Path: 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 CED7612D7D4 for ; Wed, 6 Apr 2016 12:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 tB4AQiNp745w for ; Wed, 6 Apr 2016 12:51:16 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3A012D7C9 for ; Wed, 6 Apr 2016 12:51:16 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u36JmmXV004550 for ; Wed, 6 Apr 2016 12:51:16 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 224ug5s5rx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 06 Apr 2016 12:51:16 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 6 Apr 2016 12:51:15 -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.1076.9; Wed, 6 Apr 2016 12:51:13 -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.1076.000; Wed, 6 Apr 2016 12:51:13 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet use cases: Interconnecting networks Thread-Index: AdGQPPYJbuKHdSDTSuC4ri9Ru9gouQ== Date: Wed, 6 Apr 2016 19:51:13 +0000 Message-ID: <7804adb36b8d45b9b7025aa0e2d49a12@DLB-XCHPW03.dolby.net> 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.207.133.62] Content-Type: multipart/alternative; boundary="_000_7804adb36b8d45b9b7025aa0e2d49a12DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-06_09:2016-04-06,2016-04-06,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet use cases: Interconnecting networks X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 19:51:19 -0000 --_000_7804adb36b8d45b9b7025aa0e2d49a12DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Following up on Patrick W's comment at the meeting: "In utility there is a use case of connecting two (or more?) substati= ons. They may us an SP network for that connection. Even if we do not suppo= rt internet at large, we must support 2 (or more?) interconnected networks.= " Is this on the design team's radar? Thanks, Ethan. --_000_7804adb36b8d45b9b7025aa0e2d49a12DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Following up on Patrick W’s comment at the meeting:
 
“In utility there is a use case of = connecting two (or more?) substations. They may us an SP network for that c= onnection. Even if we do not support internet at large, we must support 2 (= or more?) interconnected networks.”
 
Is this on the design team’s radar?
 
Thanks,
Ethan.
 
 --_000_7804adb36b8d45b9b7025aa0e2d49a12DLBXCHPW03dolbynet_-- From nobody Wed Apr 6 13:17:44 2016 Return-Path: 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 6AEEC12D7CC for ; Wed, 6 Apr 2016 13:17:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.23 X-Spam-Level: X-Spam-Status: No, score=-4.23 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, WEIRD_PORT=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 rx6EEf-kay6z for ; Wed, 6 Apr 2016 13:17:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B091D12D79D for ; Wed, 6 Apr 2016 13:17:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CGY75633; Wed, 06 Apr 2016 20:17:36 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 6 Apr 2016 21:17:35 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.160]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Thu, 7 Apr 2016 04:17:24 +0800 From: Jiangyuanlong To: Lou Berger , DetNet WG Thread-Topic: [Detnet] raw notes from session Thread-Index: AQHRj1EVpl0zFj4M00K9I6R+24nGv599Xhcg Date: Wed, 6 Apr 2016 20:17:23 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B91686D83@szxema506-mbs.china.huawei.com> References: <5703DB8D.8040408@labn.net> In-Reply-To: <5703DB8D.8040408@labn.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.197.56] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.57056EE0.0088, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 5b5b5c80471c8d2e120a00af706c18a2 Archived-At: Subject: Re: [Detnet] raw notes from session X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2016 20:17:43 -0000 SSBoYWQgYSBjb21tZW50IHJlZ2FyZGluZyBzbGlkZSA5IGJ1bGxldCA3IGluICJEYXRhIFBsYW5l IEFsdGVybmF0aXZlcyBEZXNpZ24gVGVhbSAtIHJlcG9ydCIuDQpJIGFncmVlIHRoYXQgdGhpcyBw YXJ0IChpLmUuLCBUaW1lIHN5bmNocm9uaXphdGlvbi4uIG9yIHJhdGhlciBPQU0gcGFydCBvZiBp dCkgaXMgaW1wb3J0YW50IGZvciB0aGUgRGV0TmV0LCBidXQgdGhpcyBmdW5jdGlvbiBpcyB1c3Vh bGx5IGluZGVwZW5kZW50IGZyb20gdGhlIGRhdGEgcGxhbmUuDQpGdXJ0aGVybW9yZSwgc3luY2hy b25pemF0aW9uIE9BTSBpcyBzdGlsbCBhIG1pc3NpbmcgcGllY2UgaW4gYWxsIHN0YW5kYXJkcyAo ZHJhZnQtaWV0Zi10aWN0b2MtMTU4OG92ZXJtcGxzLTA3IGhhcyBtZW50aW9uZWQgT0FNIGluIFNl Y3Rpb24gMTEsIGJ1dCBCRkQsIExTUC1QaW5nIGNhbiBvbmx5IG1vbml0b3IgZmF1bHRzIGluIHRo ZSBMU1Agb3IgcGF0aCwgdGhleSBjYW5ub3QgZGVhbCB3aXRoIHRoZSBsb3NzIG9mIHRoZSB0aW1p bmcgaW5mb3JtYXRpb24sIG1pc21hdGNoIG9mIHRoZSBjbG9jaywgY2xvY2sgcGVyZm9ybWFuY2Ug ZGVncmFkYXRpb24gYW5kIGV0Yy4pDQoNClRoYW5rcywNCll1YW5sb25nDQoNCg0KPiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBkZXRuZXQgW21haWx0bzpkZXRuZXQtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIExvdSBCZXJnZXINCj4gU2VudDogVHVlc2RheSwgQXBy aWwgMDUsIDIwMTYgMTE6MzcgUE0NCj4gVG86IERldE5ldCBXRw0KPiBTdWJqZWN0OiBbRGV0bmV0 XSByYXcgbm90ZXMgZnJvbSBzZXNzaW9uDQo+IA0KPiBIZXJlIGFyZSB0aGUgcmF3IG5vdGVzIGZy b20gdG9kYXkncyBzZXNzaW9uLiAgUGxlYXNlIHJldmlldyBhbmQgY29ycmVjdCAoYXQNCj4gaHR0 cDovL2V0aGVycGFkLnRvb2xzLmlldGYub3JnOjkwMDAvcC9ub3Rlcy1pZXRmLTk1LWRldG5ldCku ICBKdXN0IGENCj4gcmVtaW5kZXIgdGhlIG5vdGVzIHNob3VsZCBvbmx5IGNvdmVyIHdoYXQgd2Fz IGFjdHVhbGx5IHNhaWQgYXQgbWljcyBpbiB0aGUNCj4gc2Vzc2lvbiwgYW5kIHRoZXNlIGFyZSBp bnB1dCB0byB0aGUgZmluYWwgbWludXRlcy4gIFJlY29yZGluZ3Mgb2YgdGhlIHNlc3Npb24NCj4g aXMgYWxzbyBhdmFpbGFibGUuDQo+IA0KPiBUaGFua3MgdG8gUGFzY2FsIGFuZCBKb3VuaSBhbmQg YWxsIG90aGVycyB3aG8gY29udHJpYnV0ZWQgdG8gdGhlIG5vdGVzIGFuZA0KPiB0aGUgc3VjY2Vz c2Z1bCBtZWV0aW5nIQ0KPiANCj4gTG91IGFuZCBQYXQNCj4gDQo+ID4gSUVURi05NSBkZXRuZXQg YWdlbmRhDQo+ID4gICAgIFNlc3Npb24gMjAxNi0wNC0wNSAxMDAwLTEyMzA6IEJ1ZW4gQXlyZSBB IC0gQXVkaW8gc3RyZWFtIC0gZGV0bmV0DQo+IGNoYXRyb29tDQo+ID4gQWdlbmRhDQo+ID4gKiog SUVURiA5NSBEZXROZXQgQWdlbmRhIC0gdmVyc2lvbiA0LzQvMjAxNiAqKg0KPiA+DQo+ID4gVHVl c2RheSBBcHJpbCA1LCAyMDE2DQo+ID4gMTA6MDAtMTI6MzAgVHVlc2RheSBNb3JuaW5nIHNlc3Np b24gSQ0KPiA+IFJvb206IEJ1ZW4gQXlyZSBBDQo+ID4NCj4gPg0KPiA+IFN0YXJ0IFRpbWUgIElu Zm9ybWF0aW9uDQo+ID4gIDEwOjAwICgxNSkgIFRpdGxlOiBBZG1pbmlzdHJpdmlhICYgU3RhdHVz DQo+ID4gICAgICAgICAgICAgUHJlc2VudGVyOiBDaGFpcnMNCj4gPiAgICAgICAgICAgICBTbGlk ZXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05 NS1kZXRuZXQtMC5wZGYNCj4gDQo+IERvY3VtZW50IHN0YXR1czoNCj4gICAgIDIgV0cgZG9jdW1l bnRzDQo+ICAgICAxIGNhbmRpZGF0ZSAoYXJjaGl0ZWN0dXJlKQ0KPiANCj4gTk90ZXMgZG9uZSBi eSBKb3VuaSwgUGFzY2FsIFRodWJlcnQsDQo+IA0KPiA+IDEwOjE1ICgyMCkgIFRpdGxlOiBVc2Ug Y2FzZXMgLSB1cGRhdGUNCj4gPiAgICAgICAgICAgICBQcmVzZW50ZXI6IEV0aGFuIEdyb3NzbWFu DQo+ID4gICAgICAgICAgICAgRHJhZnQ6DQo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0wOA0KPiA+ICAgICAgICAgICAgIFNsaWRlczoNCj4g aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85NS9zbGlkZXMvc2xpZGVzLTk1LWRldG5l dC0xLnBkZg0KPiANCj4gRXRoYW4gZ2l2ZXMgdGhlIHByZXNlbnRhdGlvbiBvZiB0aGUgdXNlIGNh c2VzIGRyYWZ0Lg0KPiBHb2FsOiBwcm92aWRlIGluZHVzdHJ5IGNvbnRleHQgcGVyIHVzZSBjYXNl LCBob3cgaXQgaXMgYWRkcmVzc2VkIHRvZGF5IGFuZA0KPiB3aGF0IHdlIG5lZWQgZnJvbSBJRVRG IGZvciB0aGUgZnV0dXJlLiBMaW5lIHVwIHVzZSBjYXNlcyBhbmQgYXJjaGl0ZWN0dXJlLg0KPiAN Cj4gRXRoYW4gbGlzdHMgdXNlIGNhc2VzLCBvbmUgaXMgbmV3LCBNMk0gZm9yIGluZHVzdHJpYWws IEV0aGFuIHByZXNlbnRzIHRoZSB1c2UNCj4gY2FzZSBpbiBtb3JlIGRldGFpbHMuIEV0aGFuIGRl c2NyaWJlcyBjbGFzc2ljYWwgY29udHJvbCBsb29wLCBvcmRlcnMgb2YNCj4gbWFnbml0dWRlIGZv ciB0aW1lIGFuZCB2b2x1bWVzOyBleHByZXNzZXMgdGhlIHJlcXVpcmVtZW50IGZvciBhDQo+IGNv bnZlcmdlbmNlIHRvIElQLiBFdGhhbiBsaXN0cyBhc2tzIHRvIElFVEYgaW4gc2xpZGUgMTAsIGFu ZCBjb21waWxlcyBjb21tb24NCj4gdGhlbWVzIGluIHNsaWRlcyAxMSBhbmQgMTIuDQo+IA0KPiBT bGlkZXMgMTQtMTY6IExvb2tpbmcgZm9yIGRpc2Nvbm5lY3RzIGJldHdlZW4gZXhpc3RpbmcgYXJj aGl0ZWN0dXJlIGFuZCBwYg0KPiBzdGF0ZW1lbnQgYW5kIHRoZSB1c2UgY2FzZXMuIEJyaW5naW5n IHRoZSBtaXNtYXRjaGVzIHRvIGF0dGVudGlvbiwgc3VnZ2VzdA0KPiBkaXNjdXNzaW9ucyBvbiB0 aGUgTUwgdG8gcmVzb2x2ZS4gRXRoYW4gbGlzdHMgdGhlIGlzc3VlcyBvbmUgYnkgb25lIHRvDQo+ IHN0aW11bGF0ZSBmZWViYWNrDQo+IA0KPiBPcGVuIGludGVybmV0OiBub3QgaW4gc2NvcGUNCj4g Q2xvY2sgc3luYzogbm90IGluIHNjb3BlDQo+IFBsdWcgYW5kIHBsYXk6IG1vc3QgdXNlIGNhc2Vz IGV4cGVjdCB0aGF0IHRoZSBkZXZjZSBpcyBwcmUgcHJvdmlzaW9ubmVkLg0KPiBCdXQgdGhlbiB0 aGVyZSdzIHRoZSBmYWlsdXJlL3JlcGxhY2VtZW50IHNjZW5hcmlvLiBFdGhhbiBzdWdnZXN0cyB0 aGF0DQo+IA0KPiAtIFN0dWFydCBCcnlhbnQgb24gSmFiYmVyOiBSZSBidWxsZXQgMiAtIGlzbid0 IGRldG5ldCB1c2VmdWwgaW4gcHJvdmlkaW5nIHRoZQ0KPiB0aW1lIHN5bmMgY29uZHVpdA0KPiAN Cj4gLSBOb3JtIEZpbm46IHBlb3BsZSB1c2UgMTU4OCB0byBzY2hlZHVsZSBwYWNrZXRzLiBJbiB0 aGF0IGNhc2UsIHN5bmMnaW5nIHRpbWUNCj4gaXMgYSBzZXJ2aWNlIHRoYXQgZGV0bmV0IHVzZXMu IGRldG5ldCBtYXkgaGF2ZSByZXF1aXJlbWVudHMgb24gc3luYyB0aW1lLg0KPiBXb3VsZCBiZSBn cmVhdCB0byBoYXZlIHRoYXQgaW4gdGhlIHVzZSBjYXNlcy4gYWJvdXQgUCZQLCBpZiB0aGVyZSBp cyBhIHVzZSBjYXNlLA0KPiBzdWdnZXN0aW9uIHRvIHdyaXRlIGl0IGRvd24gdGhlcmUuDQo+IA0K PiAtIFBhdHJpY2sgV2V0dGVyd2FsZDogaW4gdXRpbGl0eSB0aGVyZSBpcyBhIHVzZSBjYXNlIG9m IGNvbm5lY3Rpbmcgc3Vic3RhdGlvbnMuDQo+IFRoZXkgbWF5IHVzIGFuIFNQIG5ldHdvcmsgZm9y IHRoYXQgY29ubmVjdGlvbi4gRXZlbiBpZiB3ZSBkbyBub3Qgc3VwcG9ydA0KPiBpbnRlcm5ldCBh dCBsYXJnZSwgd2UgbXVzdCBzdXBwb3J0IDIgaW50ZXJjb25uZWN0ZWQgbmV0d29ya3MuDQo+IA0K PiAtIEV0aGFuIEdyb3NzbWFuOiBOb3RlZA0KPiANCj4gRXRoYW46IExpbmsgYXF1dGhlbnRpY2F0 aW9uL2VuY3J5cHRpb24gaXMgYSBzZXJ2aWNlIG9uIHRvcCBvZiBkZXRuZXQuDQo+IA0KPiBMaW5r IEFnZ3JlZ2F0aW9uOiBzdHJlYW1zIGJlaW5nIHN5bmNocm9uaXplZCB0b2dldGhlcg0KPiANCj4g LSBMb3UgQmVyZ2VyOiB3aGF0IGlzIHlvdXIgb2JqZWN0aXZlIGZvciB0aGlzIChzbGlkZSAxNCBk aXNjdXNzaW9uKQ0KPiANCj4gLSBFdGhhbiBHcm9zc21hbjogdG8gcmFpc2UgdG9waWNzIHRoYXQg bWF5IG5vdCBiZSBjb3ZlcmVkIGluIG90aGVyDQo+IGRvY3VtZW50cw0KPiANCj4gLSBTdWJpciBE YXM6IGFyZSB5b3UgYXNraW5nIGFib3V0IG1pc21hdGNoZXMgd2l0aCBhcmNoaXRlY3R1cmU/DQo+ IA0KPiAtIEV0aGFuOiBJJ20gbGlzdGluZyB3aGF0IEknbSBub3QgbWF0Y2hpbmcNCj4gDQo+IDxk aXNjdXNzaW9uIGJldHdlZW4gU3ViaXIvRXRoYW4uLi4+DQo+IA0KPiBOb3JtIEZpbm46IHRoZSBQ JlAgaXMgbWVudGlvbm5lZCBpbiB0aGUgYXJjaGl0ZWN0dWUgZHJhZnQgYWJvdXQgUDJQDQo+IHBy b3RvY29sLCBoYXZuZyB0aGUgYWJpbGl0eSBmb3IgYW4gZW5kIHN5c3RlbSB0byByZXF1ZXN0IGEg c2VydmljZSBpcyBhbg0KPiBpbXBvcnRhbnQgY29tcG9pbmVudCBmb3IgZXhhY3RseSB0aGF0IHJl YXNvbi4gRW5jcnlwdGlvbjogYXJjaGl0ZWN0dXJlIHNheXMNCj4gd2UgZG8gbm90IHdhbnQgdG8g YnJlYWsgc2VjdXJpdHksIGJ1dCBhbHNvIHRoYXQgZGV0bmV0IHByZXNlbnRzIG5ldyBhc3BlY3Rz DQo+IHNpbmNlIGVuY3J5cHRpb24gZG9lcyBub3QgcHJvdGVjdCBvbiB0aW1lIGRlbGl2ZXJ5LiBM aW5rDQo+IGFnZ3JlZ2FndGlvbjogc28gZmFyIHRoZSBkaXNjdXNzaW9ucyBoYXZlIGJlZW4gYWJv dXQgbWFraW5nIHN1cmUgYSBmbG93IHN0YXkNCj4gb24gYSBzYW1lIHBhdGggYmVjYXVzZSBvZiB0 aGUgbmVlZCB0byBrZWVwIHBhY2tldHMgaW4gb3JkZXIuDQo+IEFnZ3JlZ2F0aW9uIGhhcyB0byBw bGFjZSBvbmUgZmxvdyBvbiBvbmUgbGluay4NCj4gDQo+IC0gSm9obiBEb3dkZWxsOiBpcyBpdCBt b3JlIGEgcXVlc3Rpb24gb2Ygd2hldGhlciBjdXJyZW50IGxpbmsgYXV0aGVudGljYXRpb24sDQo+ IGVuY3J5cHRpb24gYW5kIGFnZ3JlZ2F0aW9uIHRlY2hub2xvZ3kgZG9lcyBub3Qgc3VwcG9ydCBk ZXRuZXQgdXNlIGNhc2UsIGlzDQo+IHRoZXJlIHNvbWV0aGluZyB0aGF0IGlzIGxhY2tpbmc/DQo+ IC0gRXRoYW46IGV4YWN0bHkgd2hhdCB3ZSBhcmUgYWZ0ZXINCj4gLSBMb3UgQmVyZ2VyOiB0aGVu IGEgZ29vZCBkaXNjdXNzaW9uIHRvcGljIGZvciB0aGUgbGlzdA0KPiAtIFBhdCBUaGFsZXI6IGFz IGNvbnRyaWJ1dG9yLCBwbHVnIGFuZCBwbGF5IGlzIGltcG9ydGFudC4gVGhlcmUgYXJlIGNhc2Vz IGxpa2UNCj4gQS9WIHdoZXJlIHRoZXJlJ3MgZW5vdWdoIGJhbmR3aWR0aCB0byByZXNlcnZlIGZv ciBmbG93cyBhbG9uZyB0aGUgbmV0d29yaw0KPiAobm90ZSB0YWtlciB1bmRlcnN0YW5kaW5nOiBh cyBvcHBvc2VkIHRvIGNlbnRyYWwgb3B0aW1pemF0aW9uKS4gVGhlcmUgYXJlDQo+IHVzZSBjYXNl cyB3aGVyZSBldmVyeXRoaW5nIGlzIHByZXByb2dyYW1tZWQgYW5kIHRodXMgbm8gaXNzdWUgZS5n Liwgd2l0aA0KPiB0aGUgc3RhcnQgdGltZXMuIExpbmsgYWdncmVnYXRpb24gaGFzIGEgc3BlY2lm aWMgbWVhbmluZyBhdCBMMiwgdGhlcmUncyBhIGxpbmsNCj4gYWdncmVnYXRpb24gc3RhbmRhcmQu IEhhdmluZyBhIGZsb3cgYWxvbmcgbXVsdGlwbGUgcGF0aCwgbm90IHN1cmUgdGhhdCdzDQo+IHNv bWV0aGluZyB3ZSBubmVkIHRvIGludm9sdmUgb3Vyc2VsdmVzIGluDQo+IA0KPiAtIFRpbSBDaG93 bjogaXMgdGhpcyBhcHBsaWNhYmxlIHRvIG5ldHdvcmstaW50ZW5zaXZlIGFwcGxpY2F0aW9ucyB0 aGF0IG1pZ2h0DQo+IHVzZSAxLTIwR2JpdC9zLCBvciBvbmx5IGZvciBsb3cgc3BlZWQsIHRpbWUt c2Vuc2l0aXZlIGFwcGxpY2F0aW9ucz8NCj4gLSBFdGhhbjogbm8gcmVzdHJpY3Rpb24gb24gdGhh dC4NCj4gLSBQYXQgVGhhbGVyOg0KPiAtIFBhdWwgPz86IGRlZmluZSBob3cgd2UgcmV1c2UgZXhp c3RpbmcgbWVjaGFuaXNtcyBvZiBkZXRuZXQsIG5vdCBjcmVhdGluZw0KPiBuZXcgb25lcy4gKGNv bnRleHQgb2YgbGluayBhZ2csIG11bHRpY2FzdCwgZXRjKQ0KPiAtIFBhc2NhbCBUaHViZXJ0OiBJ IHRoaW5rIHdlIG5lZWQgdG8ga2VlcCBhZ2dyZWdhdGlvbiBpbiBzY29wZS4gUHV0dGluZyBiYWNr DQo+IHRvZ2V0aGVyIGEgZmxvdyB0aGF0IHdhcyBzcGxpdCBvdmVyIGRpZmZlcmVudCBwYXRocyBp cyBhbiBleHRyZW1lIGZvcm0gb24gdGhlDQo+IGVsaW1pbmF0aW9uIG9wZXJhaW9uIHRoYXQgdGhl IGRldCBsYXllciBkb2VzIGZvciB0aGUgcmVwbGljYXRpb24vZWxpbWluYXRpb24NCj4gc2Vydmlj ZSwgd2hlcmUgcGFja2V0cyBtYXkgYmUgbG9zdCBvbiBlaXRoZXIgc2lkZSBhbmQgaGF2ZSB0byBi ZSByZWNvbWJpbmVkDQo+IGFuZCByZW9yZGVyZWQNCj4gDQo+IC0gTm9ybSBGaW5uOiBPbiBzeW5j IGJldHdlZW4gODAyLjFUU04uIE5vcm0gRmlubiB0aGlua3MgdGhlcmUgaXMgZW5vdWdoDQo+IG92 ZXJsYXAgd2l0aCBwYXJ0aWNpcGF0aW9uIHRvIGtlZXAgRGV0TmV0IGFuZCA4MDIuMVRTTiBhbGln bmVkLg0KPiANCj4gDQo+ID4gKDEwOjQyIGFjdHVhbCkNCj4gPiAxMDozNSAoMjApICBUaXRsZTog RGV0TmV0IHNlcnZpY2UgbW9kZWwgLSBkaXNjdXNzaW9uDQo+ID4gICAgICAgICAgICAgUHJlc2Vu dGVyczogTG91IEJlcmdlciwgQmFsYXpzIFZhcmdhDQo+ID4gICAgICAgICAgICAgU2xpZGVzOg0K PiBodHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtZGV0 bmV0LTIucGRmDQo+IA0KPiBMb3UgaW50cm9kdWNlcyBjaGFpci1pbml0aWF0ZWQgZGlzY3Vzc2lv bnMuIE5leHQgdHdvIHRvcGljcyBhcmUgY2hhaXINCj4gaW50cm9kdWNlZCBhbmQgc3B1biBvZmYg dGhlIGRlc2lnbiB0ZWFtIGFuZCBhcmNoaXRlY3R1cmUgZG9jdW1lbnQgd29yay4NCj4gDQo+IEZp cnN0IHRvcGljIGJ5IEJhbGF6cyBpcyByZWxhdGVkIHRvIHNlcnZpY2UgbW9kZToNCj4gDQo+IExv dSBleHBsYWlucyB0aGUgZGlzdGluY3Rpb24gd2hldGhlciB0aGUgZGV0ZW50IHNlcnZpY2UgaXMg ZnJvbSB0aGUgZW5kIG5vZGUNCj4gKGFwcC8gc3lzdGVtcykgb3IgbmV0d29yayBlZGdlIG5vZGVz IChlbmQgbm9kZXMgbm90IHBhcnRpY2lwYXRpbmcpLg0KPiBPciBkbyB3ZSBuZWVkIC8gd2FudCBi b3RoLg0KPiANCj4gQmFsYXpzIHN1Z2dlc3RzIHdvcmsgbWF5IGJlIG5lZWRlZCBvbiB0ZXJtaW5v bG9neS4gRmxvd3MgY2FuIGJlIG9mDQo+IGRpZmZlcmVudCBuYXR1cmUsIElQLCBldGhlcm5ldCwg Li4uIGFuZCBlbmQgc3lzdGVtcyBhcmUgY29ubmVjdGVkIHRvIHRoZQ0KPiBuZXR3b3JrIHdpdGgg ZGlmZmVyZW50IHR5ZXMgb2YgaW50ZXJmYWNlcyAoTDIvTDMpDQo+IA0KPiBCYWxhenMgcmV2aWV3 cyB0aGUgdXNlIGNhc2VzIGFuZCBkaXNjdXNzZXMgaG93IHRoZSBzZXJ2aWNlIG1vZGVscyBhcHBs eS4NCj4gDQo+IEluIHJhZGlvIHVzZSBjYXNlLCByYWRpbyBhbmQgdHJhbnNwb3J0IGxheWVycyBh cmUgb2Z0ZW4gaW50ZWdyYXRlZCBmb3IgdGhpcw0KPiBzZXJ2aWNlLCBidXQgbm90IGZvciB4VlBO IHNlcnZpY2VzLg0KPiANCj4gRGlzY3Vzc2lvbjoNCj4gDQo+IC0gU3ViaXIgRGFzOiBjYW4geW91 IGV4cGxhaW4gd2hhdCBsaW5rcyBhcmU/IChvbiBzbGlkZSA8dW5udW1iZXJlZD4gdGl0bGVkDQo+ ICJwdXJwb3NlIG9mIHRoaXMgZGlzY3Vzc2lvbiIpDQo+IA0KPiAtIExvdTogdGhpcyBpcyBvbmUg d2F5IHRvIGRyYXcgdGhlIGxpbmUgb2Z3aHJlIHRoZSBmbG93cyBleGlzdC4gTGlua3MgYXJlDQo+ IGNvbm5lY3Rpb25zIGJldHdlZW4gbmV0d29yayBkZXZpY2VzLCBXZSBoYXZlIFAyUCBsaW5rcyBh bmQgc3VibmV0cyBpbiB0aGlzDQo+IGRyYXdpbmcuDQo+IA0KPiAtIFN1YmlyIERhczogYXJlIHRo ZXkgcGh5c2ljYWwgb3IgbG9naWNhbD8NCj4gDQo+IC0gTG91OiB3ZSBkbyBub3QgY29uc3RyYWlu IHRoYXQuIFdlIGluY2x1ZGUgZXhlbXBsZXMuDQo+IA0KPiAtIFN1YmlyIERhczoNCj4gLSBMb3U6 IGlmIHlvdSBkbyBub3QgbGlrZSB0aGUgcGljdHVyZSB0ZWxsIGhvdyBpdCBzaG91bGQgYmUgbGlr ZS4NCj4gLSBTdWJpciBEYXM6IGhvcHcgbWFueSBub2RlcyBuZWVkIHRvIHJ1biB0aGUgZGV0bmV0 IHNlcnZpY2UgaW4gdGhlDQo+IG5ldHdvcms/DQo+IA0KPiAtIExvdTogSSB1bmRlcnN0YW5kIHRo YXQgeW91IGZhdm9yIGVkZGdlIHRvIGVkZ2UgKDIgdG8gMiBvbiB0aGUgcGljdHVyZSkNCj4gDQo+ IC0gU3ViaXIgeWVzDQo+IA0KPiAtIE5vcm06IGhvcGUgd2UgY2FuIGRvIGl0IHRoYXQgd2F5LiB0 aGUgZW5kIHN0YXRpb24gaXMgZXhwZWN0ZWQgdG8gcGxhY2UgdGhlDQo+IHJlc2VydmF0aW9uIGFu ZCBtYXJrIHRoZSBwYWNrZXRzLiB3ZSBoYXZlIHVzZSBjYXNlcyB0b2RheSB3aGVyZSB0aGUgZW5k DQo+IHBpb3VpbnQgYXJlIHJlcXVlc3RpbmcgdGhlIHNlcnZpY2UuIFRoZSBub2RlcyByZWNvZ25p emUgdGhleSBhcmUgdGhlIHNwZWNpZmljDQo+IGRldG5ldCBmbG93cy4gZW5kIHN5c3RlbXMgYXJl IG1ha2tpbmcgdGhlIGFwY2tldHMgc3BlY2lmaWNhbGx5Lg0KPiANCj4gLSBMb3U6IGhvdyBkb2Vz IHRoZSBlbmQgbm9kZSBzZWUgdGhhdD8NCj4gDQo+IC0gTm9ybTogSSdtIHRhbGtpbmcgYWJvdXQg VFNOLiBJbiBnZW5lcmFsLCB0aGVyZSdzIHNvbWV0aGluZyBpbiB0aGUgaG9zdCB0aGF0DQo+IGlz IGF3YXJlIHRoYXQgdGhlcmUgaXMgVFNOLiBUaGF0IHNvbWV0aGluZyBpcyBhd2FyZSBvZiAyIHBv cnRzOyBvbmUgZm9yDQo+IG5vcm1hbCB0cmFmZmljIGJ1dCBjYXBhYmxlIHRvIHVzZSBib3Rocy4g TXkgY2hvaWNlIGlzIGFic29sdXRlbHkgMywgYm90aCBjYXNlcw0KPiAxIGFuZCAyLiBrZWVwaW5n IEwyIGFuZCBMMyBzZXBhcmF0ZSBpcyBleHRyZW1lbHkgaW1wb3J0YW50LCBidSBkZXRuZXQgaXMg bm90DQo+IGZvcndhcmRpbmcuIEEgZGV0bmV0IHNlcnZpY2UgaXMgYSBjaGFpbiBvZiBib3hlcyBh bmQgd2lyZXMgYW5kIHF1ZXVlcy4gVGhleQ0KPiBhcmUgbm90IG5lY2Vzc2FyaWx5IG9mIG9uZSB0 eXBlLCBMMiB2cy4gTDMuIFRoZSBzZXJ2aWNlIHdlIGFyZSBvZmZlcmluZyBpcyBRb1MNCj4gbm90 IGZvcndhcmRpbmcsIG5vdCBsYXllciBzcGVjaWZpYy4gQSByZWxheSBzeXN0ZW0gaGFzIHRvIHBp Y2sgYSBwYWNrZXQgYW5kDQo+IGFwcGx5IGEgc2VydmljZSwgaXQgZG9lcyBub3QgbWF0dGVyIHdo aWNoIHRlY2hub2xvZ3kvbGF5ZXIgZ290IHRoZSBwYWNrZXQgaW4NCj4gdGhlIHJlbGF5IHN5c3Rl bS4NCj4gDQo+IC0gU2FtaXRhIENoYWtyYWJhcnRpOiBUU04gaXNsYW5kIGNvbmVjdGVkIHRvIG5v bi1UU04gaXNsYW5kDQo+IA0KPiAtIExvdTogdGhhdCdzIGEgZm9ybSBvZiBjYXNlIDINCj4gDQo+ IC0gU0M6IE9uZSBlZGdlIG5vZGUgY291bGQgaG9zdCBhcHBsaWNhdGlvbg0KPiANCj4gLSBMb3U6 IHRydWUuIEFuIGVkZ2Ugbm9kZSBpcyBhIHNwZWNpYWwgY2FzZSBvZiBhcHBsaWNhdGlvbg0KPiAN Cj4gLSBTQyA6IGNvdWxkIGJlIGEgcG9pbnQgb2YgcG9saWN5IGVuZm9yY2VtZW50DQo+IA0KPiAt IExvdTogdHJ1ZQ0KPiANCj4gLSBTdWJpciBEYXM6IGFyZSB3ZSBnb2luZyB0byBkbyBkZXRuZXQg YXMgYW4gYXBwbGljYXRpb24gc2VydmljZT8NCj4gDQo+IC0gTG91OiB3aWxsIG5vdCBkbyBhIHNv Y2tldCBpbnRlcmZhY2UNCj4gDQo+IC0gTG91OiBhc2tpbmcgdGhlIHNlbnNlIGluIHRoZSByb29t LiBvbmx5IG9uZSBvciB0d28uIFdobyBpbiB0aGUgcm9vbQ0KPiBiZWxpZXZlcyB3ZSBzaG91bGQg ZG8gYSBuZXR3b3JrIGJveCAgYXBwbGljYXRpb24gKGNhc2UgMSkgLSBmZXcNCj4gICBDYXNlIDIg LSBtb3JlDQo+IC0gUGF0IFRoYWxlcjogd2hvIHRoaW5rcyBjYXNlIDEgaXMgaW1wb3J0YW50IHRv IGNvdmVyOiBzZXZlcmFsIGhhbmQNCj4gLSBQYXQgVGhhbGVyOiB3aG8gdGhpbmtzIGNhc2UgMiBp cyBpbXBvcnRhbnQgdG8gY292ZXI6IHNldmVyYWwgaGFuZCAoc2xpZ2h0bHkNCj4gbW9yZSkNCj4g DQo+IC0gTG91OiBhc2tzIHRoZSBzZW5zZSBvZiByb29tIG9uIHByaW9yaXRpemF0aW9uIGJldHdl ZW4gY2FzZSAxIGFuZCAyLg0KPiBIYW5kcyBzaG93bi4uIG5vIHJlYWwgd2lubmVyLg0KPiANCj4g PiAoQWN0dWFsIDExOjA4KQ0KPiA+IDEwOjU1ICgxNSkgIFRpdGxlOiBEZXROZXQgdGVybWlub2xv Z3kgLSBkaXNjdXNzaW9uDQo+ID4gICAgICAgICAgICAgUHJlc2VudGVyOiBOb3JtIEZpbm4NCj4g PiAgICAgICAgICAgICBTbGlkZXM6DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv OTUvc2xpZGVzL3NsaWRlcy05NS1kZXRuZXQtMy5wZGYNCj4gPg0KPiANCj4gTm9ybSBGaW5uIG9u IHRlcm1pbm9sb2d5IGRpc2N1c3Npb24NCj4gTm9ybSBub3RlcyB0aGF0IExvdSBjb250cmlidXRl ZCBoZWF2aWx5IG9uIHRoaXMgc2xpZGV3YXJlDQo+IA0KPiBOb3JtIG5vdGUgc3RoYXQgdGhlcmUg YXJlIG1hbnkgd2F5cyB0byBuYWlsIGEgcGF0aCBkb3duLiBJZiB3ZSBwaWNrIGEgdGVybQ0KPiB0 YWh0IGNvaW5jaWRlcyB3aXRoIHNvbWUgZXhpc3RpbmcgZHJhZnQgKGVnIGZyb20gc2VnbWVudCBy b3V0aW5nKSBpdCBkb2VzIG5vdA0KPiBtZWFuIHRoYXQgd2UgY2hvc2UgdG8gd29yayB3aXRoIHNl Z21lbnQgcm91dGluZy4NCj4gDQo+IE5vcm0gc2hvd3MgdGVybXMgdGhhdCBhcmUgdXNlZCBpbiB2 YXJpb3VzIHRlY2hub2xvZ2llcy4gV291bGQgYmUgbmljZSB0bw0KPiBwaWNrIHNvbWUuDQo+IA0K PiBBbm90aGVyIGFuZ2xlIHNob3dzIGEgc291cmNlIG9uIHRoZSBsZWZ0IChtYXliZSBub3QgYXdh cmUgb2YgZGV0bmV0KSBhbmQNCj4gb24gdGhlIHJpZ2h0LCBhIGxpc3RlbmVyIHRoYXQgaXMgYXdh cmUgYW5kIHRlcm1pbmF0aW5nIHRoZSBzZXJ2aWNlLiBXZQ0KPiBkZWZpbml0ZWx5IGhhdmUgdXNl IGNhc2VzIGxpa2UgdGhhdC4NCj4gDQo+IE5vcm0gZXhwcmVzc2VzIGRlc2lyZSB0byBwaWNrIHRl cm1zLiBlZyBkZXRlcm1pbml0aWMgZmxvdyBlbmQgdG8gZW5kIGdvaW5nDQo+IG92ZXIgYSBkZXRu ZXQgc2VydmljZQ0KPiANCj4gPC4uLj4NCj4gDQo+IC0gTG91OiBwaWNrIHlvdXIgZmF2b3JpdGUg dGVjaG5vbG9neQ0KPiANCj4gLSBOb3JtOiBkcmF3aW5naXNzdWUuIEluIHRoZSBhcmNoaXRlY3R1 cmUgd2UgZG8gbm90IG1ha2UgYSBkaWZmZXJlbmNlIGJ5DQo+IGxheWVyLg0KPiANCj4gLSBMb3U6 IHlvdSBhcmUgYXQgdGhlIGRldG5ldCBsYXllciBhbmQgdGhlIHN1Ym5ldCBpcyB0aGUgbmV0d29y ayB0aGF0IHlvdSBhcmUNCj4gdXNpbmcuIFRoYXQgZG9lcyBub3QgbWVhbiBhbiBJUCBzdWJuZXQu DQo+IA0KPiAtIE5vcm06IGdyZWF0LiB0aGUgc3VibmV0IG9uIHRoZSBwaWN0dXJlIG1heSBvcGVy YXRlIGF0IGFueSBsYXllciwgYXMgbG9uZyBhcw0KPiBpdCBwcm92aWRlcyB0aGEgc2VydmNpZXMg dGhhdCBkZXRuZXQgbmVlZHMuDQo+IA0KPiAtIExvYSBBbmRlcnNzb246IHdoeSBub3QgY2FsbCBz dWJuZXQgYXMgYSBkZXRuZXQgc3VibmV0d29yay4NCj4gDQo+IC0gTCBBIHdoZXJlIGQgdGhlIGFy cm93cyBvbiA3ICBzdGFydD8NCj4gDQo+IC0gTG91OiB3ZSBrZXB0IHRoZSBhcnJvd3MgZW5kcG9p bnRzIHZhZ3VlIHRvIGdldCB0aGUgZGlzY3Vzc2lvbiBnb2luZy4NCj4gDQo+IC0gTCBBOiBvbiBh cnJvdyA2IHRoYXQncyBpcyBjbGVhcmx5IGVuZGluZw0KPiANCj4gLSBMb3U6IHllcyBiZWNhdXNl IHRoYXQgaXMgdGhlIGVuZCB0byBlbmQgc2VydmljZQ0KPiANCj4gMS4gRW5kIHN5c3RlbSAtPg0K PiAyLiBFZGdlIG5vZGUgLT4NCj4gMy4gTmV0d29yayBub2RlIC0+DQo+IDQuIFN1YiBuZXR3b3Jr IC0+IGRldG5ldCBzdWIgbmV0d29yaw0KPiA1LiBsaW5rIC0+DQo+IDYuIERldGVybWluaXN0aWMg ZmxvdyAtPg0KPiA3LiBEZU5ldCBGbG93IC0+DQo+IA0KPiAtIFRpbSBDaG93bjogTmVlZCAyIGRp YWdyYW1zPyAob25lIGVuZCB0byBlbmQsIG9uZSBlZGdlIHRvIGVkZ2UpIEl0IHNlZW1zDQo+IG9k ZCB0byBoYXZlIGEgJ0RldGVybWluaXN0aWMgZmxvdycgZW5kIHRvIGVuZCB3aGVyZSBvbmx5IHBh cnQgb2YgdGhlIHBhdGggaXMgYQ0KPiBEZXROZXQgZmxvdy4NCj4gDQo+IC0gTm9ybSBGaW5uOiBj b25mdXNpb24gaXMgdGhhdCB0aGlzIGRpYWdyYW0gbG9va3MgbGlrZSBhIHN0YWNrIGRpYWdyYW0g YnV0IGl0IGlzDQo+IG5vdCwgaXQgaXMgbG9va2luZyBhdCB0aGUgbmV0d29yayBmcm9tIGFib3Zl Lg0KPiANCj4gLSBCYWxhenMgVmFyZ2E6IGRldG5ldCBmbG93IGNhbiBiZSB0aGUgc2FtZSBhcyBk ZXRlcm1pbmlzdGljIGZsb3cuIFRoZXJlIGFyZQ0KPiBjYXNlcyB3aGVyZSB0aGV5IGFyZSBhbHNv IGRpZmZlcmVudCBhbmQgd2UgbmVlZCB0byBiZSBhYmxlIHRvIGRpc3Rpbmd1aXNoDQo+IG5ldHdl ZW4gdGhvc2UuIFRodXMgdHdvIGFycm93cy4NCj4gDQo+IE5vcm0gYnJpbmdzIHVwIHNsaWRlICJz aW1wbGUgZXhhbXBsZTouLi4iDQo+IA0KPiBOb3JtIEZpbm46IHByb3Bvc2VzIHRoYXQgdGhlIGRl dG5ldCBkYXRhcGxhbmUgYWxlcm5hdGl2ZXMgZHJhZnQgaHMgdGhlIG1vc3QNCj4gcGVvcGxlIHdv cmtpbmcgb24gaXQsIGFuZCB0aGF0IGl0IHNob3VsZCBiZSB0aGUgcmVmZXJlbmNlIHRvIGFsaWdu IHRvLg0KPiANCj4gLSBMb3UgQmVyZ2VyOiBnb29kIGlkZWEuIFdlIHNob3VsZCBub3QgY29uc3Ry YWluIHRoZSBzcGVjaWZpY3Mgb2YgdGhhdCB5ZXQuDQo+IFdvdWxkIGJlIGEgc2hhbWUgaWYgdGhl IHRlcm1pbm9sb2d5IGRvZXMgbm90IGFsaWduIHdpdGggdGhlIHNvbHV0aW9uLiBXZQ0KPiBzaG91 bGQgc3RhcnQgd2l0aCB0aGUgZGF0YXBsYW5lIGFuZCBrZWVwIGl0IG9wZW4uDQo+IA0KPiAtIEph bm9zOiBiYWNrIHRvIGJvdGggb3B0aW9ucy4gSWYgd2UgcHJvdmlkZSBib3RoLCBhIHNpbmdsZSBu YW1lIGJlY29tZXMNCj4gY29uZnVzaW5nLg0KPiANCj4gLSBMb3UgQmVyZ2VyOiBXZSB3aWxsIHBy b3Bvc2UgdG8gZm9sbG93IE5vcm0ncyBwcm9wb3NhbCBvZiBhbGlnbmluZyBEZXROZXQNCj4gdGVy bWlub2xvZ3kgd2l0aCB0aGUgZGF0YSBwbGFuZSB0ZXJtaW5vbG9neQ0KPiANCj4gPiAxMToxMCAo MjApICBUaXRsZTogRGV0TmV0IGFyY2hpdGVjdHVyZSAtIHVwZGF0ZQ0KPiA+ICAgICAgICAgICAg IFByZXNlbnRlcjogTm9ybSBGaW5uDQo+ID4gICAgICAgICAgICAgRHJhZnQ6DQo+IGh0dHA6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZpbm4tZGV0bmV0LWFyY2hpdGVjdHVyZS0wMw0KPiA+ ICAgICAgICAgICAgIFNsaWRlczoNCj4gaHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85 NS9zbGlkZXMvc2xpZGVzLTk1LWRldG5ldC00LnBkZg0KPiANCj4gDQo+IE5vcm0gcHJlc2VudHMg YXJjaGl0ZWN0dXJlIGRyYWZ0LiBTbGlkZXMgdW5jaGFuZ2VkIG1vc3RseSBmcm9tIGxhc3QgbWVl dGluZy4NCj4gUHJlc2VudHMgc2xpZGUgIm9iamVjdGl2ZS9nb2FscyIuIFdlIHdhbnQgdG8gaW52 ZW50IHRoZSBsZWFzdCBwb3NzaWJsZS4gVGhlcmUNCj4gYXJlIGFzc3VtcHRpb25zIGxpa2UgZml4 ZWQgdGhyb3VnaHB1dCBhbmQgbm8gdGhyb3R0bGluZy4NCj4gDQo+IE5vcm0gZ2l2ZXMgYSBzdGF0 dXMuIEJpZ2dlc3QgY2hhbmdlIGlzIHRlcm1pbm9sb2d5LCBlZyBzdHJlYW0tPiBkZXRuZXQgZmxv dywNCj4gc2VhbWxlc3MgcmVkdW5kYW5jeSBiZWNhbWUgcGFja2V0IHJlcGxpY2F0aW9uIGFuZCBk ZWxldGlvbi4NCj4gDQo+IE5vcm0gcHJlc2VudHMgZXNzZW50aWFsIGFzcGVjdHMuIFdlIGFyZSBu b3QgdGFsa2luZyBhYm91dCBmYXVsdCBkZXRlY3Rpb24NCj4gYW5kIHJlbWVkaWF0aW9uLCB3aGlj aCBjb3VsZCBiZSBmdXR1cmUgd29yay4gV2UgYXJlIHRhbGtpbmcgYWJvdXQgc2VuZGluZw0KPiB0 aGUgcGFja2V0cyB0d2ljZS4gdGhlIG1vZGVsIGFsbG93cyBib3RoIGVuZCBzdGF0aW9uIGFuZCBj ZW50cmFsIGNvbnRyb2xsZXJzDQo+IHBhbGNpbmcgcmVzZXJ2YXRpb25zLg0KPiANCj4gTm9ybSBw cmVzZW50cyBvcGVuIGlzc3VlczogTm9ybSB0aGlua3MgdGhhdCB6ZXJvIGNvbmdlc3Rpb24gbG9z cyByZXF1aXJlcw0KPiBwZXIgZmxvdyBzdGF0ZS4gVEJEIGlzIHRoZSBzdHJlYW0gaWRlbnRpZmlj YXRpb24uIFRoZSAoZHQpIGRhdGEgcGxhbmUgZG9jdW1lbnQNCj4gcHJvdmlkZXMgaW5mcm9tYXRp b24gb24gdGhhdCB3aGljaCB0aGUgYXJjaGl0ZWN0dXJlIG5lZWRzIHRvIGVjaG8uDQo+IA0KPiAt IFJvbGFuZCBCbGVzczogTWF5YmUgZGlmZnNlciBjb3VsZCBwcm92aWRlIHJlcXVpcmVkIHF1YXJh bnRlZXMuDQo+IC0gTm9ybSBGaW5uOiBFcm0gbm8uIC4uZ29lcyBpbnRvIGV4cGxhaW5pbmcgcmVz ZXJ2YXRpb25zLCBldGMuDQo+IA0KPiAtIFNoYWhyYW0gRGF2YXJpOiBpcyBvbmUgb2YgdGhlIGdv YWxzIG5vdCB0byBrZWVwIHRoZSBvcmRlciBvZiB0aGUgcGFja2V0cy4NCj4gLSBOb3JtIEZpbm46 IGlmIHlvdSBsb29rIGludG8gdGhpcyB3ZSBtYXkgZGlzY292ZXIgdGhhdCB3ZSBjYW4gYWRkIGFz IGEgZ29hbA0KPiBlYXNpbHkuDQo+IC0gU2hhcmFtIERhdmFyaTogaXQgaXMgbm90IGNoZWFwLg0K PiAtIE5vcm0gRmlubjogZG9uZSBhdCB0aGUgdXBwZXIgbGF5ZXJzLg0KPiAtIFNoYXJhbSBEYXZh cmk6IGRpZmZzZXJ2IGlzIHByZWZlcmFibGUgYW5kIGFjaG9pZXZlYWJsZSBpZiB3ZSBzaGFwZSBv biBldmVyeQ0KPiBub2RlIGFuZCBlbm91Z2ggYnVmZmVyaW5nLg0KPiAtIE5vcm0gRmlubjogaWYg eW91IGhhdmUgZW5vdWdoIGJ1ZmZlcmluZyBhbmQga25vdyB0b3BvbG9neSBkaWZmc2VyIGNhbiBk bw0KPiB0aGUgam9iLiBJbiBzb21lIHRvcG9sb2dpZXMganVzdCBkb24ndCBkbyBpdCAoZXhhbXBs ZSBvZiByaW5nIGluDQo+IGluZGlzdHJpYWwpDQo+IC0gUGF0IFRoYWxlcjogZ29pbmcgYmFjayB0 byBhcmNoaXRlY3R1cmUuLiBub24gZW5naW5lZXJlZCBwbHVnIGFuZCBwbGF5IGlzIHBhcnQNCj4g b2YgdGhlIHNjb3BlLg0KPiAtIExvdSBCZXJnZXI6IGl0IGltcG9ydGFudCB0aGUgYXJjaGl0ZWN0 dXJlIGRvY3VtZW50IGRvZXMgbm90IGdvIHRvbyBtdWNoDQo+IGludG8gc3BlY2lmaWMgaW1wbGVt ZW50YXRpb25zLg0KPiAtIExvdSBCZXJnZXI6IG9uZSByZXZzIG9mIHRoZSBhcmNoaXRlY3R1cmUg YW5kIHRoZW4gYWRvcHQuDQo+IC0gTm9ybSBGaW5uOiBoYXZpbmcgYW4gYXJjaGl0ZWN0dXJlIGRv YyBpcyBpbXBvcnRhbnQgdG8ga2VlcCBhc3N1bXB0aW9ucw0KPiBhbGlnbmVkLg0KPiAtIFRpbSBD aG93bjogZG8gd2Ugd2FudCBhbiBlbnZpcm9ubWVudCB3aXRoIHByaXZhY3kgc3VwcG9ydCAoZS5n LiBtaWdodA0KPiBoYXZlIGR5bmFtaWMgTDIgYWRkcmVzc2VzLCBvciA1LXR1cGxlIGhpZGRlbiBk dWUgdG8gSVBzZWMgZXRjKQ0KPiAtIExvdSBCZXJnZXI6IGdvb2Qgb3Bwb3J0dW5pdHkgdG8gbG9v ayBhdCBkb2MgYW5kIHNlZSB3aGVyZSB0aGVyZSBhcmUNCj4gY29uY2VybnMgYW5kIHBvc3QgdG8g dGhlIGxpc3QuIFRvIE5vcm06IGRvIHlvdSB3YW50IHRvIGFkZHJlc3MgY29tbWVudHMgYXMNCj4g aW5kaXZpZHVhbCBzbyB5b3UgcGxhY2UgeW91ciBvd24gaWRlYXMsIG9yIGRvIHlvdSB3YW50IHRv IGJlIHRoZSBlZGl0b3IgZm9yDQo+IHRoZSBXRyBhZnRlciBhZG9wdGlvbj8NCj4gDQo+IC0gTm9y bSBGaW5uOiBBbGlnbm1lbnQgaXMgYmV0dGVyIG5vdyB3aXRoIHRlcm1pbm9sb2d5LiBCZXR0ZXIg cHV0IHRoZSBjYWxsDQo+IG91dCB0byBnZXQgb3BpbmlvbnMgc29vbmVyIHRoYW4gbGF0ZXIuDQo+ IC0gTG91IEJlcmdlcjogUG9sbCAtLSBhc2tzIGhvdyBtYW55IGhhcyByZWFkIHRoZSBhcmNoIGRv Yy4gQSBnb29kIG51bWJlci4NCj4gLSBMb3UgQmVyZ2VyOiBQb2xsIC0tICBob3cgbWFueSB0aGlu a3MgaXQgaXMgYSBnb29kIGJhc2lzIGZvciB0aGUgV0cNCj4gZG9jdW1lbnQuIE1vcmUuDQo+IC0g TG91IEJlcmdlcjogYXNrIE5vcm0gdG8gZG8gb25lIG1vcmUgcm91bmQgdG8gYWxpZ24gd2l0aCBt ZWV0aW5nDQo+IGRpc2N1c3Npb25zIGFuZCB0aGVuIHdpbGwgY2FsbCBmb3IgYWRvcHRpb24uDQo+ IA0KPiAtIExvdSBCZXJnZXI6ICh0byBXRykgd2hlbiBzdXBwb3J0aW5nIGFkb3B0aW9uIHBsZWFz ZSBtZW50aW9uIHdoYXQgeW91DQo+IHdhbnQgYWRkcmVzc2VkIGluIHRoZSBmaXJzdCBXRyByZXYu IFRoaXMgcmFpc2VzIHRoZSBpbXBvcnRhbnRjZSBvZiB0aGUgaXNzdWUNCj4gcmFpc2VkLg0KPiAN Cj4gPiAxMTozMCAoMzApICBUaXRsZTogRGF0YSBQbGFuZSBBbHRlcm5hdGl2ZXMgRGVzaWduIFRl YW0gLSByZXBvcnQNCj4gPiAgICAgICAgICAgICBQcmVzZW50ZXI6IEpvdW5pIGtvcmhvbmVuDQo+ ID4gICAgICAgICAgICAgRHJhZnQ6IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1k dC1kZXRuZXQtZHAtYWx0LTAwDQo+ID4gICAgICAgICAgICAgU2xpZGVzOg0KPiBodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtZGV0bmV0LTUucGRmDQo+ IA0KPiANCj4gSm91bmkgcHJlc2VudHMgdGhlIHN0YXR1cyBvZiB0aGUgZGVzaWduIHRlYW0gd29y ayBvbiBkYXRhcGxhbmUuDQo+IERpc2NsYWltZXJzLCBkb2MgaXMgZmFyIGZyb20gcmVhZHksIFdJ UC4gSm91bmkgcHJlc2VudHMgdGhlIGRlc2lnbiB0ZWFtLg0KPiANCj4gSm91bmkgcHJlc2VudHMg dGhlIGdvYWxzLCBldmFsdWF0ZSBzdWl0YWJpbGl0eSBvZiBleGlzdGluZyB0ZWNobm9sb2dpZXMg Zm9yDQo+IGRldG5ldC4NCj4gQWxzbyBub24gZ29hbHM6IHRoZSBkb2N1bWVudCBkb2VzIG5vdCBz ZWxlY3QgdGVjaG5vbG9naWVzLCBkb2VzIG5vdA0KPiBjb25zaWRlciB0aGUgY29udHJvbCBwbGFu ZS4NCj4gDQo+IEpvdW5pIGludHJvZHVjZXMgdGhlICBkZXRuZXQgdmlldyBvZiBsYXllcmluZywg d2l0aCBhICJkZXRuZXQgc2VydmljZSBsYXllciINCj4gYW5kIGEgImRldG5ldCB0cmFuc3BvcnQg bGF5ZXIiLiBUaGlzIHBhcnRpdGlvbiBpcyB1c2VkIHRvIHN0cnVjdHVyZSB0aGUNCj4gZG9jdW1l bnQuDQo+IA0KPiBKb3VuaSBwcmVzZW50cyAiV2h5PyIgdGVjaG5vbG9naWVzIGFyZSBzZWxlY3Rl ZCBhbmQgc3R1ZGllZCwgd2hpY2gNCj4gcHJvcGVydGllcyB3ZXJlIGZvdW5kIG9mIGludGVyZXN0 IGZvciBkZXRuZXQgc2VydmljZXMuIE9ic2VydmVzIHRoYXQgYSBsb3Qgb2YNCj4gZGlzY3Vzc2lv biB3YXMgZm9jdXNlZCBvbiByZXBsaWNhdGlvbiBhbmQgZGVsZXRpb24sIHdoaWNoIGxheWVyIGRv ZXMgd2hhdC4NCj4gDQo+IEdvYWwgaXMgdG8gY2FsbCBmb3IgYWRvcHRpb24gYWZ0ZXIgMDEsIHdo aWNoIG1heSBhZGQvcmVtb3ZlIGFsdGVybmF0aXZlcy4NCj4gDQo+IC0gTG91IEJlcmdlcjogd2hh dCBzaG91bGQgdGhlIERUIGRvIGFmdGVyIHRoYXQ/IElzIHRoZXJlIGEgbG9naWNhbCBuZXh0IHN0 ZXA/DQo+IA0KPiAtIEpvdW5pIEtvcmhvbmVuOiBGb2xsb3cgbm9ybWFsIFdHIHByb2Nlc3MNCj4g DQo+IC0gTG91IEJlcmdlcjogcGVvcGxlIGRvIG5vdCBuZWVkIHRvIGJlIGluIHRoZSBEVCB0byBj b250cmlidXRlLiBTZW5kIHRleHQgdG8NCj4gdGhlIGNoYWlycy4gTm93IGlzIHRoZSB0aW1lIGZv ciBldmVyeW9uZSBjb25jZXJuZWQgdG8gc3BlYWsgdXAuDQo+IA0KPiAtIFN0ZXdhcnQgQnJ5YW50 OiA8amFiYmVyPlBXcyBkb24ndCByZWFsbHkgaGF2ZSBzZXF1ZW5jaW5nIC0gbGFzdCBzbGlkZQ0K PiAtIGl0J3Mgb25seSB0aGVyZSBmb3IgdGhlIFRETSBQV3MgaW4gcHJhY3Rpc2UNCj4gDQo+IC0g VW1hIENodW5kdXJ5OiBpcyBnb2FsIHRvIHBpY2sgdXAgYSB0ZWNobm9sb2d5IGFuZCB0aGVuIGZp eCB0aGUgZ2Fwcz8NCj4gDQo+IC0gSm91bmkgS29yaG9uZW46IHllcw0KPiANCj4gLSBFcmlrIE5v cm1hcms6IGhvdyB3b3VsZCB0aGluZ3Mgd29yayB0b2dldGhlciwgZGV0bmV0IGFuZCBSVFANCj4g DQo+IC0gSm91bmkgS29yaG9uZW46IFJUUCBwcm92aWRlcyBzZXJ2aWNlcyB0aGF0IGRvIG1vc3Qg b2Ygd2hhdCB3ZSBuZWVkIGhlcmUNCj4gaW4gZGV0bmV0LCBzZXFlbmNpbmcsIGR1cGxpY2F0ZSBl bGltaW5hdGlvbi4uLg0KPiANCj4gLSBMb3U6IHRoZXJlIGFyZSB0aGluZ3MgaW4gdGhlIGRjIHRo YXQgd2lsbCBuZWVkIHRvIGJlIHRocm93biBvdXQuDQo+IA0KPiAtIElseWEgVmVyc2hrb3Y6IHBh Y2tldHMgb3V0IG9mIG9yZGVyLCByZW9yZGVyaW5nLiBJcyB0aGF0IGEgZ29hbD8gbGlzdCBvZg0K PiByZXF1aXJlbWVudHMuDQo+IA0KPiAtIFBhdDogd2UgcHV0IHRoZW0gaW4gb3JkZXINCj4gDQo+ IC0gTG91OiB3ZSdsbCBkZXRlcm1pbmllIHdpaGNoIHdlIGFyZSByZWFsbHkgZ29ubmEgZG8uDQo+ IA0KPiAtIFl1YW5sb25nIEppYW5nOiBudW1iZXIgOTogd2hhdCBkbyB5b3UgbWVhbj8NCj4gDQo+ IC0gSm91bmk6IHJlY2VpdmluZyBwYWNrZXQgdGhhdCB5b3UgYXJlIG5vdCBzdXBwb3NlZCB0byBy ZWNlaXZlZC4gd2hpY2ggbm9kZSBpcw0KPiBtaXNiZWhhdmluZz8gZWcgaWYgdGhlcmUgaXMgZHVw bGljYXRpb24gaW4gdGhlIG5ldHdvcmssIG5lZWQgdG8gZGV0ZXJtaW5lIHRoZQ0KPiBub2RlIHRo YXQgcGVyZm9ybWVkIHRoZSBkdXBsaWNhdGlvbi4NCj4gDQo+IC0gWXVhbmxvbmcgSmlhbmc6IG5v dCBzdXJlIHdlIG5lZWQgdG8gZGlzdGluZ3Vpc2ggPz8/DQo+IA0KPiAtIEpvaG4gTWVzc2VuZ2Vy OiBpdCdzIE9BTSBwYXJ0IG9mIHRpbWUgc3luY2hyb25pemF0aW9uLiBUaGUgZGF0YXBsYW5lIGlz DQo+IHRoZSBvbmx5IHBsYWNlIHd3aGVyZSB5b3UgY2FuIGRvIHRoYXQuDQo+IA0KPiAtIFl1YW5s b25nIEppYW5nOiB0aW1lIGZsb3dzIG9mIE1QTFMgcGFja2V0cy4NCj4gDQo+IC0gTG91OiB5ZXMs IHRoZXJlJ3MgMTU4OCBvdXQgdGhlcmUsIGRpc2N1c3Npb24gaXMgd2hldGhlciB0aGVyZSBhcmUg Z2FwcyB0aGF0DQo+IHdlIGlkZW50aWZ5LiBJZiB0aGVyZSB3YXMgbm90aGluZyB0byBkbyB3ZSB3 b3VsZCBub3QgaGF2ZSBhIFdHIDspDQo+IA0KPiANCj4gPiAxMjowMCAoMTUpICBUaXRsZTogRGV0 ZXJtaW5pc3RpYyBOZXR3b3JraW5nIFJlcXVpcmVtZW50cyBvbiBEYXRhIGFuZA0KPiBDb250cm9s IFBsYW5lDQo+ID4gICAgICAgICAgICAgUHJlc2VudGVyOiBZaXlvbmcgWmhhDQo+ID4gICAgICAg ICAgICAgRHJhZnQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC16aGEtZGV0 bmV0LXJlcXVpcm1lbnRzLTAwDQo+ID4gICAgICAgICAgICAgU2xpZGVzOg0KPiBodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtZGV0bmV0LTYucGRmDQo+ IA0KPiANCj4gWWl5b25nIFpoYSBwcmVzZW50cyByZXF1aXJlbWVudCBkcmFmdA0KPiBZaXlvbmcg WmhhIHJldmlld3MgdGhlIGFyY2hpdGVjdHVyZSBhbmQgdGhlbiBNUExTIGFzIGEgY2FuZGljYXRl IHRvIHN1cHBvcnQNCj4gZGV0bmV0IHRyYW5zcG9ydC4gQW5hbHlzZXMgb3BlbiBxdWVzdGlvbnMg dG8gZ2V0IHRoZXJlLiBMU1Agc2V0dXAuIFN1cHBvcnQNCj4gTDIgdGVjaCBzdWNoIGFzIFBXLg0K PiANCj4gWWl5b25nIFpoYSBwcmVzZW50cyBuZWVkcyBhbmQgaXNzdWVzIGZvciBkZXRuZXQgZmxv dyBpZGVudGlmaWNhdGlvbiwgYW5kDQo+IHByb3Bvc2VzIGFsdGVybmF0aXZlcyBsaWtlIG5ldHdv cmsgYWRkZWQuDQo+IA0KPiBZaXlvbmcgWmhhIHByZXNlbnRzIFRTTi4NCj4gDQo+IC0gR3JlZyBN aXJza3k6IHlvdSBhc3N1bWUgdGhhdCBhIHBhcnRpY3VsYXIgdGVjaG5vbG9neSBjYW4gZ3VhcmFu dGVlIGRlbGF5LiBJDQo+IGJlbGlldmUgdGhhdCB3ZSBuZWVkIHBlcmZvcm1hbmNlIG1lYXN1cmVt ZW50IHRvIGNvbmZpcm0gdGhhdCB0aGUgc2VydmljZQ0KPiBsZXZlbCBjb25mb3JtcyBTTEEsIGVs c2UgYWN0aW9ucyBhcmUgdG8gYmUgdGFrZW4uIEkgZG8gbm90IHRoaW5rIHRoYXQgYQ0KPiBkYXRh cGxhbmUgdGVjaG5vbG9neSBpcyBhIGd1YXJhbnRlZSBhbmQgcmVtb3ZlcyB0aGUgbmVlZCBmb3Ig dmFsaWRhdGlvbg0KPiB0aHJvdWdoIG1lYXN1cmVtZW50Lg0KPiANCj4gLSBMb3UgbGl0dGxlIHRp bWUgbGVmdCwgY29tbWVudHMgdGhyb3VnaCB0aGUgbGlzdC4NCj4gLSBMb3U6IHdoYXQgZ29hbCBm b3IgdGhpcyBkb2M6DQo+IC0gWWl5b25nIFpoYTogbmVlZCBmZWVkYmFjayBmcm9tIHRoZSBncm91 cCBmb3IgdGhhdA0KPiA+DQo+ID4gMTI6MTUgKDE1KSAgVGl0bGU6IEludGVncmF0ZWQgTW9iaWxl IEZyb250aGF1bCBhbmQgQmFja2hhdWwNCj4gPiAgICAgICAgICAgICBQcmVzZW50ZXI6IEphbWVz IEh1YW5nDQo+ID4gICAgICAgICAgICAgRHJhZnQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1odWFuZy1kZXRuZXQteGhhdWwtMDANCj4gPiAgICAgICAgICAgICBTbGlkZXM6 DQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1k ZXRuZXQtNy5wZGYNCj4gDQo+IEphbWVzIEh1YW5nIHByZXNlbnRzIGV0aGVybmV0IGFzIGEgY2Fu ZGlkYXRlIGZvciBkZXRuZXQgdHJhbnNwb3J0DQo+IChmcm9udGhhdWwgYW5kIGJhY2toYXVsKSBh bmQgY29tcGFyZXMgd2l0aCBvdGhlcnMgbGlrZSBJUCBhbmQgTVBMUy4NCj4gDQo+IEZvciBNUExT OiBtaXNzaW5nIHJhZGlvIG92ZXIgTVBMUy4gVGhlbiBkaXNjdXNzZXMgc3VwcG9ydCBvZiAvIENQ UkkNCj4gYXdhcmVuZXNzDQo+IA0KPiAtIEphbm9zOiB3b3JrIGdvaW5nIG9uIGluIDgwMi4xQ0Eg KG5vdGUgdGFrZXI6IG5hbWUgdG8gYmUgY29uZmlybWVkKSB0bw0KPiBjYXJyeSBDb21tb24gUHVi bGljIFJhZGlvIEludGVyZmFjZSAoQ1BSSeKEoikNCj4gDQo+IEphbWVzIGRpc2N1c3NlcyBwYWNr ZXQgbG9zcyAvIEJFUiBpbXBhY3Qgb24gQ1BSSQ0KPiANCj4gLSBKYW5vczogYWdhaW4gbG9vayBh dCA4MDIuMUNBDQo+IA0KPiAtIEphbWVzOiB5ZXMsIGF3YXJlIG9mIHRoaXMgd29yaw0KPiANCj4g LSBMb3U6IHdoYXQncyBuZXh0DQo+IA0KPiAtIEphbWVzOiBuZXcgdmVyc2lvbi4NCj4gDQo+IC0g TG91OiBwbGVhc2UgbG9vayBhdCB1c2UgY2FzZXMgZG9jdW1lbnQNCj4gDQo+IC0gTG91IGNsb3Nl cyB0aGUgbWVldGluZyAoMiBtaW51dGVzIGVhcmx5ISEhKQ0KPiANCj4gDQo+IA0KPiANCj4gDQo+ ID4gMTI6MzAgICAgICBBZGpvdXJuDQo+IA0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRldG5ldCBtYWlsaW5nIGxpc3QNCj4gZGV0 bmV0QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZGV0 bmV0DQo= From nobody Thu Apr 7 08:03:11 2016 Return-Path: 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 CB07212D58D for ; Thu, 7 Apr 2016 08:03:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=broadcom.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 UfDkZlj3npAC for ; Thu, 7 Apr 2016 08:03:08 -0700 (PDT) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 E1D7212D870 for ; Thu, 7 Apr 2016 07:51:04 -0700 (PDT) Received: by mail-pf0-x235.google.com with SMTP id c20so57257501pfc.1 for ; Thu, 07 Apr 2016 07:51:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=reply-to:subject:references:to:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IvR9lC3bWk/OycRBo3qWg6p2RwxoNAFbZ8XvQm1aw5w=; b=YASZLKL4L2tRXxbQQVnfzhbYVayAx3bqM7oBoBaUrhyDPkqIVQdOi+apY5ZIDGBjf5 yIyerqMjNHpq7OadwuuTfpECO1cGz//91VKhoXxmtSLmtyouxDnUnZfAxk9DlHxA6fpy CW1C4Qrfug/JD0PY2iaS+Sy96Qc1XbZaIL04o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:reply-to:subject:references:to:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IvR9lC3bWk/OycRBo3qWg6p2RwxoNAFbZ8XvQm1aw5w=; b=U8bbbbXZ55o3DeDZ6AjSBwSFMYrCaOFh6GQST8JaUna+OhK9204ln85GKZfZeiO/yo olxU9JZU6pneQBWVfTLp4UQ/0TuHu3v6Vg5QcOqPj1T8JlkR0s5rcXt2nR9L6/sGEJU+ d54xog3lKnttyIc0ZSvSWir050ZdGbtY+sIgMIOLK/nMsVNZN4wR0pYTpnDZVAJ4xcFe 2BX8WmbYWYe1qOSS4eiv7gByIlOmtgkAq6rq9xHV2drSK0xewan+UfquJFgtjtHRe3iG ahz1zub9k5rQkNjBUnYPb8lh1ZSaJN8kHiZzICilgg1OjsNQ/ELlOfNkyzlvlDrfAH1o 7Z/g== X-Gm-Message-State: AD7BkJJR0GKl2U2u+aP5Trz1kTuBJpYTKtfnXWONUX72cJj0v3/eecH/ZUQgzJqJqNfI8xZV X-Received: by 10.98.14.68 with SMTP id w65mr5277493pfi.144.1460040663369; Thu, 07 Apr 2016 07:51:03 -0700 (PDT) Received: from [10.9.244.177] (5520-maca-inet1-outside.broadcom.com. [216.31.211.11]) by smtp.gmail.com with ESMTPSA id n19sm12830815pfi.53.2016.04.07.07.51.01 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Apr 2016 07:51:02 -0700 (PDT) References: <7804adb36b8d45b9b7025aa0e2d49a12@DLB-XCHPW03.dolby.net> To: "Grossman, Ethan A." , "detnet@ietf.org" From: Jouni Korhonen Message-ID: <570673D1.1050307@broadcom.com> Date: Thu, 7 Apr 2016 07:50:57 -0700 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <7804adb36b8d45b9b7025aa0e2d49a12@DLB-XCHPW03.dolby.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Detnet] DetNet use cases: Interconnecting networks X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: jouni.korhonen@broadcom.com List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:03:10 -0000 During the formationg of the WG we did talk about interconnecting islands and looking at the current WG charter: The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. We could say that interconnecting networks over some SP network (some form of VPN or even leased line) could fall under the 'closed group of administrative control'. Anyway, while the DT has not specifically spent energy on interconnecting networks, many of the technologies we have on plate could fit into the use case. So they are in that sense on the DT's radar but not as a specific topic to look at. - Jouni 4/6/2016, 12:51 PM, Grossman, Ethan A. kirjoitti: > Following up on Patrick W’s comment at the meeting: > “In utility there is a use case of connecting two (or more?) > substations. They may us an SP network for that connection. Even if we > do not support internet at large, we must support 2 (or more?) > interconnected networks.” > Is this on the design team’s radar? > Thanks, > Ethan. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Thu Apr 7 08:15:27 2016 Return-Path: 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 1B40A12D968 for ; Thu, 7 Apr 2016 08:15:25 -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 caioCF2Kpiwh for ; Thu, 7 Apr 2016 08:15:19 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5541112D167 for ; Thu, 7 Apr 2016 08:02:58 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37EwkhK008812; Thu, 7 Apr 2016 08:02:57 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225hr28nx1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Apr 2016 08:02:57 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 08:02:56 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 08:02:54 -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.1076.000; Thu, 7 Apr 2016 08:02:54 -0700 From: "Grossman, Ethan A." To: "jouni.korhonen@broadcom.com" , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet use cases: Interconnecting networks Thread-Index: AdGQPPYJbuKHdSDTSuC4ri9Ru9gouQA2prCAAA5azmA= Date: Thu, 7 Apr 2016 15:02:54 +0000 Message-ID: References: <7804adb36b8d45b9b7025aa0e2d49a12@DLB-XCHPW03.dolby.net> <570673D1.1050307@broadcom.com> In-Reply-To: <570673D1.1050307@broadcom.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_10:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: Re: [Detnet] DetNet use cases: Interconnecting networks X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 15:15:25 -0000 Thanks Jouni, >From your explanation I understand that Patrick's request is explicitly cov= ered in the WG charter, so it is in scope. Ethan. -----Original Message----- From: Jouni Korhonen [mailto:jouni.korhonen@broadcom.com]=20 Sent: Thursday, April 07, 2016 11:51 AM To: Grossman, Ethan A.; detnet@ietf.org Subject: Re: [Detnet] DetNet use cases: Interconnecting networks During the formationg of the WG we did talk about interconnecting islands a= nd looking at the current WG charter: The Working Group will initially focus on solutions for networks that are under a single administrative control or within a closed group of administrative control; these include not only campus-wide networks but also can include private WANs. We could say that interconnecting networks over some SP network (some form = of VPN or even leased line) could fall under the 'closed group of administr= ative control'. Anyway, while the DT has not specifically spent energy on i= nterconnecting networks, many of the technologies we have on plate could fi= t into the use case. So they are in that sense on the DT's radar but not as= a specific topic to look at. - Jouni 4/6/2016, 12:51 PM, Grossman, Ethan A. kirjoitti: > Following up on Patrick W's comment at the meeting: > "In utility there is a use case of connecting two (or more?)=20 > substations. They may us an SP network for that connection. Even if we=20 > do not support internet at large, we must support 2 (or more?)=20 > interconnected networks." > Is this on the design team's radar? > Thanks, > Ethan. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Thu Apr 7 12:37:26 2016 Return-Path: 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 BCFA112D149 for ; Thu, 7 Apr 2016 12:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 0lRIXg0PQWGE for ; Thu, 7 Apr 2016 12:37:24 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CAB12D093 for ; Thu, 7 Apr 2016 12:37:24 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37JZQ5s021643 for ; Thu, 7 Apr 2016 12:37:24 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy835k-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 12:37:24 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 12:37:22 -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.1076.9; Thu, 7 Apr 2016 12:37:21 -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.1076.000; Thu, 7 Apr 2016 12:37:21 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Unresolved Statements - Strategy Thread-Index: AdGRA7R1h3yMLfFMRCGcm3ALHwv1yw== Date: Thu, 7 Apr 2016 19:37:20 +0000 Message-ID: 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: multipart/alternative; boundary="_000_cce467aaf589427f878541eea698d11fDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Unresolved Statements - Strategy X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:37:26 -0000 --_000_cce467aaf589427f878541eea698d11fDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Folks, Here is my plan for continuing the discussion we started at the meeting abo= ut the various statements in the use case draft that I couldn't associate w= ith statements in the Problem Statement or Architecture drafts. I am going = to send one email per statement, with as much as I know about that statemen= t, that way we can discuss them independently of each other. Please respond= to any and all of them that you care to. Presumably the result for each st= atement will be that one or more of the drafts can be modified to say whate= ver it takes to clear up the point. Special case: The 6TiSCH ones will all = go together in a single email thread. Ethan. --_000_cce467aaf589427f878541eea698d11fDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi Folks,
Here is my plan for continuing the discussion we started at the meetin= g about the various statements in the use case draft that I couldn’t = associate with statements in the Problem Statement or Architecture drafts. = I am going to send one email per statement, with as much as I know about that statement, that way we can discuss them i= ndependently of each other. Please respond to any and all of them that you = care to. Presumably the result for each statement will be that one or more = of the drafts can be modified to say whatever it takes to clear up the point. Special case: The 6TiSCH ones = will all go together in a single email thread.
Ethan. 
 
 --_000_cce467aaf589427f878541eea698d11fDLBXCHPW03dolbynet_-- From nobody Thu Apr 7 12:56:47 2016 Return-Path: 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 4106612D17B for ; Thu, 7 Apr 2016 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Tk0vhV3PTswg for ; Thu, 7 Apr 2016 12:56:43 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9B2A12D0BA for ; Thu, 7 Apr 2016 12:56:43 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37Js0hE009078 for ; Thu, 7 Apr 2016 12:56:39 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0b-000fd501.pphosted.com with ESMTP id 225vjy870u-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 12:56:39 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 12:56:38 -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.1076.9; Thu, 7 Apr 2016 12:56:36 -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.1076.000; Thu, 7 Apr 2016 12:56:36 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: The Open Internet Thread-Index: AdGRBRtXW+BXuuIgRlaGh3XqvKagVQ== Date: Thu, 7 Apr 2016 19:56:36 +0000 Message-ID: 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: multipart/alternative; boundary="_000_c6c4f56723e643089df9ae5b332f3483DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 19:56:45 -0000 --_000_c6c4f56723e643089df9ae5b332f3483DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: The Open Internet - (not in scope) - But does future planning for this affe= ct DetNet? Discussion: Ethan: AFAICT the answer is basically "no". The question of "privacy" (in t= he RFC 7258 sense) came up, but I am still waiting to hear if that is an is= sue on private networks. If anyone can think of anything else that bears on= this please speak up. --_000_c6c4f56723e643089df9ae5b332f3483DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
The Open Internet – (not in scope) - But does future planning fo= r this affect DetNet?
Discussion:
Ethan: AFAICT the answer is basically “no”. The question o= f “privacy” (in the RFC 7258 sense) came up, but I am still wai= ting to hear if that is an issue on private networks. If anyone can think o= f anything else that bears on this please speak up.
 
 
 
 --_000_c6c4f56723e643089df9ae5b332f3483DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:06:46 2016 Return-Path: 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 B60A212D59F for ; Thu, 7 Apr 2016 13:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gMMl0FfcArvp for ; Thu, 7 Apr 2016 13:06:43 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9324212D60A for ; Thu, 7 Apr 2016 13:06:43 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37K6doj009088 for ; Thu, 7 Apr 2016 13:06:43 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy840k-4 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:06:43 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:04:58 -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.1076.9; Thu, 7 Apr 2016 13:04:56 -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.1076.000; Thu, 7 Apr 2016 13:04:56 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Providing Synchronized Time Thread-Index: AdGRCKJDoI4EO4AYS9GGhMr+RHKjNg== Date: Thu, 7 Apr 2016 20:04:56 +0000 Message-ID: <8583e31212574c81ae93fbae34369b3d@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_8583e31212574c81ae93fbae34369b3dDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: Providing Synchronized Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:06:44 -0000 --_000_8583e31212574c81ae93fbae34369b3dDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Providing Synchronized Time (not in scope) Discussion: A point came up about whether DetNet streams could serve as a way to delive= r timekeeping packets in a more timely way in order to provide more accurat= e time. We concluded that this was a possible use case for DetNet, and invi= te contributions of use case text on the topic. However since DetNet itself= depends on time sync to function, making timekeeping depend on DetNet is a= circular dependency so doesn't seem feasible. --_000_8583e31212574c81ae93fbae34369b3dDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Providing Synchronized Time (not in scope)
Discussion:
A point came up about whether DetNet streams could serve as a way to d= eliver timekeeping packets in a more timely way in order to provide more ac= curate time. We concluded that this was a possible use case for DetNet, and= invite contributions of use case text on the topic. However since DetNet itself depends on time sync to func= tion, making timekeeping depend on DetNet is a circular dependency so doesn= ’t seem feasible.
 
 
 --_000_8583e31212574c81ae93fbae34369b3dDLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:11:55 2016 Return-Path: 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 931BF12D609 for ; Thu, 7 Apr 2016 13:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 xPxwApk_tWV4 for ; Thu, 7 Apr 2016 13:11:52 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 780B812D539 for ; Thu, 7 Apr 2016 13:11:52 -0700 (PDT) Received: by mail-ob0-x230.google.com with SMTP id tz8so54646660obc.0 for ; Thu, 07 Apr 2016 13:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=HKvB4HlxiSuoO56vEnwaMaPdOCn8g4s3+mfq97RA9VU=; b=SctyC2FH1tprKlDT2VxjJeMFl0NDQUICkOc+3tnM85x2n0qI8/jWOzs8r6Fh2QWWa3 XKFOJNesjh8iQIWGQqqyJUos0ul1bN1kbquoD9GjV7ksNKHJdO04vWbnrTTO5cA3d5v4 LNNFsfnJ5EbqoZ+TuX0zXqxRHF/OKLHss94/DginviN+bGG0SMT7zccNXyp8VhTbwCcF fXOkINfTeX2EsfXasg5pGV6+fwaf3jKiUFoWQYoqagVbYQOR9LBU9YxilKxJMc4O2PN3 ebBNLexjSW7laqmdkKndcGp2Rzdt+V8uW2lGauyGKxULYlYpRUFjy4QYRasvZMz9K/7R VWkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=HKvB4HlxiSuoO56vEnwaMaPdOCn8g4s3+mfq97RA9VU=; b=ci5d2HITORDaxQujH6zTzPUTYPyWW1aDziT6MAvL7jRbSLTLWAnT4QdIpB/THqfOZp 7lrbga4wAsK7Utitq2qLdJZSbD50QFay0OubLcGjG6e5GcPEXHTUaXsra3geiTe8G/Ul BjoQEKS1Su7qwfN7XeJDIZe1zBMDU7yXxbO0VArMZp6SN7QOxkyqyIq0eNRsbTpD6Kil x7BcqlxAogF5mrIgOHqpS85PxwTGvydhQ6GI7le6cvWAYIv4YSFAiTkSLAdnIZl2B95m 1x9GlVQKnFRJyiks83dUZ1eT3LofdaW73OrXgQz+XGwswTRlPbsZ8CmYy0wYfwt/uMgM 3A0w== X-Gm-Message-State: AD7BkJJKs8/6k/gIg0xf1V65zo+vdf3u6qjFSwp8V3DrlkHf50L5Ns7hj8tjUooZ9+1zZI2HgtCjnEAojfpOMA== MIME-Version: 1.0 X-Received: by 10.60.145.236 with SMTP id sx12mr2590311oeb.45.1460059911883; Thu, 07 Apr 2016 13:11:51 -0700 (PDT) Received: by 10.76.113.233 with HTTP; Thu, 7 Apr 2016 13:11:51 -0700 (PDT) In-Reply-To: References: Date: Thu, 7 Apr 2016 16:11:51 -0400 Message-ID: From: Subir Das To: "Grossman, Ethan A." Content-Type: multipart/alternative; boundary=047d7b5d54a466154e052feab00d Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:11:55 -0000 --047d7b5d54a466154e052feab00d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Ethan, Thanks for starting the discussion. When you say no, does this mean the access to DetNet services will be restricted and the deployment of DetNet services need to follow a specific network model? -Subir On Thu, Apr 7, 2016 at 3:56 PM, Grossman, Ethan A. wrote= : > Statement: > The Open Internet =E2=80=93 (not in scope) - But does future planning for= this > affect DetNet? > Discussion: > Ethan: AFAICT the answer is basically =E2=80=9Cno=E2=80=9D. The question = of =E2=80=9Cprivacy=E2=80=9D (in > the RFC 7258 sense) came up, but I am still waiting to hear if that is an > issue on private networks. If anyone can think of anything else that bear= s > on this please speak up. > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --047d7b5d54a466154e052feab00d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ethan,
Thanks for starting the discussi= on. When you say no, does this mean the access to DetNet services will be r= estricted and the deployment of DetNet services need to follow a specific= =C2=A0 network model?

-Subir



=


On Thu, Apr 7, 2016 at 3:56 PM, Grossman, Ethan A. <ea= gros@dolby.com> wrote:
Statement:
The Open Internet =E2=80=93 (not in scope) - But does future planning = for this affect DetNet?
Discussion:
Ethan: AFAICT the answer is basically =E2=80=9Cno=E2=80=9D. The questi= on of =E2=80=9Cprivacy=E2=80=9D (in the RFC 7258 sense) came up, but I am s= till waiting to hear if that is an issue on private networks. If anyone can= think of anything else that bears on this please speak up.
=C2=A0
=C2=A0
=C2=A0

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


--047d7b5d54a466154e052feab00d-- From nobody Thu Apr 7 13:16:13 2016 Return-Path: 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 D606012D6AA for ; Thu, 7 Apr 2016 13:16:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cfb_9WXN167y for ; Thu, 7 Apr 2016 13:16:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F0CE12D668 for ; Thu, 7 Apr 2016 13:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7480; q=dns/txt; s=iport; t=1460060169; x=1461269769; h=from:to:subject:date:message-id:mime-version; bh=O7ERxWhpO/HC0cG1tJkTd0iloubbJgt7scYmAdA8Alg=; b=lNT/MEtdKzwU0NKreYPhQAn9e/iWuLoqjAgkmWziovwkVI68lmgcOGKP WyJK/RpA2mPu3e1jgFXOIFhWjZNI4F0FmmdTCXdPfRCENMW8QNX+SH6rJ bWom94JFYHA7AsmlrfELPDRUMAdilpflVruj9cCtLBlfJBDY+qgwgbOe+ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbAgDNvgZX/4QNJK1dDoJdTFN9Bro9A?= =?us-ascii?q?Q2BcyGFbB6BKTgUAQEBAQEBAWUnhEEBAgICI2gBCBEBAgECKAMCBDAUAwYKBAE?= =?us-ascii?q?SiCcOr3eRfgEBAQEBBQEBAQEBAQEBFASGIYRLhF8NglOCVgWYBAGOC48OjyMBH?= =?us-ascii?q?gEBQoMsO2wBiDp+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,449,1454976000"; d="scan'208,217"; a="89423341" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 07 Apr 2016 20:16:08 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u37KG8LA011585 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 20:16:08 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 15:16:07 -0500 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 15:16:07 -0500 From: "Norman Finn (nfinn)" To: Tim Chown , "detnet@ietf.org" Thread-Topic: [Detnet] detnet architecture, and privacy considerations Thread-Index: AQHRkQpRB8AwCx57okGw6NIOQtTMPA== Date: Thu, 7 Apr 2016 20:16:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.116.94] Content-Type: multipart/alternative; boundary="_000_D32C46334BC36nfinnciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] detnet architecture, and privacy considerations X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:16:12 -0000 --_000_D32C46334BC36nfinnciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVmaW5pdGVseSB3aWxsIGFkZHJlc3MgdGhpcyBjb21tZW50IHdoZW4gcHJlcGFyaW5nIGFub3Ro ZXIgdmVyc2lvbiBmb3IgcG9zc2libGUgYWRvcHRpb24uDQoNClRoYW5rcyEhDQoNCuKAlCBOb3Jt DQoNCkZyb206IGRldG5ldCA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldC1i b3VuY2VzQGlldGYub3JnPj4gb24gYmVoYWxmIG9mIFRpbSBDaG93biA8VGltLkNob3duQGppc2Mu YWMudWs8bWFpbHRvOlRpbS5DaG93bkBqaXNjLmFjLnVrPj4NCkRhdGU6IFR1ZXNkYXksIEFwcmls IDUsIDIwMTYgYXQgMTM6NDMgUE0NClRvOiAiZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRA aWV0Zi5vcmc+IiA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogW0RldG5ldF0gZGV0bmV0IGFyY2hpdGVjdHVyZSwgYW5kIHByaXZhY3kgY29uc2lkZXJh dGlvbnMNCg0KSGksDQoNClRoZSBxdWVzdGlvbiBJIGFza2VkIGF0IHRoZSBtaWMgdG9kYXkgd2Fz IGRyaXZlbiBieSBzZWVpbmcgYW4gYXJjaGl0ZWN0dXJlIHRleHQgKGRyYWZ0LWZpbm4tZGV0bmV0 LWFyY2hpdGVjdHVyZS0wNCkgd2hlcmUgdGhlcmXigJlzIG5vIGV4cGxpY2l0IG1lbnRpb24gb2Yg cHJpdmFjeSBoYW5kbGluZywgYW5kIGJlaW5nIGF3YXJlIHRoYXQgc2luY2UgUkZDIDcyNTggd2Fz IHB1Ymxpc2hlZCB3ZSBzaG91bGQgYmUgdGhpbmtpbmcgYWJvdXQgYXBwcm9wcmlhdGUgcHJpdmFj eSBjb25zaWRlcmF0aW9ucyBpbiBzdWNoIGRvY3VtZW50cy4NCg0KU28sIGZvciBleGFtcGxlLCBv bmUg4oCYb3BlbiBpc3N1ZScgc2xpZGUgaW4gTm9ybWFu4oCZcyB0YWxrIGFza2VkIGFib3V0IGlk ZW50aWZ5aW5nIHN0cmVhbXMsIGFuZCBMMiBhZGRyZXNzZXMgb3IgdGhlIDUtdHVwbGUgd2VyZSBt ZW50aW9uZWQsIGJ1dCBpbiBhIHdvcmxkIHdoZXJlIEwyIGFkZHJlc3NlcyBhcmUgcmFuZG9taXNl ZCBvdmVyIHRpbWUsIGFuZCBlbmNyeXB0aW9uIGlzIG1vcmUgd2lkZXNwcmVhZCwgb3RoZXIgbWVj aGFuaXNtcyBtYXkgYmUgcmVxdWlyZWQsIG9uZXMgdGhhdCBvbmUgbWlnaHQgYXJndWUgc2hvdWxk IGJlIG9wYXF1ZSB0byB0aGUgbmV0d29yayBvcGVyYXRvci4NCg0KV2VhcmluZyBteSBkbnNzZCBX RyBjaGFpciBoYXQsIHdl4oCZdmUgZGlzY3Vzc2VkIHNpbWlsYXIgaXNzdWVzIHRoaXMgd2Vlaywg c3BlY2lmaWNhbGx5IGhvdyB5b3UgbWlnaHQgZG8gZGV2aWNlIG5hbWluZyBhbmQgc2VydmljZSBk aXNjb3Zlcnkgd2l0aCBwcml2YWN5LCB3aGlsZSB1c2luZyDigJhicm9hZGNhc3TigJkgcHJvdG9j b2xzIHN1Y2ggYXMgbUROUyBhbmQgRE5TLVNEIChzZWUgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJv Y2VlZGluZ3MvOTUvc2xpZGVzL3NsaWRlcy05NS1kbnNzZC0wLnBkZiwgaWYgaW50ZXJlc3RlZCku DQoNCldoYXRldmVyIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgYXJlIHB1dCBpbnRvIHRoZSBhcmNo aXRlY3R1cmUsIEkgdGhpbmsgd2Ugc2hvdWxkIGF0IGxlYXN0IGVuc3VyZSB3ZSBkaXNjdXNzIHRo ZW0sIG5vdGluZyB0aGF0IHdoaWxlIGRldG5ldCBpcyBzY29wZWQgYnkgY2hhcnRlciB0byBpbml0 aWFsbHkgb25seSBiZSBhcHBsaWNhYmxlIHdpdGhpbiBhIHNpbmdsZSBhZG1pbmlzdHJhdGl2ZSBk b21haW4sIHVzZSBvZiB0aGUgd29yZCDigJhpbml0aWFsbHnigJkgaW1wbGllcyBpdHMgc2NvcGUg bWF5L3dpbGwgZ3JvdyBsYXRlci4NCg0KVGltDQoNCg0KDQo= --_000_D32C46334BC36nfinnciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+RGVmaW5pdGVs eSB3aWxsIGFkZHJlc3MgdGhpcyBjb21tZW50IHdoZW4gcHJlcGFyaW5nIGFub3RoZXIgdmVyc2lv biBmb3IgcG9zc2libGUgYWRvcHRpb24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5U aGFua3MhITwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+4oCUIE5vcm08L2Rpdj4NCjxk aXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBz dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVm dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+ZGV0bmV0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGV0bmV0 LWJvdW5jZXNAaWV0Zi5vcmciPmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVo YWxmIG9mIFRpbSBDaG93biAmbHQ7PGEgaHJlZj0ibWFpbHRvOlRpbS5DaG93bkBqaXNjLmFjLnVr Ij5UaW0uQ2hvd25AamlzYy5hYy51azwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2Vp Z2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBBcHJpbCA1LCAyMDE2IGF0IDEzOjQzIFBN PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+JnF1b3Q7PGEg aHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZn dDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVjdDogPC9zcGFuPltE ZXRuZXRdIGRldG5ldCBhcmNoaXRlY3R1cmUsIGFuZCBwcml2YWN5IGNvbnNpZGVyYXRpb25zPGJy Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09L X0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNv bGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0id29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJr aXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkhpLA0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhlIHF1ZXN0aW9u IEkgYXNrZWQgYXQgdGhlIG1pYyB0b2RheSB3YXMgZHJpdmVuIGJ5IHNlZWluZyBhbiBhcmNoaXRl Y3R1cmUgdGV4dCAoZHJhZnQtZmlubi1kZXRuZXQtYXJjaGl0ZWN0dXJlLTA0KSB3aGVyZSB0aGVy ZeKAmXMgbm8gZXhwbGljaXQgbWVudGlvbiBvZiBwcml2YWN5IGhhbmRsaW5nLCBhbmQgYmVpbmcg YXdhcmUgdGhhdCBzaW5jZSBSRkMgNzI1OCB3YXMgcHVibGlzaGVkIHdlIHNob3VsZCBiZSB0aGlu a2luZw0KIGFib3V0IGFwcHJvcHJpYXRlIHByaXZhY3kgY29uc2lkZXJhdGlvbnMgaW4gc3VjaCBk b2N1bWVudHMuPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRp diBjbGFzcz0iIj5TbywgZm9yIGV4YW1wbGUsIG9uZSDigJhvcGVuIGlzc3VlJyBzbGlkZSBpbiBO b3JtYW7igJlzIHRhbGsgYXNrZWQgYWJvdXQgaWRlbnRpZnlpbmcgc3RyZWFtcywgYW5kIEwyIGFk ZHJlc3NlcyBvciB0aGUgNS10dXBsZSB3ZXJlIG1lbnRpb25lZCwgYnV0IGluIGEgd29ybGQgd2hl cmUgTDIgYWRkcmVzc2VzIGFyZSByYW5kb21pc2VkIG92ZXIgdGltZSwgYW5kIGVuY3J5cHRpb24g aXMgbW9yZSB3aWRlc3ByZWFkLCBvdGhlciBtZWNoYW5pc21zDQogbWF5IGJlIHJlcXVpcmVkLCBv bmVzIHRoYXQgb25lIG1pZ2h0IGFyZ3VlIHNob3VsZCBiZSBvcGFxdWUgdG8gdGhlIG5ldHdvcmsg b3BlcmF0b3IuJm5ic3A7PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj5XZWFyaW5nIG15IGRuc3NkIFdHIGNoYWlyIGhhdCwgd2XigJl2ZSBk aXNjdXNzZWQgc2ltaWxhciBpc3N1ZXMgdGhpcyB3ZWVrLCBzcGVjaWZpY2FsbHkgaG93IHlvdSBt aWdodCBkbyBkZXZpY2UgbmFtaW5nIGFuZCBzZXJ2aWNlIGRpc2NvdmVyeSB3aXRoIHByaXZhY3ks IHdoaWxlIHVzaW5nIOKAmGJyb2FkY2FzdOKAmSBwcm90b2NvbHMgc3VjaCBhcyBtRE5TIGFuZCBE TlMtU0QgKHNlZSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz Lzk1L3NsaWRlcy9zbGlkZXMtOTUtZG5zc2QtMC5wZGYiIGNsYXNzPSIiPmh0dHBzOi8vd3d3Lmll dGYub3JnL3Byb2NlZWRpbmdzLzk1L3NsaWRlcy9zbGlkZXMtOTUtZG5zc2QtMC5wZGY8L2E+LA0K IGlmIGludGVyZXN0ZWQpLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+V2hhdGV2ZXIgcHJpdmFjeSBjb25zaWRlcmF0aW9ucyBhcmUgcHV0 IGludG8gdGhlIGFyY2hpdGVjdHVyZSwgSSB0aGluayB3ZSBzaG91bGQgYXQgbGVhc3QgZW5zdXJl IHdlIGRpc2N1c3MgdGhlbSwgbm90aW5nIHRoYXQgd2hpbGUgZGV0bmV0IGlzIHNjb3BlZCBieSBj aGFydGVyIHRvIGluaXRpYWxseSBvbmx5IGJlIGFwcGxpY2FibGUgd2l0aGluIGEgc2luZ2xlIGFk bWluaXN0cmF0aXZlIGRvbWFpbiwgdXNlIG9mIHRoZSB3b3JkDQog4oCYaW5pdGlhbGx54oCZIGlt cGxpZXMgaXRzIHNjb3BlIG1heS93aWxsIGdyb3cgbGF0ZXIuPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPlRpbTwvZGl2Pg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50 ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D32C46334BC36nfinnciscocom_-- From nobody Thu Apr 7 13:19:24 2016 Return-Path: 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 5B17B12D0A8 for ; Thu, 7 Apr 2016 13:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.53 X-Spam-Level: X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 hjTJA6sTXfg6 for ; Thu, 7 Apr 2016 13:19:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE10112D11B for ; Thu, 7 Apr 2016 13:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16392; q=dns/txt; s=iport; t=1460060361; x=1461269961; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=MbJ2aaIHawGLDSrwDKZH1xB6VOXjK8/EipTprv5vVY0=; b=Oq0xjPZTfaCM6gUN5x3n0rM4jjLAdoyK3B94cyb9o7HIGPz0cZshLN4E 9OFq+jSXpuros+NDxIt7VEjR5egQ5dqp0C6AOd2Tw0ASR9TNxRsecpgvV Sc6bewlpJIr54km41bNOwNFmRQkxlzC9ivU5nToAlu7DSAZShebri+81f w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAgAUwAZX/5ldJa1dgmtMU30GhB62H?= =?us-ascii?q?wENgXMhhWwCHIEpOBQBAQEBAQEBZSeEQQEBAQQjClwCAQgRAQIBAigDAgICMBQ?= =?us-ascii?q?DBggCBAESH4gIDq94kX4BAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYhhEuEIzwNg?= =?us-ascii?q?lOCVgWTGYRrAYV2iBWBZ4RNgyiFMo8jAR4BAUKCBBkVgTVsiDt+AQEB?= X-IronPort-AV: E=Sophos; i="5.24,449,1454976000"; d="scan'208,217"; a="89088945" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Apr 2016 20:19:20 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u37KJJ9s023296 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Apr 2016 20:19:19 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 7 Apr 2016 15:19:19 -0500 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1104.009; Thu, 7 Apr 2016 15:19:19 -0500 From: "Norman Finn (nfinn)" To: "Patrick Wetterwald (pwetterw)" , "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Cases - Starting the "what is in scope for DetNet" discussion Thread-Index: AQHRi5804GCMKAN+LkiiGro+R86znJ95XMGAgAXDCoA= Date: Thu, 7 Apr 2016 20:19:19 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.116.94] Content-Type: multipart/alternative; boundary="_000_D32C46EA4BC3Fnfinnciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Cases - Starting the "what is in scope for DetNet" discussion X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:19:23 -0000 --_000_D32C46EA4BC3Fnfinnciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VyZS4gIFRoYXQgYWxzbyByZWxhdGVzIHRvIHRoZSDigJxvbmUgYWRtaW5pc3RyYXRpdmUgZG9t YWluIHNwbGl0IGludG8gaXNsYW5kcyBieSBhIFdBTiBzZXJ2aWNl4oCdIGNhc2UgaW4gYW5vdGhl ciB0aHJlYWQuDQoNCuKAlCBOb3JtDQoNCkZyb206ICJQYXRyaWNrIFdldHRlcndhbGQgKHB3ZXR0 ZXJ3KSIgPHB3ZXR0ZXJ3QGNpc2NvLmNvbTxtYWlsdG86cHdldHRlcndAY2lzY28uY29tPj4NCkRh dGU6IFN1bmRheSwgQXByaWwgMywgMjAxNiBhdCAyMjoxOSBQTQ0KVG86IE5vcm1hbiBGaW5uIDxu ZmlubkBjaXNjby5jb208bWFpbHRvOm5maW5uQGNpc2NvLmNvbT4+LCAiR3Jvc3NtYW4sIEV0aGFu IEEuIiA8ZWFncm9zQGRvbGJ5LmNvbTxtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbT4+LCAiZGV0bmV0 QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+IiA8ZGV0bmV0QGlldGYub3JnPG1haWx0 bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtEZXRuZXRdIERldE5ldCBVc2UgQ2Fz ZXMgLSBTdGFydGluZyB0aGUgIndoYXQgaXMgaW4gc2NvcGUgZm9yIERldE5ldCIgZGlzY3Vzc2lv bg0KDQpFdGhhbiwgTm9ybSwNCg0KQWdyZWUgZm9yIHRoZSBub24gc3VwcG9ydCBvZiB0aGUgQmln LUkgSW50ZXJuZXQgd2l0aCB0aGUgZm9sbG93aW5nIHByZWNpc2lvbjogVXRpbGl0aWVzIG1heSBh c2sgYSBTUCB0byBwcm92aWRlIHRoZW0gd2l0aCBhIOKAnGRldGVybWluaXN0aWPigJ0gbGluayAo bGlrZSBhIGxlYXNlZCBsaW5lKSB3aXRoIGEgZ3VhcmFudGVlIG9mIG1heCBkZWxheSwgIEppdHRl ciBhbmQgcGFja2V0IGxvc3MuIEJ1dCBJIGd1ZXNzIHRoaXMgdXNlIGNhc2UgaXMgaW5jbHVkZWQg aW4g4oCcZW50ZXJwcmlzZeKAnSByaWdodCA/DQoNClRoYW5rcywNCg0KUGF0cmljaw0KDQpGcm9t OiBkZXRuZXQgPGRldG5ldC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpkZXRuZXQtYm91bmNlc0Bp ZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiTm9ybWFuIEZpbm4gKG5maW5uKSIgPG5maW5uQGNpc2Nv LmNvbTxtYWlsdG86bmZpbm5AY2lzY28uY29tPj4NCkRhdGU6IFRodXJzZGF5IDMxIE1hcmNoIDIw MTYgYXQgMTk6NDYNClRvOiAiR3Jvc3NtYW4sIEV0aGFuIEEuIiA8ZWFncm9zQGRvbGJ5LmNvbTxt YWlsdG86ZWFncm9zQGRvbGJ5LmNvbT4+LCAiZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRA aWV0Zi5vcmc+IiA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtEZXRuZXRdIERldE5ldCBVc2UgQ2FzZXMgLSBTdGFydGluZyB0aGUgIndoYXQg aXMgaW4gc2NvcGUgZm9yIERldE5ldCIgZGlzY3Vzc2lvbg0KDQpFdGhhbiwNCg0KTWFraW5nIERl dE5ldCB3b3JrIG92ZXIgdGhlIEJpZy1JIEludGVybmV0IGlzIG5vdCBvbmUgb2YgbXkgZ29hbHMs IGF0IGxlYXN0LiAgSSBvZnRlbiB1c2UgdGhlIHRlcm0g4oCcZW50ZXJwcmlzZeKAnSBmb3IgdGhl IHNjb3BlIGluIHdoaWNoIEnigJltIGludGVyZXN0ZWQuDQoNClRpbWVrZWVwaW5nIGlzIGFuIGVz c2VudGlhbCBwYXJ0IG9mIG1hbnksIHByb2JhYmx5IG1vc3QsIG9mIHRoZSBhcHBsaWNhdGlvbnMg dGhhdCBhbHNvIGZpbmQgRGV0TmV0IHVzZWZ1bC4gIFRoYXQgaGF2aW5nIGJlZW4gc2FpZCwgc28g aXMgcHJvdGVjdGlvbiBhZ2FpbnN0IEVNSSBhbmQgZWxlY3RyaWNhbCBwb3dlciBzYXZpbmcuIExl dOKAmXMgY29uY2VudHJhdGUgRGV0TmV0IG9uIHJlbGlhYmxlLCBvbi10aW1lIGRlbGl2ZXJ5IG9m IHBhY2tldHMuICBJ4oCZbSBub3QgZXZlbiBzdXJlIHRoYXQg4oCcYSB3YXkgdG8gc3BlY2lmeSB0 aGUgcmVxdWlyZWQgYWNjdXJhY3nigJ0gbmVlZCBiZSBpbiBzY29wZS4NCg0K4oCUIE5vcm0NCg0K RnJvbTogZGV0bmV0IDxkZXRuZXQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZGV0bmV0LWJvdW5j ZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgIkdyb3NzbWFuLCBFdGhhbiBBLiIgPGVhZ3Jvc0Bk b2xieS5jb208bWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2gg MjksIDIwMTYgYXQgMTI6MTMgUE0NClRvOiAiZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRA aWV0Zi5vcmc+IiA8ZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogW0RldG5ldF0gRGV0TmV0IFVzZSBDYXNlcyAtIFN0YXJ0aW5nIHRoZSAid2hhdCBpcyBp biBzY29wZSBmb3IgRGV0TmV0IiBkaXNjdXNzaW9uDQoNCkhpIEZvbGtzLA0KDQpJIGNsYWltIHRo YXQgd2UgaGF2ZSBicm91Z2h0IHRoZSBEZXROZXQgVXNlIENhc2VzIGRyYWZ0IHVwIHRvIGEgc3Rh dGUgd2hlcmUgSSBjYW4gc2F5IHdpdGggYSBzdHJhaWdodCBmYWNlIOKAnHBsZWFzZSByZWFkIHRo aXMgZG9jdW1lbnQsIGl0IHdvbuKAmXQgaHVydCB5b3XigJ0uIFNvIGlmIHlvdSBoYXZlbuKAmXQg YWxyZWFkeSBkb25lIHNvLCBwbGVhc2UgbG9vayBpdCBvdmVyLg0KDQpodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTA5DQoNCk1vdmluZyBvbiB0 byB0aGUgbmV4dCBzdGVwLCB3ZSBuZWVkIHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIG9uIHdoaWNo IGFzcGVjdHMgb2YgdGhlIHVzZSBjYXNlcyB3aWxsIGJlIHdpdGhpbiBzY29wZSBvZiB0aGUgRGV0 TmV0IHdvcmsuIE9yLCBwZXJoYXBzIGl0IGlzIGVhc2llciB0byBlbnVtZXJhdGUgd2hpY2ggb25l cyBhcmUgbm90IGluIHNjb3BlLCBhdCBsZWFzdCBmb3IgYSBzdGFydC4NCg0KVGhlIG1vc3Qgb2J2 aW91cyBmaXJzdCBpdGVtIHRvIGRlY2lkZSBvbiBpcyByZXF1ZXN0cyB0byBoYXZlIERldE5ldCB3 b3JrIG9uIHRoZSBvcGVuIEludGVybmV0IOKAkyBJIHRoaW5rIHdl4oCZcmUgcHJldHR5IGNsZWFy IHRoYXQgdGhhdCBpcyDigJxub3QgaW4gc2NvcGXigJ0gYmVjYXVzZSBvdXIgYXJjaGl0ZWN0dXJl IGRlcGVuZHMgb24gdGhlcmUgYmVpbmcg4oCcY2VudHJhbGl6ZWQgY29udHJvbOKAnSAod2hpY2gg bWF5IGJlIGRpc3RyaWJ1dGVkIGFtb25nIG11bHRpcGxlIG5ldHdvcmsgZW50aXRpZXMsIGJ1dCB3 aGljaCB0b2dldGhlciBjb25zdGl0dXRlIGEgc2luZ2xlIHBvaW50IG9mIGNvbnRyb2wpLiBJIGhh dmUgYWxzbyBoZWFyZCB0aGlzIHBocmFzZWQgYXMg4oCcY29ycG9yYXRlIG5ldHdvcmtz4oCdLiBE byB3ZSBhZ3JlZSBvbiB0aGlzPw0KDQpBbm90aGVyIGV4YW1wbGUgaXMgdGltZWtlZXBpbmcg4oCT IHRoaXMgd2lsbCBiZSBzcGVjaWZpZWQgYnkgb3RoZXIgZXhpc3RpbmcgbWVhbnMsIHJpZ2h0PyBU aGUgb25seSBleHBsaWNpdCBEZXROZXQgQXNrIGZvciB0aGlzIGlzIGluIE0yTSBhcyDigJxQcmVj aXNlIHRpbWUgc3luY2hyb25pemF0aW9uIGFjY3VyYWN5ICgxdXMp4oCdIGFuZCBJIHRoaW5rIHRo ZSBpbnRlbnQgKGFzIGluIG90aGVyIHVzZSBjYXNlcykgaXMgdGhhdCB0aGUgRGV0TmV0IEFzayBp cyBmb3IgYSB3YXkgdG8gc3BlY2lmeSB0aGUgcmVxdWlyZWQgYWNjdXJhY3ksIG5vdCBob3cgdG8g YWNoaWV2ZSB0aGF0IGFjY3VyYWN5Lg0KDQpBbnlvbmUgZWxzZSBzZWUgYW55dGhpbmcgdGhhdCBt aWdodCBub3QgYmUgaW4gc2NvcGU/IEkgcGxhbiB0byBhc2sgdGhpcyBxdWVzdGlvbiBpbiB0aGUg VXNlIENhc2VzIHBhcnQgb2YgdGhlIElFVEYgc2Vzc2lvbiwgc28gaWYgeW91IGhhdmUgYW55IHRo b3VnaHRzIHBsZWFzZSBzZW5kIHRoZW0gdG8gdGhlIGxpc3QgKG9yIGlmIHRoYXQgZG9lc27igJl0 IGhhcHBlbiwgYnJpbmcgdGhlbSB0byB0aGUgbGl2ZSBkaXNjdXNzaW9uKS4NCg0KVGhhbmtzLA0K WW91ciBmYWl0aGZ1bCBVc2UgQ2FzZXMgRWRpdG9yLA0KRXRoYW4uDQoNCg0KDQo= --_000_D32C46EA4BC3Fnfinnciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <6F230C2FA4F51F4A95EC8102C613FBE5@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+U3VyZS4gJm5i c3A7VGhhdCBhbHNvIHJlbGF0ZXMgdG8gdGhlIOKAnG9uZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4g c3BsaXQgaW50byBpc2xhbmRzIGJ5IGEgV0FOIHNlcnZpY2XigJ0gY2FzZSBpbiBhbm90aGVyIHRo cmVhZC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PuKAlCBOb3JtPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPHNwYW4gaWQ9Ik9MS19TUkNfQk9EWV9TRUNUSU9OIj4NCjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7IGZvbnQtc2l6ZToxMXB0OyB0ZXh0LWFsaWduOmxlZnQ7 IGNvbG9yOmJsYWNrOyBCT1JERVItQk9UVE9NOiBtZWRpdW0gbm9uZTsgQk9SREVSLUxFRlQ6IG1l ZGl1bSBub25lOyBQQURESU5HLUJPVFRPTTogMGluOyBQQURESU5HLUxFRlQ6IDBpbjsgUEFERElO Ry1SSUdIVDogMGluOyBCT1JERVItVE9QOiAjYjVjNGRmIDFwdCBzb2xpZDsgQk9SREVSLVJJR0hU OiBtZWRpdW0gbm9uZTsgUEFERElORy1UT1A6IDNwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWln aHQ6Ym9sZCI+RnJvbTogPC9zcGFuPiZxdW90O1BhdHJpY2sgV2V0dGVyd2FsZCAocHdldHRlcncp JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cHdldHRlcndAY2lzY28uY29tIj5wd2V0dGVyd0Bj aXNjby5jb208L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5EYXRl OiA8L3NwYW4+U3VuZGF5LCBBcHJpbCAzLCAyMDE2IGF0IDIyOjE5IFBNPGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOiA8L3NwYW4+Tm9ybWFuIEZpbm4gJmx0OzxhIGhyZWY9 Im1haWx0bzpuZmlubkBjaXNjby5jb20iPm5maW5uQGNpc2NvLmNvbTwvYT4mZ3Q7LCAmcXVvdDtH cm9zc21hbiwgRXRoYW4gQS4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplYWdyb3NAZG9sYnku Y29tIj5lYWdyb3NAZG9sYnkuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpkZXRu ZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0 bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RldG5ldF0gRGV0TmV0 IFVzZSBDYXNlcyAtIFN0YXJ0aW5nIHRoZSAmcXVvdDt3aGF0IGlzIGluIHNjb3BlIGZvciBEZXRO ZXQmcXVvdDsgZGlzY3Vzc2lvbjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1u YnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyBj b2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyI+DQo8ZGl2PkV0aGFuLCBOb3JtLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rp dj4NCjxkaXY+QWdyZWUgZm9yIHRoZSBub24gc3VwcG9ydCBvZiB0aGUgQmlnLUkgSW50ZXJuZXQg d2l0aCB0aGUgZm9sbG93aW5nIHByZWNpc2lvbjogVXRpbGl0aWVzIG1heSBhc2sgYSBTUCB0byBw cm92aWRlIHRoZW0gd2l0aCBhIOKAnGRldGVybWluaXN0aWPigJ0gbGluayAobGlrZSBhIGxlYXNl ZCBsaW5lKSB3aXRoIGEgZ3VhcmFudGVlIG9mIG1heCBkZWxheSwgJm5ic3A7Sml0dGVyIGFuZCBw YWNrZXQgbG9zcy4gQnV0IEkgZ3Vlc3MgdGhpcyB1c2UgY2FzZSBpcyBpbmNsdWRlZA0KIGluIOKA nGVudGVycHJpc2XigJ0gcmlnaHQgPzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhh bmtzLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UGF0cmljazwvZGl2Pg0KPGRpdj48 YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxl PSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBj b2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRp dW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkct UklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDog bWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPkZyb206IDwvc3Bhbj5kZXRuZXQgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91 bmNlc0BpZXRmLm9yZyI+ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYg b2YgJnF1b3Q7Tm9ybWFuIEZpbm4gKG5maW5uKSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5m aW5uQGNpc2NvLmNvbSI+bmZpbm5AY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i Zm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPlRodXJzZGF5IDMxIE1hcmNoIDIwMTYgYXQg MTk6NDY8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVv dDtHcm9zc21hbiwgRXRoYW4gQS4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzplYWdyb3NAZG9s YnkuY29tIj5lYWdyb3NAZG9sYnkuY29tPC9hPiZndDssICZxdW90OzxhIGhyZWY9Im1haWx0bzpk ZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1h aWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5SZTogW0RldG5ldF0gRGV0 TmV0IFVzZSBDYXNlcyAtIFN0YXJ0aW5nIHRoZSAmcXVvdDt3aGF0IGlzIGluIHNjb3BlIGZvciBE ZXROZXQmcXVvdDsgZGlzY3Vzc2lvbjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0i Qk9SREVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAw IDAgNTsiPg0KPGRpdj4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtp dC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNl OyBjb2xvcjogcmdiKDAsIDAsIDApOyBmb250LXNpemU6IDE0cHg7IGZvbnQtZmFtaWx5OiBDb25z b2xhcywgc2Fucy1zZXJpZjsiPg0KPGRpdj5FdGhhbiw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2Pk1ha2luZyBEZXROZXQgd29yayBvdmVyIHRoZSBCaWctSSBJbnRlcm5ldCBpcyBub3Qg b25lIG9mIG15IGdvYWxzLCBhdCBsZWFzdC4gJm5ic3A7SSBvZnRlbiB1c2UgdGhlIHRlcm0g4oCc ZW50ZXJwcmlzZeKAnSBmb3IgdGhlIHNjb3BlIGluIHdoaWNoIEnigJltIGludGVyZXN0ZWQuPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaW1la2VlcGluZyBpcyBhbiBlc3NlbnRpYWwg cGFydCBvZiBtYW55LCBwcm9iYWJseSBtb3N0LCBvZiB0aGUgYXBwbGljYXRpb25zIHRoYXQgYWxz byBmaW5kIERldE5ldCB1c2VmdWwuICZuYnNwO1RoYXQgaGF2aW5nIGJlZW4gc2FpZCwgc28gaXMg cHJvdGVjdGlvbiBhZ2FpbnN0IEVNSSBhbmQgZWxlY3RyaWNhbCBwb3dlciBzYXZpbmcuIExldOKA mXMgY29uY2VudHJhdGUgRGV0TmV0IG9uIHJlbGlhYmxlLCBvbi10aW1lIGRlbGl2ZXJ5IG9mIHBh Y2tldHMuDQogJm5ic3A7SeKAmW0gbm90IGV2ZW4gc3VyZSB0aGF0IOKAnGEgd2F5IHRvIHNwZWNp ZnkgdGhlIHJlcXVpcmVkIGFjY3VyYWN54oCdIG5lZWQgYmUgaW4gc2NvcGUuPC9kaXY+DQo8ZGl2 Pjxicj4NCjwvZGl2Pg0KPGRpdj7igJQgTm9ybTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxz cGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpD YWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9S REVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJPUkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElO Ry1CT1RUT006IDBpbjsgUEFERElORy1MRUZUOiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9S REVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBB RERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwv c3Bhbj5kZXRuZXQgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZyI+ ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7R3Jvc3Nt YW4sIEV0aGFuIEEuJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSI+ ZWFncm9zQGRvbGJ5LmNvbTwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv bGQiPkRhdGU6IDwvc3Bhbj5UdWVzZGF5LCBNYXJjaCAyOSwgMjAxNiBhdCAxMjoxMyBQTTxicj4N CjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9 Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0Ozxh IGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRldG5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bRGV0bmV0 XSBEZXROZXQgVXNlIENhc2VzIC0gU3RhcnRpbmcgdGhlICZxdW90O3doYXQgaXMgaW4gc2NvcGUg Zm9yIERldE5ldCZxdW90OyBkaXNjdXNzaW9uPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0 eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJ TjowIDAgMCA1OyI+DQo8ZGl2Pg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNy b3NvZnQgRXhjaGFuZ2UgU2VydmVyIj4NCjwhLS0gY29udmVydGVkIGZyb20gcnRmIC0tPjxzdHls ZT48IS0tIC5FbWFpbFF1b3RlIHsgbWFyZ2luLWxlZnQ6IDFwdDsgcGFkZGluZy1sZWZ0OiA0cHQ7 IGJvcmRlci1sZWZ0OiAjODAwMDAwIDJweCBzb2xpZDsgfSAtLT48L3N0eWxlPg0KPGRpdj48Zm9u dCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4N CjxkaXY+SGkgRm9sa3MsPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj5JIGNsYWltIHRo YXQgd2UgaGF2ZSBicm91Z2h0IHRoZSBEZXROZXQgVXNlIENhc2VzIGRyYWZ0IHVwIHRvIGEgc3Rh dGUgd2hlcmUgSSBjYW4gc2F5IHdpdGggYSBzdHJhaWdodCBmYWNlIOKAnHBsZWFzZSByZWFkIHRo aXMgZG9jdW1lbnQsIGl0IHdvbuKAmXQgaHVydCB5b3XigJ0uIFNvIGlmIHlvdSBoYXZlbuKAmXQg YWxyZWFkeSBkb25lIHNvLCBwbGVhc2UgbG9vayBpdCBvdmVyLg0KPC9kaXY+DQo8ZGl2PiZuYnNw OzwvZGl2Pg0KPGRpdj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTA5Ij48Zm9udCBjb2xvcj0iYmx1ZSI+PHU+aHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0wOTwvdT48L2Zv bnQ+PC9hPjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjxkaXY+TW92aW5nIG9uIHRvIHRoZSBu ZXh0IHN0ZXAsIHdlIG5lZWQgdG8gc3RhcnQgdGhlIGRpc2N1c3Npb24gb24gd2hpY2ggYXNwZWN0 cyBvZiB0aGUgdXNlIGNhc2VzIHdpbGwgYmUgd2l0aGluIHNjb3BlIG9mIHRoZSBEZXROZXQgd29y ay4gT3IsIHBlcmhhcHMgaXQgaXMgZWFzaWVyIHRvIGVudW1lcmF0ZSB3aGljaCBvbmVzIGFyZQ0K PHU+bm90PC91PiBpbiBzY29wZSwgYXQgbGVhc3QgZm9yIGEgc3RhcnQuIDwvZGl2Pg0KPGRpdj4m bmJzcDs8L2Rpdj4NCjxkaXY+VGhlIG1vc3Qgb2J2aW91cyBmaXJzdCBpdGVtIHRvIGRlY2lkZSBv biBpcyByZXF1ZXN0cyB0byBoYXZlIERldE5ldCB3b3JrIG9uIHRoZSBvcGVuIEludGVybmV0IOKA kyBJIHRoaW5rIHdl4oCZcmUgcHJldHR5IGNsZWFyIHRoYXQgdGhhdCBpcyDigJxub3QgaW4gc2Nv cGXigJ0gYmVjYXVzZSBvdXIgYXJjaGl0ZWN0dXJlIGRlcGVuZHMgb24gdGhlcmUgYmVpbmcg4oCc Y2VudHJhbGl6ZWQgY29udHJvbOKAnSAod2hpY2ggbWF5IGJlIGRpc3RyaWJ1dGVkIGFtb25nDQog bXVsdGlwbGUgbmV0d29yayBlbnRpdGllcywgYnV0IHdoaWNoIHRvZ2V0aGVyIGNvbnN0aXR1dGUg YSBzaW5nbGUgcG9pbnQgb2YgY29udHJvbCkuIEkgaGF2ZSBhbHNvIGhlYXJkIHRoaXMgcGhyYXNl ZCBhcyDigJxjb3Jwb3JhdGUgbmV0d29ya3PigJ0uIERvIHdlIGFncmVlIG9uIHRoaXM/DQo8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2PkFub3RoZXIgZXhhbXBsZSBpcyB0aW1la2VlcGlu ZyDigJMgdGhpcyB3aWxsIGJlIHNwZWNpZmllZCBieSBvdGhlciBleGlzdGluZyBtZWFucywgcmln aHQ/IFRoZSBvbmx5IGV4cGxpY2l0IERldE5ldCBBc2sgZm9yIHRoaXMgaXMgaW4gTTJNIGFzIOKA nFByZWNpc2UgdGltZSBzeW5jaHJvbml6YXRpb24gYWNjdXJhY3kgKDF1cynigJ0gYW5kIEkgdGhp bmsgdGhlIGludGVudCAoYXMgaW4gb3RoZXIgdXNlIGNhc2VzKSBpcyB0aGF0IHRoZSBEZXROZXQg QXNrDQogaXMgZm9yIGEgd2F5IHRvIHNwZWNpZnkgdGhlIHJlcXVpcmVkIGFjY3VyYWN5LCBub3Qg aG93IHRvIGFjaGlldmUgdGhhdCBhY2N1cmFjeS4NCjwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4N CjxkaXY+QW55b25lIGVsc2Ugc2VlIGFueXRoaW5nIHRoYXQgbWlnaHQgbm90IGJlIGluIHNjb3Bl PyBJIHBsYW4gdG8gYXNrIHRoaXMgcXVlc3Rpb24gaW4gdGhlIFVzZSBDYXNlcyBwYXJ0IG9mIHRo ZSBJRVRGIHNlc3Npb24sIHNvIGlmIHlvdSBoYXZlIGFueSB0aG91Z2h0cyBwbGVhc2Ugc2VuZCB0 aGVtIHRvIHRoZSBsaXN0IChvciBpZiB0aGF0IGRvZXNu4oCZdCBoYXBwZW4sIGJyaW5nIHRoZW0g dG8gdGhlIGxpdmUgZGlzY3Vzc2lvbikuDQo8L2Rpdj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8ZGl2 PlRoYW5rcywgPC9kaXY+DQo8ZGl2PllvdXIgZmFpdGhmdWwgVXNlIENhc2VzIEVkaXRvciw8L2Rp dj4NCjxkaXY+RXRoYW4uPC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250PjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L3NwYW4+PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj48 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D32C46EA4BC3Fnfinnciscocom_-- From nobody Thu Apr 7 13:28:12 2016 Return-Path: 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 B8CED12D6E4 for ; Thu, 7 Apr 2016 13:28:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 NszpNbGH2uPn for ; Thu, 7 Apr 2016 13:28:09 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 311A212D6E3 for ; Thu, 7 Apr 2016 13:28:09 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KO4JR019910 for ; Thu, 7 Apr 2016 13:28:09 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjv04t3-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:28:09 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:28:07 -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.1076.9; Thu, 7 Apr 2016 13:28:06 -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.1076.000; Thu, 7 Apr 2016 13:28:06 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Stream Start-up (or re-start) Time Thread-Index: AdGRCy7WSH98dpgkSOigK+oEh/VQ7A== Date: Thu, 7 Apr 2016 20:28:06 +0000 Message-ID: <60ea8b8dab5e44098f5174a9491507ad@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_60ea8b8dab5e44098f5174a9491507adDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:28:10 -0000 --_000_60ea8b8dab5e44098f5174a9491507adDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Stream Start-up (or re-start) Time Discussion: It was noted that systems that really need a timely replacement for a faile= d device would probably use other methods (e.g. redundancy) rather than dep= ending on a bounded stream start-up time. I don't have a sense of the answ= er to this one. --_000_60ea8b8dab5e44098f5174a9491507adDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Stream Start-up (or re-start) Time
Discussion:
It was noted that systems that really need a timely replacement for a = failed device would probably use other methods (e.g. redundancy) rather tha= n depending on a bounded stream start-up time.  I don’t have a s= ense of the answer to this one.  
 
 --_000_60ea8b8dab5e44098f5174a9491507adDLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:33:35 2016 Return-Path: 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 9530812D6BE for ; Thu, 7 Apr 2016 13:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 8lAKzd82UsPR for ; Thu, 7 Apr 2016 13:33:32 -0700 (PDT) Received: from mx0b-000fd501.pphosted.com (mx0b-000fd501.pphosted.com [67.231.152.235]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2DB1112D6E4 for ; Thu, 7 Apr 2016 13:33:31 -0700 (PDT) Received: from pps.filterd (m0000695.ppops.net [127.0.0.1]) by mx0b-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KSq6a026504 for ; Thu, 7 Apr 2016 13:33:26 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0b-000fd501.pphosted.com with ESMTP id 225vjy8976-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:33:26 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:33:25 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 13:33:24 -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.1076.000; Thu, 7 Apr 2016 13:33:24 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Cases Statmements: Link Authentication/Encryption Thread-Index: AdGRDBv0VuW29UCmQxSgR0D546MjQw== Date: Thu, 7 Apr 2016 20:33:23 +0000 Message-ID: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_5138314d76cd4e3cb444ab674552f8d4DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:33:33 -0000 --_000_5138314d76cd4e3cb444ab674552f8d4DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Link Authentication/Encryption Discussion: This statement came from a section of the Pro Audio use case (which was wri= tten by my co-author :-) and I haven't looked into the details of whether t= here is anything implied in that statement that would require us to do anyt= hing other than our current strategy of "don't break security". Perhaps Mr.= Gunther will enlighten us... :- ) --_000_5138314d76cd4e3cb444ab674552f8d4DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Link Authentication/Encryption
Discussion:
This statement came from a section of the Pro Audio use case (which wa= s written by my co-author :-) and I haven’t looked into the details o= f whether there is anything implied in that statement that would require us= to do anything other than our current strategy of “don’t break security”. Perhaps Mr. Gunther w= ill enlighten us… :- )
 
 
 --_000_5138314d76cd4e3cb444ab674552f8d4DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:37:43 2016 Return-Path: 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 1261512D6BD for ; Thu, 7 Apr 2016 13:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 ipmbM8ApzBI7 for ; Thu, 7 Apr 2016 13:37:35 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC7CF12D6ED for ; Thu, 7 Apr 2016 13:37:35 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KGIZd014673; Thu, 7 Apr 2016 13:20:02 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy84ea-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Apr 2016 13:20:02 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:20:00 -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.1076.9; Thu, 7 Apr 2016 13:19:59 -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.1076.000; Thu, 7 Apr 2016 13:19:59 -0700 From: "Grossman, Ethan A." To: Subir Das Thread-Topic: [Detnet] DetNet Use Case Statements: The Open Internet Thread-Index: AQHRkQm7SWY7rQ7CU0K2Ew5aOU+6mZ9+8heA Date: Thu, 7 Apr 2016 20:19:58 +0000 Message-ID: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net> References: In-Reply-To: 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: multipart/alternative; boundary="_000_487af79ba316492086d7ab597de02642DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:37:42 -0000 --_000_487af79ba316492086d7ab597de02642DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBiZWxpZXZlIHNvLCBpbiB0aGUgc2Vuc2UgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCDigJxl bnRlcnByaXNl4oCdIG5ldHdvcmtzLCBhbmQgcHJlc3VtYWJseSBhY2Nlc3MgaXMgcmVzdHJpY3Rl ZCBmb3IgdGhlIHdob2xlIG5ldHdvcmssIG5vdCBqdXN0IERldE5ldCBzZXJ2aWNlcyBvbiB0aGF0 IG5ldHdvcmsuIFdoZXRoZXIgYWNjZXNzIHRvIERldE5ldCBzZXJ2aWNlcyBhbW9uZyBhdXRob3Jp emVkIHVzZXJzIG9mIHRoYXQgbmV0d29yayBpcyByZXN0cmljdGVkIHNlZW1zIHRvIG1lIGEgbWF0 dGVyIG9mIGFkbWluaXN0cmF0aW9uIGZvciB0aGF0IG5ldHdvcmsuIEkgd291bGQgc2F5IGEgZGVw bG95bWVudCBvZiBEZXROZXQgc2VydmljZXMgbmVlZHMgdG8gZm9sbG93IHRoZSBuZXR3b3JrIG1v ZGVsIChpLmUuIGFyY2hpdGVjdHVyZSkgdGhhdCB3ZSAoRGV0TmV0KSBlc3RhYmxpc2gsIGFsdGhv dWdoIGl0IGlzIGNsZWFyIHRoYXQgdGhlcmUgd2lsbCBiZSB2YXJpb3VzIGRpZmZlcmluZyBpbXBs ZW1lbnRhdGlvbnMsIHNvIGluIHRoYXQgY2FzZSBpdCBpcyBub3Qgc28g4oCcc3BlY2lmaWPigJ0g aW4gdGVybXMgb2Yg4oCcd2hhdCBiaXRzIGFyZSBvbiB0aGUgd2lyZeKAnS4gUmlnaHQ/DQoNCkZy b206IFN1YmlyIERhcyBbbWFpbHRvOnN1YmlyZGFzMjFAZ21haWwuY29tXQ0KU2VudDogVGh1cnNk YXksIEFwcmlsIDA3LCAyMDE2IDU6MTIgUE0NClRvOiBHcm9zc21hbiwgRXRoYW4gQS4NCkNjOiBk ZXRuZXRAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbRGV0bmV0XSBEZXROZXQgVXNlIENhc2UgU3Rh dGVtZW50czogVGhlIE9wZW4gSW50ZXJuZXQNCg0KRXRoYW4sDQpUaGFua3MgZm9yIHN0YXJ0aW5n IHRoZSBkaXNjdXNzaW9uLiBXaGVuIHlvdSBzYXkgbm8sIGRvZXMgdGhpcyBtZWFuIHRoZSBhY2Nl c3MgdG8gRGV0TmV0IHNlcnZpY2VzIHdpbGwgYmUgcmVzdHJpY3RlZCBhbmQgdGhlIGRlcGxveW1l bnQgb2YgRGV0TmV0IHNlcnZpY2VzIG5lZWQgdG8gZm9sbG93IGEgc3BlY2lmaWMgIG5ldHdvcmsg bW9kZWw/DQotU3ViaXINCg0KDQoNCg0KT24gVGh1LCBBcHIgNywgMjAxNiBhdCAzOjU2IFBNLCBH cm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb208bWFpbHRvOmVhZ3Jvc0Bkb2xieS5j b20+PiB3cm90ZToNClN0YXRlbWVudDoNClRoZSBPcGVuIEludGVybmV0IOKAkyAobm90IGluIHNj b3BlKSAtIEJ1dCBkb2VzIGZ1dHVyZSBwbGFubmluZyBmb3IgdGhpcyBhZmZlY3QgRGV0TmV0Pw0K RGlzY3Vzc2lvbjoNCkV0aGFuOiBBRkFJQ1QgdGhlIGFuc3dlciBpcyBiYXNpY2FsbHkg4oCcbm/i gJ0uIFRoZSBxdWVzdGlvbiBvZiDigJxwcml2YWN54oCdIChpbiB0aGUgUkZDIDcyNTggc2Vuc2Up IGNhbWUgdXAsIGJ1dCBJIGFtIHN0aWxsIHdhaXRpbmcgdG8gaGVhciBpZiB0aGF0IGlzIGFuIGlz c3VlIG9uIHByaXZhdGUgbmV0d29ya3MuIElmIGFueW9uZSBjYW4gdGhpbmsgb2YgYW55dGhpbmcg ZWxzZSB0aGF0IGJlYXJzIG9uIHRoaXMgcGxlYXNlIHNwZWFrIHVwLg0KDQoNCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZGV0bmV0IG1haWxpbmcg bGlzdA0KZGV0bmV0QGlldGYub3JnPG1haWx0bzpkZXRuZXRAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RldG5ldDxodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp bmZvX2RldG5ldCZkPUN3TUZhUSZjPWxJOFpiNlR6TTNkMXRYNGlFdTdicGcmcj1aY0hDNndYX2dE d1BEY2ZNYUZOWmlRJm09ZWRMeGpKS0xqOUh5bnZwYXJjY2RpTGp3RUFILVYxeTQ5U2hIOEVUMENQ RSZzPVl6OS15cUtLNlY5c2hHRVc3R0Qyd2NQbXB2SkZRT1Zsa1hHUWw5TXQzTFEmZT0+DQoNCg== --_000_487af79ba316492086d7ab597de02642DLBXCHPW03dolbynet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIHNvLCBp biB0aGUgc2Vuc2UgdGhhdCB3ZSBhcmUgdGFsa2luZyBhYm91dCDigJxlbnRlcnByaXNl4oCdIG5l dHdvcmtzLCBhbmQgcHJlc3VtYWJseSBhY2Nlc3MgaXMgcmVzdHJpY3RlZCBmb3IgdGhlIHdob2xl IG5ldHdvcmssIG5vdCBqdXN0IERldE5ldCBzZXJ2aWNlcw0KIG9uIHRoYXQgbmV0d29yay4gV2hl dGhlciBhY2Nlc3MgdG8gRGV0TmV0IHNlcnZpY2VzIGFtb25nIGF1dGhvcml6ZWQgdXNlcnMgb2Yg dGhhdCBuZXR3b3JrIGlzIHJlc3RyaWN0ZWQgc2VlbXMgdG8gbWUgYSBtYXR0ZXIgb2YgYWRtaW5p c3RyYXRpb24gZm9yIHRoYXQgbmV0d29yay4gSSB3b3VsZCBzYXkgYSBkZXBsb3ltZW50IG9mIERl dE5ldCBzZXJ2aWNlcyBuZWVkcyB0byBmb2xsb3cgdGhlIG5ldHdvcmsgbW9kZWwgKGkuZS4gYXJj aGl0ZWN0dXJlKQ0KIHRoYXQgd2UgKERldE5ldCkgZXN0YWJsaXNoLCBhbHRob3VnaCBpdCBpcyBj bGVhciB0aGF0IHRoZXJlIHdpbGwgYmUgdmFyaW91cyBkaWZmZXJpbmcgaW1wbGVtZW50YXRpb25z LCBzbyBpbiB0aGF0IGNhc2UgaXQgaXMgbm90IHNvIOKAnHNwZWNpZmlj4oCdIGluIHRlcm1zIG9m IOKAnHdoYXQgYml0cyBhcmUgb24gdGhlIHdpcmXigJ0uIFJpZ2h0PyAmbmJzcDsmbmJzcDsmbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFN1YmlyIERhcyBb bWFpbHRvOnN1YmlyZGFzMjFAZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5 LCBBcHJpbCAwNywgMjAxNiA1OjEyIFBNPGJyPg0KPGI+VG86PC9iPiBHcm9zc21hbiwgRXRoYW4g QS48YnI+DQo8Yj5DYzo8L2I+IGRldG5ldEBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBS ZTogW0RldG5ldF0gRGV0TmV0IFVzZSBDYXNlIFN0YXRlbWVudHM6IFRoZSBPcGVuIEludGVybmV0 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5FdGhh biw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5UaGFua3MgZm9yIHN0YXJ0aW5nIHRoZSBkaXNjdXNzaW9uLiBX aGVuIHlvdSBzYXkgbm8sIGRvZXMgdGhpcyBtZWFuIHRoZSBhY2Nlc3MgdG8gRGV0TmV0IHNlcnZp Y2VzIHdpbGwgYmUgcmVzdHJpY3RlZCBhbmQgdGhlIGRlcGxveW1lbnQgb2YgRGV0TmV0IHNlcnZp Y2VzIG5lZWQgdG8gZm9sbG93IGEgc3BlY2lmaWMmbmJzcDsgbmV0d29yayBtb2RlbD8NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LVN1YmlyIDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUs IEFwciA3LCAyMDE2IGF0IDM6NTYgUE0sIEdyb3NzbWFuLCBFdGhhbiBBLiAmbHQ7PGEgaHJlZj0i bWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20iIHRhcmdldD0iX2JsYW5rIj5lYWdyb3NAZG9sYnkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+U3RhdGVtZW50Og0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgT3BlbiBJbnRlcm5ldCDigJMgKG5vdCBpbiBz Y29wZSkgLSBCdXQgZG9lcyBmdXR1cmUgcGxhbm5pbmcgZm9yIHRoaXMgYWZmZWN0IERldE5ldD88 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRpc2N1c3Npb246PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5FdGhhbjogQUZBSUNUIHRoZSBhbnN3ZXIgaXMgYmFzaWNhbGx5IOKA nG5v4oCdLiBUaGUgcXVlc3Rpb24gb2Yg4oCccHJpdmFjeeKAnSAoaW4gdGhlIFJGQyA3MjU4IHNl bnNlKSBjYW1lIHVwLCBidXQgSSBhbSBzdGlsbCB3YWl0aW5nIHRvIGhlYXIgaWYgdGhhdCBpcyBh biBpc3N1ZSBvbiBwcml2YXRlIG5ldHdvcmtzLg0KIElmIGFueW9uZSBjYW4gdGhpbmsgb2YgYW55 dGhpbmcgZWxzZSB0aGF0IGJlYXJzIG9uIHRoaXMgcGxlYXNlIHNwZWFrIHVwLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCmRldG5ldCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVm PSJtYWlsdG86ZGV0bmV0QGlldGYub3JnIj5kZXRuZXRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193 d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19kZXRuZXQmYW1wO2Q9Q3dNRmFRJmFtcDtjPWxJ OFpiNlR6TTNkMXRYNGlFdTdicGcmYW1wO3I9WmNIQzZ3WF9nRHdQRGNmTWFGTlppUSZhbXA7bT1l ZEx4akpLTGo5SHludnBhcmNjZGlMandFQUgtVjF5NDlTaEg4RVQwQ1BFJmFtcDtzPVl6OS15cUtL NlY5c2hHRVc3R0Qyd2NQbXB2SkZRT1Zsa1hHUWw5TXQzTFEmYW1wO2U9IiB0YXJnZXQ9Il9ibGFu ayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kZXRuZXQ8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_487af79ba316492086d7ab597de02642DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:45:00 2016 Return-Path: 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 6849412D10C for ; Thu, 7 Apr 2016 13:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9FC9mDSR0iM4 for ; Thu, 7 Apr 2016 13:44:57 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C791612D175 for ; Thu, 7 Apr 2016 13:44:57 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KivZv019709 for ; Thu, 7 Apr 2016 13:44:57 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjv05bm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:44:57 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:44:56 -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.1076.9; Thu, 7 Apr 2016 13:44:55 -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.1076.000; Thu, 7 Apr 2016 13:44:54 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Link Aggregation Thread-Index: AdGRDTva8UR3PCVcSiml22f+uRWeAw== Date: Thu, 7 Apr 2016 20:44:54 +0000 Message-ID: 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: multipart/alternative; boundary="_000_e7e71da91ac94d1798911f63f83d36bbDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:44:59 -0000 --_000_e7e71da91ac94d1798911f63f83d36bbDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Link Aggregation Discussion: I used the term "link aggregation" without understanding that it is a reser= ved word in this context, so I need to figure out what the correct term is.= The use case is that the user has a high bandwidth stream such as video bu= t there is no single network link between talker and listener which has ava= ilable bandwidth (for whatever reason) and the question is can DetNet "seam= lessly" split the stream and send parts of it across different paths to the= listener. It seemed like the feel of the room was that we shouldn't be inv= olved in doing this, however it was brought up that this function could be = implemented in a similar way as packet replication and deletion, except tha= t the packet sequence numbers are not duplicates so they would be accepted = and it might "just work". It sounds to me like it might be a useful thing t= o keep in there since it doesn't seem like it would be that hard, but perha= ps this is a DetNet "future feature" that we don't have to address now as l= ong as we don't do anything that would preclude developing it later. --_000_e7e71da91ac94d1798911f63f83d36bbDLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Link Aggregation
Discussion:
I used the term “link aggregation” without understanding t= hat it is a reserved word in this context, so I need to figure out what the= correct term is. The use case is that the user has a high bandwidth stream= such as video but there is no single network link between talker and listener which has available bandwidth (for whateve= r reason) and the question is can DetNet “seamlessly” split the= stream and send parts of it across different paths to the listener. It see= med like the feel of the room was that we shouldn’t be involved in doing this, however it was brought up that this function cou= ld be implemented in a similar way as packet replication and deletion, exce= pt that the packet sequence numbers are not duplicates so they would be acc= epted and it might “just work”. It sounds to me like it might be a useful thing to keep in there since it d= oesn’t seem like it would be that hard, but perhaps this is a DetNet = “future feature” that we don’t have to address now as lon= g as we don’t do anything that would preclude developing it later.
 
 --_000_e7e71da91ac94d1798911f63f83d36bbDLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:51:43 2016 Return-Path: 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 F30F812D622 for ; Thu, 7 Apr 2016 13:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 9JK3V327HUAx for ; Thu, 7 Apr 2016 13:51:35 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0734912D55A for ; Thu, 7 Apr 2016 13:51:35 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KneiM026199 for ; Thu, 7 Apr 2016 13:51:34 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjv05hv-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:51:34 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:51:33 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 13:51:32 -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.1076.000; Thu, 7 Apr 2016 13:51:31 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: =?Windows-1252?Q?DetNet_Use_Case_Statements:_Latency_matching_=96_single-?= =?Windows-1252?Q?_or_bi-directional?= Thread-Index: AdGRDoe5uN0yG/UaRCyeY8Qx+bksUA== Date: Thu, 7 Apr 2016 20:51:31 +0000 Message-ID: <7516b05e9b4948d69ebfcd8d664ee414@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_7516b05e9b4948d69ebfcd8d664ee414DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] =?windows-1252?q?DetNet_Use_Case_Statements=3A_Latency_m?= =?windows-1252?q?atching_=96_single-_or_bi-directional?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:51:38 -0000 --_000_7516b05e9b4948d69ebfcd8d664ee414DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Statement: Latency matching =96 single- or bi-directional Discussion: This came up because at least one use cases mentioned a need for multiple o= utgoing paths (or the send and return paths) to have matched latencies. I s= uppose one way to do this is to specify a latency which is the minimum, and= the add delay to the other path(s) to match it =96 but does this happen at= the DetNet level or is it something the application layer would do? --_000_7516b05e9b4948d69ebfcd8d664ee414DLBXCHPW03dolbynet_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Statement:
Latency matching =96 single- or bi-directional
Discussion:
This came up because at least one use cases mentioned a need for multi= ple outgoing paths (or the send and return paths) to have matched latencies= . I suppose one way to do this is to specify a latency which is the minimum= , and the add delay to the other path(s) to match it =96 but does this happen at the DetNet level or is it s= omething the application layer would do?
 
 --_000_7516b05e9b4948d69ebfcd8d664ee414DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:56:50 2016 Return-Path: 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 3E13312D55A for ; Thu, 7 Apr 2016 13:56:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 YERNwvbeYMYZ for ; Thu, 7 Apr 2016 13:56:47 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 665E812D608 for ; Thu, 7 Apr 2016 13:56:47 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37Ku6wP006630 for ; Thu, 7 Apr 2016 13:56:47 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy85jt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:56:47 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:56:45 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 13:56:44 -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.1076.000; Thu, 7 Apr 2016 13:56:44 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time Thread-Index: AdGRD/0EQIWJvj4vQxOXPJJbjPfNYA== Date: Thu, 7 Apr 2016 20:56:43 +0000 Message-ID: <1ee9e258c48d41f7926e7d0fbea92435@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_1ee9e258c48d41f7926e7d0fbea92435DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:56:49 -0000 --_000_1ee9e258c48d41f7926e7d0fbea92435DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's the text from the Use Case draft as a reminder: Some audio systems installed in public environments (airports, hospitals) have unique requirements with regards to health, sa= fety and fire concerns. One such requirement is a maximum of 3 seconds for = a system to respond to an emergency detection and begin sending appropriate w= arning signals and alarms without human intervention. For this requirement to= be met, the system must support a bounded and acceptable time from a notifi= cation signal to specific stream establishment. For further details see [ISO7= 240-16] From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Thursday, April 07, 2016 5:28 PM To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start)= Time Statement: Stream Start-up (or re-start) Time Discussion: It was noted that systems that really need a timely replacement for a faile= d device would probably use other methods (e.g. redundancy) rather than dep= ending on a bounded stream start-up time. I don't have a sense of the answ= er to this one. --_000_1ee9e258c48d41f7926e7d0fbea92435DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s the text fro= m the Use Case draft as a reminder:

Some audio systems instal= led in public environments (airports, hospitals)

    &= nbsp;           &nbs= p;       have unique requirements with regard= s to health, safety and fire concerns.

    &= nbsp;           &nbs= p;       One such requirement is a maximum of= 3 seconds for a system to respond to an

    &= nbsp;            &nb= sp;      emergency detection and begin sendin= g appropriate warning signals and alarms

    &= nbsp;           &nbs= p;       without human intervention. For this= requirement to be met, the system must

    &= nbsp;           &nbs= p;       support a bounded and acceptable tim= e from a notification signal to specific

    &= nbsp;           &nbs= p;       stream establishment. For further de= tails see [ISO7240-16]

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Thursday, April 07, 2016 5:28 PM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Stream Start-up (or re= -start) Time

 

Statement:

Stream Start-up (or re-start) Time=

Discussion:

It was noted that systems that really n= eed a timely replacement for a failed device would probably use other metho= ds (e.g. redundancy) rather than depending on a bounded stream start-up time.  I don’t have a sense of the answer to th= is one.  

 

--_000_1ee9e258c48d41f7926e7d0fbea92435DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 13:58:51 2016 Return-Path: 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 8A99C12D70E for ; Thu, 7 Apr 2016 13:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 FJqXGCMm3kol for ; Thu, 7 Apr 2016 13:58:46 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0E9E12D714 for ; Thu, 7 Apr 2016 13:58:46 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37Ku6wR006630 for ; Thu, 7 Apr 2016 13:58:46 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy85mk-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 13:58:46 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 13:58:44 -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.1076.9; Thu, 7 Apr 2016 13:58:43 -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.1076.000; Thu, 7 Apr 2016 13:58:43 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption Thread-Index: AdGRDBv0VuW29UCmQxSgR0D546MjQwABA3gA Date: Thu, 7 Apr 2016 20:58:42 +0000 Message-ID: References: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> In-Reply-To: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_b284469863514776b82884d682098214DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_14:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: Re: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 20:58:49 -0000 --_000_b284469863514776b82884d682098214DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here's the text from the Use Case draft: Digital Rights Management (DRM) is very important to the audio and video industries. Any time protected content is intro= duced into a network there are DRM concerns that must be maintained = (see [CONTENT_PROTECTION]). Many aspects of DRM are = outside the scope of network technology, however there are cases whe= n a secure link supporting authentication and encryption is req= uired by content owners to carry their audio or video content when it i= s outside their own secure environment (for example see ). As an example, two techniques are Digital Transm= ission Content Protection (DTCP) and High-Bandwidth Digital Content Prote= ction (HDCP). HDCP content is not approved for retransmission with= in any other type of DRM, while DTCP may be retransmitted under HDCP. The= refore if the source of a stream is outside of the network and it uses HD= CP protection it is only allowed to be placed on the network with that s= ame HDCP protection. From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Thursday, April 07, 2016 5:33 PM To: detnet@ietf.org Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encrypt= ion Statement: Link Authentication/Encryption Discussion: This statement came from a section of the Pro Audio use case (which was wri= tten by my co-author :-) and I haven't looked into the details of whether t= here is anything implied in that statement that would require us to do anyt= hing other than our current strategy of "don't break security". Perhaps Mr.= Gunther will enlighten us... :- ) --_000_b284469863514776b82884d682098214DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here’s the text fro= m the Use Case draft:

Digital Rights Management= (DRM) is very important to the audio and video

    &= nbsp;           &nbs= p;           industries. = Any time protected content is introduced into a network

    &= nbsp;           &nbs= p;           there are DR= M concerns that must be maintained (see

    &= nbsp;            &nb= sp;          [CONTENT_PRO= TECTION]). Many aspects of DRM are outside the scope of

    &= nbsp;           &nbs= p;           network tech= nology, however there are cases when a secure link

    &= nbsp;           &nbs= p;           supporting a= uthentication and encryption is required by content owners

    &= nbsp;           &nbs= p;           to carry the= ir audio or video content when it is outside their own

    &= nbsp;           &nbs= p;           secure envir= onment (for example see <xref target=3D"DCI"/>).</t><= o:p>

    &= nbsp;           &nbs= p;       <t>As an example, two techniqu= es are Digital Transmission Content Protection

    &= nbsp;           &nbs= p;           (DTCP) and H= igh-Bandwidth Digital Content Protection (HDCP). HDCP

    &= nbsp;           &nbs= p;           content is n= ot approved for retransmission within any other type of DRM,

    &= nbsp;            &nb= sp;          while DTCP m= ay be retransmitted under HDCP. Therefore if the source of a

    &= nbsp;           &nbs= p;           stream is ou= tside of the network and it uses HDCP protection it is only

    &= nbsp;           &nbs= p;           allowed to b= e placed on the network with that same HDCP protection.</t>

    &= nbsp;           &nbs= p;  

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Thursday, April 07, 2016 5:33 PM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/= Encryption

 

Statement:

Link Authentication/Encryption

Discussion:

This statement came from a section of t= he Pro Audio use case (which was written by my co-author :-) and I haven= 217;t looked into the details of whether there is anything implied in that statement that would require us to do anything other than our curr= ent strategy of “don’t break security”. Perhaps Mr. Gunth= er will enlighten us… :- )

 

 

--_000_b284469863514776b82884d682098214DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 14:00:15 2016 Return-Path: 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 75EF512D608 for ; Thu, 7 Apr 2016 14:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 O7zbkfci9oVS for ; Thu, 7 Apr 2016 14:00:10 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1D5512D10C for ; Thu, 7 Apr 2016 14:00:09 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37KxtLq009968 for ; Thu, 7 Apr 2016 14:00:09 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjv05st-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 14:00:09 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 14:00:08 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 14:00:07 -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.1076.000; Thu, 7 Apr 2016 14:00:06 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Plug-And-Play Thread-Index: AdGRCNkIZirEvHznTV28oe5F8truEg== Date: Thu, 7 Apr 2016 21:00:06 +0000 Message-ID: <179217173638485a976bafbcf1f3a7c5@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_179217173638485a976bafbcf1f3a7c5DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_15:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:00:14 -0000 --_000_179217173638485a976bafbcf1f3a7c5DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Plug-And-Play (new device, replace device) Discussion: Ethan: There are enough use cases and available technology for doing this, = and enough "feel of the room" that I claim it is in scope. It won't always = be possible (or useful) in every use case, so it must a feature that can be= selectively included in a given DetNet implementation. There is some disti= nction between introducing a "new" device into the network and replacing a = removed/failed device. However since a replacement for a failed device migh= t not be "exactly" the same as the original device (e.g. different firmware= revision) then some renegotiation seems inevitable (though maybe not as mu= ch as for a new device). --_000_179217173638485a976bafbcf1f3a7c5DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Plug-And-Play (new device, replace device)
Discussion:
Ethan: There are enough use cases and available technology for doing t= his, and enough “feel of the room” that I claim it is in scope.= It won’t always be possible (or useful) in every use case, so it mus= t a feature that can be selectively included in a given DetNet implementation. There is some distinction between introducing = a “new” device into the network and replacing a removed/failed = device. However since a replacement for a failed device might not be “= ;exactly” the same as the original device (e.g. different firmware revision) then some renegotiation seems inevitable (though maybe n= ot as much as for a new device).
 
 --_000_179217173638485a976bafbcf1f3a7c5DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 14:02:15 2016 Return-Path: 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 C84D712D55A for ; Thu, 7 Apr 2016 14:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ApgO_SjWWPhz for ; Thu, 7 Apr 2016 14:02:12 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CA9D12D10C for ; Thu, 7 Apr 2016 14:02:12 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37L1mPF010220 for ; Thu, 7 Apr 2016 14:02:12 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy85qm-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 14:02:12 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 14:02:10 -0700 Received: from DLB-XCHPW03.dolby.net (10.233.7.3) by DLB-XCHPW03.dolby.net (10.233.7.3) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Thu, 7 Apr 2016 14:02:09 -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.1076.000; Thu, 7 Apr 2016 14:02:08 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Link Aggregation Thread-Index: AdGRDTva8UR3PCVcSiml22f+uRWeAwAA3LZw Date: Thu, 7 Apr 2016 21:02:08 +0000 Message-ID: <9c8a366c426c4cf189f4cb3ad0e58360@DLB-XCHPW03.dolby.net> References: In-Reply-To: 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: multipart/alternative; boundary="_000_9c8a366c426c4cf189f4cb3ad0e58360DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_15:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:02:14 -0000 --_000_9c8a366c426c4cf189f4cb3ad0e58360DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Here is the Use Case draft text: For transmitting streams that require more bandwidth than a single link in the target network can support, link aggregation is= a technique for combining (aggregating) the bandwidth available on = multiple physical links to create a single logical link of the required ban= dwidth. However, if aggregation is to be used, the network controller (= or equivalent) must be able to determine the maximum latency of any path t= hrough the aggregate link. From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Thursday, April 07, 2016 5:45 PM To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Link Aggregation Statement: Link Aggregation Discussion: I used the term "link aggregation" without understanding that it is a reser= ved word in this context, so I need to figure out what the correct term is.= The use case is that the user has a high bandwidth stream such as video bu= t there is no single network link between talker and listener which has ava= ilable bandwidth (for whatever reason) and the question is can DetNet "seam= lessly" split the stream and send parts of it across different paths to the= listener. It seemed like the feel of the room was that we shouldn't be inv= olved in doing this, however it was brought up that this function could be = implemented in a similar way as packet replication and deletion, except tha= t the packet sequence numbers are not duplicates so they would be accepted = and it might "just work". It sounds to me like it might be a useful thing t= o keep in there since it doesn't seem like it would be that hard, but perha= ps this is a DetNet "future feature" that we don't have to address now as l= ong as we don't do anything that would preclude developing it later. --_000_9c8a366c426c4cf189f4cb3ad0e58360DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Here is the Use Case draf= t text:

For transmitting streams = that require more bandwidth than a single link in

    &= nbsp;           &nbs= p;       the target network can support, link= aggregation is a technique for

    &= nbsp;           &nbs= p;       combining (aggregating) the bandwidt= h available on multiple physical links

    &= nbsp;           &nbs= p;       to create a single logical link of t= he required bandwidth. However, if

    &= nbsp;           &nbs= p;       aggregation is to be used, the netwo= rk controller (or equivalent) must be

    &= nbsp;           &nbs= p;       able to determine the maximum latenc= y of any path through the aggregate

    &= nbsp;           &nbs= p;       link.

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Thursday, April 07, 2016 5:45 PM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Link Aggregation<= /o:p>

 

Statement:

Link Aggregation

Discussion:

I used the term “link aggregation= ” without understanding that it is a reserved word in this context, s= o I need to figure out what the correct term is. The use case is that the user has a high bandwidth stream such as video but there is no single = network link between talker and listener which has available bandwidth (for= whatever reason) and the question is can DetNet “seamlessly” s= plit the stream and send parts of it across different paths to the listener. It seemed like the feel of the room was t= hat we shouldn’t be involved in doing this, however it was brought up= that this function could be implemented in a similar way as packet replica= tion and deletion, except that the packet sequence numbers are not duplicates so they would be accepted and it might= “just work”. It sounds to me like it might be a useful thing t= o keep in there since it doesn’t seem like it would be that hard, but= perhaps this is a DetNet “future feature” that we don’t have to address now as long as we don’t do anything that= would preclude developing it later.

 

--_000_9c8a366c426c4cf189f4cb3ad0e58360DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 14:10:06 2016 Return-Path: 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 625CC12D665 for ; Thu, 7 Apr 2016 14:10:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 U1ZMfm1ktC38 for ; Thu, 7 Apr 2016 14:10:03 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565AC12D622 for ; Thu, 7 Apr 2016 14:10:03 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37L6BUN012693 for ; Thu, 7 Apr 2016 14:10:03 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy861p-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 07 Apr 2016 14:10:03 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 14:10:01 -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.1076.9; Thu, 7 Apr 2016 14:10:00 -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.1076.000; Thu, 7 Apr 2016 14:10:00 -0700 From: "Grossman, Ethan A." To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Traffic Segregation (multicast to many devices) Thread-Index: AdGRD2jJYvG/6rAXT/a4Yc3X9X4oxw== Date: Thu, 7 Apr 2016 21:09:59 +0000 Message-ID: <3604f117c91e43b993e822c52d1e4138@DLB-XCHPW03.dolby.net> 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: multipart/alternative; boundary="_000_3604f117c91e43b993e822c52d1e4138DLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-07_15:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Subject: [Detnet] DetNet Use Case Statements: Traffic Segregation (multicast to many devices) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:10:05 -0000 --_000_3604f117c91e43b993e822c52d1e4138DLBXCHPW03dolbynet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Statement: Traffic Segregation (multicast to many devices) Discussion: This is from the Pro Audio use case. The Use Case draft text is included be= low. It looks to me like this is a use case that would benefit from being c= onfigured via a central controller rather than having to do discovery on al= l of the devices? The assumption is that this is a plug-and-play (e.g. AVB)= network. So in implementations where we include the plug-and-play feature,= would it also include "traffic segregation" capability? Perhaps the techn= iques suggested below might be appropriate for this case?
Sink devices may be low cost devices with limited pr= ocessing power. In order to not overwhelm the CPUs in these devices it is im= portant to limit the amount of traffic that these devices must process.<= /t> As an example, consider the use of individual seat s= peakers in a cinema. These speakers are typically required to be cost re= duced since the quantities in a single theater can reach hundreds o= f seats. Discovery protocols alone in a one thousand seat theater can = generate enough broadcast traffic to overwhelm a low powered CPU. Thus an ins= tallation like this will benefit greatly from some type of traffic segregati= on that can define groups of seats to reduce traffic within each group. All s= eats in the theater must still be able to communicate with a central control= ler. There are many techniques that can be used to suppor= t this requirement including (but not limited to) the following exampl= es.
Packet forwarding rules can be used to eliminate= some extraneous streaming traffic from reaching potentially low= powered sink devices, however there may be other types of broadcast t= raffic that should be eliminated using other means for example VLANs = or IP subnets.
Multicast addressing is commonly used to keep ba= ndwidth utilization of shared links to a minimum. Because of the MAC Address forwarding nature of = Layer 2 bridges it is important that a multicast MAC address is only = associated with one stream. This will prevent reservations from for= warding packets from one stream down a path that has no interested sinks= simply because there is another stream on that same path that shares th= e same multicast MAC address. Since each multicast MAC Address can represent 3= 2 different IPv4 multicast addresses there must be a process put= in place to make sure this does not occur. Requiring use of IPv6 addr= ess can achieve this, however due to their continued prevalence, solu= tions that are effective for IPv4 installations are also required.
--_000_3604f117c91e43b993e822c52d1e4138DLBXCHPW03dolbynet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Statement:
Traffic Segregation (multicast to many devices)
Discussion:
This is from the Pro Audio use case. The Use Case draft text is includ= ed below. It looks to me like this is a use case that would benefit from be= ing configured via a central controller rather than having to do discovery = on all of the devices? The assumption is that this is a plug-and-play (e.g. AVB) network. So in implementations w= here we include the plug-and-play feature, would it also include “tra= ffic segregation” capability?  Perhaps the techniques suggested = below might be appropriate for this case?
 
           &nbs= p;    <section title=3D"Traffic Segregation">= ;
           &nbs= p;        <t>Sink devices may be l= ow cost devices with limited processing power. In order
           &nbs= p;            to not= overwhelm the CPUs in these devices it is important to limit the
           &nbs= p;            amount= of traffic that these devices must process.</t>
           &nbs= p;        <t>As an example, consid= er the use of individual seat speakers in a cinema.
           &nbs= p;            These = speakers are typically required to be cost reduced since the
           &nbs= p;            quanti= ties in a single theater can reach hundreds of seats. Discovery
           &nbs= p;            protoc= ols alone in a one thousand seat theater can generate enough broadcast
           &nbs= p;            traffi= c to overwhelm a low powered CPU. Thus an installation like this will
           &nbs= p;            benefi= t greatly from some type of traffic segregation that can define groups
           &nbs= p;            of sea= ts to reduce traffic within each group. All seats in the theater must
           &nbs= p;            still = be able to communicate with a central controller.</t>
           &nbs= p;        <t>There are many techni= ques that can be used to support this requirement
           &nbs= p;            includ= ing (but not limited to) the following examples.</t>
 
           &nbs= p;        <section title=3D"Pack= et Forwarding Rules, VLANs and Subnets">
           &nbs= p;            <t&= gt;Packet forwarding rules can be used to eliminate some extraneous
           &nbs= p;            &= nbsp;   streaming traffic from reaching potentially low powered s= ink devices,
           &nbs= p;            &= nbsp;   however there may be other types of broadcast traffic tha= t should be
           &nbs= p;            &= nbsp;   eliminated using other means for example VLANs or IP subn= ets.</t>
           &nbs= p;        </section>
 
           &nbs= p;        <section title=3D"Mult= icast Addressing (IPv4 and IPv6)">
           &nbs= p;            <t&= gt;Multicast addressing is commonly used to keep bandwidth utilization of
           &nbs= p;            &= nbsp;   shared links to a minimum.</t>
           &nbs= p;            <t&= gt;Because of the MAC Address forwarding nature of Layer 2 bridges it is
           &nbs= p;            &= nbsp;   important that a multicast MAC address is only associated= with one
           &nbs= p;            &= nbsp;   stream. This will prevent reservations from forwarding pa= ckets from one
           &nbs= p;            &= nbsp;   stream down a path that has no interested sinks simply be= cause there is
           &nbs= p;            &= nbsp;   another stream on that same path that shares the same mul= ticast MAC
           &nbs= p;            &= nbsp;   address.</t>
           &nbs= p;            <t&= gt;Since each multicast MAC Address can represent 32 different IPv4
           &nbs= p;            &= nbsp;   multicast addresses there must be a process put in place = to make sure
           &nbs= p;            &= nbsp;   this does not occur. Requiring use of IPv6 address can ac= hieve this,
           &nbs= p;            &= nbsp;   however due to their continued prevalence, solutions that= are effective
           &nbs= p;            &= nbsp;   for IPv4 installations are also required.</t>
           &nbs= p;        </section>
 
 --_000_3604f117c91e43b993e822c52d1e4138DLBXCHPW03dolbynet_-- From nobody Thu Apr 7 14:28:45 2016 Return-Path: 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 29BAD12D749 for ; Thu, 7 Apr 2016 14:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.46 X-Spam-Level: X-Spam-Status: No, score=-0.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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 Sm7UBAHMh2LJ for ; Thu, 7 Apr 2016 14:28:41 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 ABF1B12D738 for ; Thu, 7 Apr 2016 14:28:31 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id w85so115252985oiw.0 for ; Thu, 07 Apr 2016 14:28:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=0gzBZgaNPAzdaQ2BMK1GAooc2mW9fuCCYccD3r3P+DA=; b=L+tMKlNdAj0S+lbv8fnizoiXUyUJUWQUeYUk21aKw1C/plQUQBentvIOo9a0flRnET 0wmzaIA4E1GSO/eEwa/TgGb3l+rDCvcoRR+4jRzHiIRvGWx2GKw+2CND8MuriRGexP1F QSSfPxWV53xIbnyF6AOaievpoDlTi4roTH655tdNa5P/iqU9v6vKS4T9wUdBoOUO5paj sbisEANRLXu60bQDa6jQ2iQaAE5DuafhPKqQsZ0U8JKE8+lwl6rcwR3IcYytcdymxTGS rU3DSzAHGlTNSMbl9sVkZZQkxfDYZF3WUev5o+/UeG/Lk6jkJvuGHbOJg6s4Ob6Q38Zq H+NQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=0gzBZgaNPAzdaQ2BMK1GAooc2mW9fuCCYccD3r3P+DA=; b=ZA1F9KNPoMuMdRWyWBujdEJbWmampz6iviu+lbJWKJ6uodBakT06UpgFoP2p62v5Xf 7T7bxwRX3RSK40lEDWH+KeUNUGBHRL/I8FwNkjrOvSd36cNusXlhRJiAWU3vVCvx04rP rgCD7Jnsp3GjLjqz8KSNJc8Pjf637c9G8LUbylj1IQzyVH45KV0HpYBXIS9BE+fNaxzB YbnV1jnu4RHgg066fRn7bEmT5ILg05QmXUVjbOHEfdDnUi4riDExrzdsKW4Isblm3Dhr LM3I+ayGAtFJ0veQDJ88gWFTl2XFL36UcBz/Dx3Es8U5xgG0OyhHRJoYPO6CnCxNRaPa 9J9Q== X-Gm-Message-State: AD7BkJLtD79V8q7ZoUii+jbkv6JlbaVEC5Q2iAi+vzTqqrUcU4lKs9Pof04+Q2M3ny4tXLDhDWejZbiAiDQDoA== MIME-Version: 1.0 X-Received: by 10.202.46.139 with SMTP id u133mr2383211oiu.16.1460064511100; Thu, 07 Apr 2016 14:28:31 -0700 (PDT) Received: by 10.76.113.233 with HTTP; Thu, 7 Apr 2016 14:28:31 -0700 (PDT) In-Reply-To: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net> References: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net> Date: Thu, 7 Apr 2016 17:28:31 -0400 Message-ID: From: Subir Das To: "Grossman, Ethan A." Content-Type: multipart/alternative; boundary=001a1137c99c888b52052febc2ca Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 21:28:45 -0000 --001a1137c99c888b52052febc2ca Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for the clarifications. So what you mean by 'Open Internet' is that DetNet services provided by provider X may not be available to provider Y. This is fine and it is an administration policy as you have indicated. However, the underlying network model should not have restrictions if they would like to provide access to each other services. Would you agree? On Thu, Apr 7, 2016 at 4:19 PM, Grossman, Ethan A. wrote= : > I believe so, in the sense that we are talking about =E2=80=9Centerprise= =E2=80=9D > networks, and presumably access is restricted for the whole network, not > just DetNet services on that network. Whether access to DetNet services > among authorized users of that network is restricted seems to me a matter > of administration for that network. I would say a deployment of DetNet > services needs to follow the network model (i.e. architecture) that we > (DetNet) establish, although it is clear that there will be various > differing implementations, so in that case it is not so =E2=80=9Cspecific= =E2=80=9D in terms > of =E2=80=9Cwhat bits are on the wire=E2=80=9D. Right? > > > > *From:* Subir Das [mailto:subirdas21@gmail.com] > *Sent:* Thursday, April 07, 2016 5:12 PM > *To:* Grossman, Ethan A. > *Cc:* detnet@ietf.org > *Subject:* Re: [Detnet] DetNet Use Case Statements: The Open Internet > > > > Ethan, > > Thanks for starting the discussion. When you say no, does this mean the > access to DetNet services will be restricted and the deployment of DetNet > services need to follow a specific network model? > > -Subir > > > > > > > > On Thu, Apr 7, 2016 at 3:56 PM, Grossman, Ethan A. > wrote: > > Statement: > > The Open Internet =E2=80=93 (not in scope) - But does future planning for= this > affect DetNet? > > Discussion: > > Ethan: AFAICT the answer is basically =E2=80=9Cno=E2=80=9D. The question = of =E2=80=9Cprivacy=E2=80=9D (in > the RFC 7258 sense) came up, but I am still waiting to hear if that is an > issue on private networks. If anyone can think of anything else that bear= s > on this please speak up. > > > > > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > --001a1137c99c888b52052febc2ca Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for the clarifications. So what you mean by 'Op= en Internet'=C2=A0 is that DetNet services provided by provider X may n= ot be available to provider Y. This is fine and it is an administration pol= icy as you have indicated.=C2=A0 However, the underlying network model=C2= =A0 should not=C2=A0 have restrictions if they would like to provide access= to each other services. Would you agree?



On Thu, Apr 7, 2016 at 4:19 PM, = Grossman, Ethan A. <eagros@dolby.com> wrote:

I believe so, in the sens= e that we are talking about =E2=80=9Centerprise=E2=80=9D networks, and pres= umably access is restricted for the whole network, not just DetNet services on that network. Whether access to DetNet services among authorized users = of that network is restricted seems to me a matter of administration for th= at network. I would say a deployment of DetNet services needs to follow the= network model (i.e. architecture) that we (DetNet) establish, although it is clear that there will be variou= s differing implementations, so in that case it is not so =E2=80=9Cspecific= =E2=80=9D in terms of =E2=80=9Cwhat bits are on the wire=E2=80=9D. Right? = =C2=A0=C2=A0=C2=A0

=C2=A0

From: Subir Da= s [mailto:subirda= s21@gmail.com]
Sent: Thursday, April 07, 2016 5:12 PM
To: Grossman, Ethan A.
Cc: detnet@ietf= .org
Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet<= u>

=C2=A0

Ethan,

Thanks for starting t= he discussion. When you say no, does this mean the access to DetNet service= s will be restricted and the deployment of DetNet services need to follow a= specific=C2=A0 network model?

-Subir



=C2=A0


--001a1137c99c888b52052febc2ca-- From nobody Thu Apr 7 15:41:49 2016 Return-Path: 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 16C0712D718 for ; Thu, 7 Apr 2016 15:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 CK7c3mdOtxgP for ; Thu, 7 Apr 2016 15:41:43 -0700 (PDT) Received: from mx0a-000fd501.pphosted.com (mx0a-000fd501.pphosted.com [67.231.144.242]) (using TLSv1.2 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09B0412D169 for ; Thu, 7 Apr 2016 15:41:43 -0700 (PDT) Received: from pps.filterd (m0045961.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u37Mfgam006419; Thu, 7 Apr 2016 15:41:42 -0700 Received: from dlb-xmrpw02.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 225vjy88nx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 07 Apr 2016 15:41:42 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW02.dolby.net (10.213.22.205) with Microsoft SMTP Server (TLS) id 14.3.266.1; Thu, 7 Apr 2016 15:41:41 -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.1076.9; Thu, 7 Apr 2016 15:41:39 -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.1076.000; Thu, 7 Apr 2016 15:41:39 -0700 From: "Grossman, Ethan A." To: Subir Das Thread-Topic: [Detnet] DetNet Use Case Statements: The Open Internet Thread-Index: AQHRkQm7SWY7rQ7CU0K2Ew5aOU+6mZ9+8heAgACKC4D//58X/Q== Date: Thu, 7 Apr 2016 22:41:39 +0000 Message-ID: References: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_F766AF5CF75B415AA4CEF105114CAB39dolbycom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-08_01:2016-04-07,2016-04-07,1970-01-01 signatures=0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2016 22:41:47 -0000 --_000_F766AF5CF75B415AA4CEF105114CAB39dolbycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes - then it would be Patrick's case of connecting two "consenting" networ= ks, right? On Apr 7, 2016, at 6:28 PM, Subir Das > wrote: Thanks for the clarifications. So what you mean by 'Open Internet' is that= DetNet services provided by provider X may not be available to provider Y.= This is fine and it is an administration policy as you have indicated. Ho= wever, the underlying network model should not have restrictions if they = would like to provide access to each other services. Would you agree? On Thu, Apr 7, 2016 at 4:19 PM, Grossman, Ethan A. > wrote: I believe so, in the sense that we are talking about "enterprise" networks,= and presumably access is restricted for the whole network, not just DetNet= services on that network. Whether access to DetNet services among authoriz= ed users of that network is restricted seems to me a matter of administrati= on for that network. I would say a deployment of DetNet services needs to f= ollow the network model (i.e. architecture) that we (DetNet) establish, alt= hough it is clear that there will be various differing implementations, so = in that case it is not so "specific" in terms of "what bits are on the wire= ". Right? From: Subir Das [mailto:subirdas21@gmail.com] Sent: Thursday, April 07, 2016 5:12 PM To: Grossman, Ethan A. Cc: detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet Ethan, Thanks for starting the discussion. When you say no, does this mean the acc= ess to DetNet services will be restricted and the deployment of DetNet serv= ices need to follow a specific network model? -Subir On Thu, Apr 7, 2016 at 3:56 PM, Grossman, Ethan A. > wrote: Statement: The Open Internet - (not in scope) - But does future planning for this affe= ct DetNet? Discussion: Ethan: AFAICT the answer is basically "no". The question of "privacy" (in t= he RFC 7258 sense) came up, but I am still waiting to hear if that is an is= sue on private networks. If anyone can think of anything else that bears on= this please speak up. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_F766AF5CF75B415AA4CEF105114CAB39dolbycom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Yes - then it would be Patrick's case of connecting two "consenti= ng" networks, right?

On Apr 7, 2016, at 6:28 PM, Subir Das <subirdas21@gmail.com> wrote:

Thanks for the clarifications. So what you mean by 'Open I= nternet'  is that DetNet services provided by provider X may not be av= ailable to provider Y. This is fine and it is an administration policy as y= ou have indicated.  However, the underlying network model  should not  have restrictions if they would like = to provide access to each other services. Would you agree?



On Thu, Apr 7, 2016 at 4:19 PM, Grossman, Ethan = A. <eagros@dolby.com<= /a>> wrote:

I believe so, in the sens= e that we are talking about “enterprise” networks, and presumab= ly access is restricted for the whole network, not just DetNet services on that network. Whether access to DetNet services among authorized users = of that network is restricted seems to me a matter of administration for th= at network. I would say a deployment of DetNet services needs to follow the= network model (i.e. architecture) that we (DetNet) establish, although it is clear that there will be variou= s differing implementations, so in that case it is not so “specific&#= 8221; in terms of “what bits are on the wire”. Right?  &nb= sp; 

 

From: Subir Da= s [mailto:subirda= s21@gmail.com]
Sent: Thursday, April 07, 2016 5:12 PM
To: Grossman, Ethan A.
Cc: detnet@ietf= .org
Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet<= u>

 

Ethan,

Thanks for starting t= he discussion. When you say no, does this mean the access to DetNet service= s will be restricted and the deployment of DetNet services need to follow a= specific  network model?

-Subir



 


--_000_F766AF5CF75B415AA4CEF105114CAB39dolbycom_-- From nobody Fri Apr 8 15:57:21 2016 Return-Path: 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 0C78F12D0E1 for ; Fri, 8 Apr 2016 15:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=meraki.net 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 OPaRqahGgbYN for ; Fri, 8 Apr 2016 15:57:17 -0700 (PDT) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 43DE212D55B for ; Fri, 8 Apr 2016 15:57:17 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id q128so148581084iof.3 for ; Fri, 08 Apr 2016 15:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=meraki.net; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5LL066y33K7nhuU08bWhLL99XUBGCAvokBNYjd4vLaw=; b=ADbIF2DTFY8Y12mqK1pXaV9Dx5N9FWYm8bfwmGeb882x5BGd8ivIUnoN/Zj59f29xd xivtx2uf6d+jueW5JkxFGf2+1ugx+18d/LIPO19mN7wzIRk++x3F/cIe3bEZj/O+3BfK 4N6P1jm9BK/a1bkz7He8K+clb5JXEmpPg/z+c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5LL066y33K7nhuU08bWhLL99XUBGCAvokBNYjd4vLaw=; b=F/lr5ztPiGSa8vskBVm08d+/zXQD8eJm/L/vMCGesdw6sr29ZXxKUj/FvwCbUrqho3 bvWgCuUqXbl6KM3w9QXUwCTB/uGbXzXU6ghftohHhXsWLK2Ut/Ui3u5KIluYzjIWxb9Z B0jVfXimj+Q43jPWIOQinPU9cKO6hbwkedBz08Ka44uJ6bD4OGHjJg6UBOyLlfG+jPqV h5e1nvhuzw5ofUXFCgGtRksqUsTnGYstIc/sO7ZqeLBtI//qqlxSsDCG8ZFSj02SB38G vSFk5hTxMwhbToPGVU3gEFhuGpdMmkB3r2OqR36Rzj4uYthIAdtcneBgje42XfvdreMb +N2A== X-Gm-Message-State: AD7BkJIO+bJW6uZJ/RisSK8GXXXwlcEe6dX8/YrjIEzZ+MibVKmxR1bzNjABcazNdLLA0UNXZBX3MFB0lz9kY1j1 X-Received: by 10.107.1.18 with SMTP id 18mr11855044iob.74.1460156236518; Fri, 08 Apr 2016 15:57:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.153.83 with HTTP; Fri, 8 Apr 2016 15:56:57 -0700 (PDT) In-Reply-To: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net> References: <487af79ba316492086d7ab597de02642@DLB-XCHPW03.dolby.net> From: Simon Barber Date: Fri, 8 Apr 2016 15:56:57 -0700 Message-ID: To: "Grossman, Ethan A." Content-Type: multipart/alternative; boundary=001a113968dccb70730530011dc4 Archived-At: Cc: "detnet@ietf.org" , Subir Das Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 22:57:20 -0000 --001a113968dccb70730530011dc4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In general you should regard all networks as compromised, even if they are supposed to be private. On Thu, Apr 7, 2016 at 1:19 PM, Grossman, Ethan A. wrote= : > I believe so, in the sense that we are talking about =E2=80=9Centerprise= =E2=80=9D > networks, and presumably access is restricted for the whole network, not > just DetNet services on that network. Whether access to DetNet services > among authorized users of that network is restricted seems to me a matter > of administration for that network. I would say a deployment of DetNet > services needs to follow the network model (i.e. architecture) that we > (DetNet) establish, although it is clear that there will be various > differing implementations, so in that case it is not so =E2=80=9Cspecific= =E2=80=9D in terms > of =E2=80=9Cwhat bits are on the wire=E2=80=9D. Right? > > > > *From:* Subir Das [mailto:subirdas21@gmail.com] > *Sent:* Thursday, April 07, 2016 5:12 PM > *To:* Grossman, Ethan A. > *Cc:* detnet@ietf.org > *Subject:* Re: [Detnet] DetNet Use Case Statements: The Open Internet > > > > Ethan, > > Thanks for starting the discussion. When you say no, does this mean the > access to DetNet services will be restricted and the deployment of DetNet > services need to follow a specific network model? > > -Subir > > > > > > > > On Thu, Apr 7, 2016 at 3:56 PM, Grossman, Ethan A. > wrote: > > Statement: > > The Open Internet =E2=80=93 (not in scope) - But does future planning for= this > affect DetNet? > > Discussion: > > Ethan: AFAICT the answer is basically =E2=80=9Cno=E2=80=9D. The question = of =E2=80=9Cprivacy=E2=80=9D (in > the RFC 7258 sense) came up, but I am still waiting to hear if that is an > issue on private networks. If anyone can think of anything else that bear= s > on this please speak up. > > > > > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > > --001a113968dccb70730530011dc4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In general you should regard all networks as compromised, = even if they are supposed to be private.
On Thu, Apr 7, 2016 at 1:19 PM, Grossman, Etha= n A. <eagros@dolby.com> wrote:

I believe so, in the sens= e that we are talking about =E2=80=9Centerprise=E2=80=9D networks, and pres= umably access is restricted for the whole network, not just DetNet services on that network. Whether access to DetNet services among authorized users = of that network is restricted seems to me a matter of administration for th= at network. I would say a deployment of DetNet services needs to follow the= network model (i.e. architecture) that we (DetNet) establish, although it is clear that there will be variou= s differing implementations, so in that case it is not so =E2=80=9Cspecific= =E2=80=9D in terms of =E2=80=9Cwhat bits are on the wire=E2=80=9D. Right? = =C2=A0=C2=A0=C2=A0

=C2=A0

From: Subir Da= s [mailto:subirda= s21@gmail.com]
Sent: Thursday, April 07, 2016 5:12 PM
To: Grossman, Ethan A.
Cc: detnet@ietf= .org
Subject: Re: [Detnet] DetNet Use Case Statements: The Open Internet<= u>

=C2=A0

Ethan,

Thanks for starting t= he discussion. When you say no, does this mean the access to DetNet service= s will be restricted and the deployment of DetNet services need to follow a= specific=C2=A0 network model?

-Subir



=C2=A0


_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.org/mailman/listinfo/detnet


--001a113968dccb70730530011dc4-- From nobody Sun Apr 10 10:26:24 2016 Return-Path: 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 10F3712D0A2 for ; Sun, 10 Apr 2016 10:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 cWUiQ10aepqM for ; Sun, 10 Apr 2016 10:26:21 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9734512B064 for ; Sun, 10 Apr 2016 10:26:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5461; q=dns/txt; s=iport; t=1460309181; x=1461518781; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=UNT1hACmqNmyUgFQfvFs3Dly1/7aOpG8VgVyb+s8/wI=; b=c95TGAuc/FM3WL6n8Tis78663LiBrjWMxmMYK+AVt06vF7GD22RbJ8V0 zYkMrVdln+CB7csIJHszSMcjdyQQBdRJP7gB6FudJ7ddtZvpQQwrhUmGW 9vtCvbbFkIFR/N/2VirzN/vpCCvq68JJPxeV+UERGIbXtCec2peXNvsk3 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0C7BQDBiwpX/5FdJa1cgmtMU321YoUBg?= =?us-ascii?q?XMXAQmFIkoCgSE5EwEBAQEBAQFlJ4RCAQEEAQEBKkELEAIBCAQ7BycLFBEBAQQ?= =?us-ascii?q?OBYgnDrweAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYF1CIJOhGyCfoIrBYdth?= =?us-ascii?q?xOJBAGOC48NjyUBIgM9g2dsiisBAQE?= X-IronPort-AV: E=Sophos; i="5.24,462,1454976000"; d="scan'208,217"; a="92164257" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Apr 2016 17:26:20 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u3AHQKP2020487 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 10 Apr 2016 17:26:20 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Sun, 10 Apr 2016 12:26:19 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Sun, 10 Apr 2016 12:26:19 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." Thread-Topic: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time Thread-Index: AdGRCy7WSH98dpgkSOigK+oEh/VQ7ACQumUW Date: Sun, 10 Apr 2016 17:26:19 +0000 Message-ID: References: <60ea8b8dab5e44098f5174a9491507ad@DLB-XCHPW03.dolby.net> In-Reply-To: <60ea8b8dab5e44098f5174a9491507ad@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_A6E90ED9E3C843328F985B6BB3806465ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Apr 2016 17:26:23 -0000 --_000_A6E90ED9E3C843328F985B6BB3806465ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ethan What you point at it very true, and the point is probably that since you do= not know what will break, you cannot guarantee that it can be fixed by a s= imple reboot or will require a complete rebuild of the system. So people ar= e after all forms of diversity to avoid that any individual cause of failur= e breaks the service. In wireless communications, such diversity includes not only path redundanc= y but also time (ARQ), frequency (TSCH, FH), and encoding (network coding, = CDMA, FEC). At one extreme we find safety related applications. People will apply paral= lelism to any degree that they feel necessary, down to requiring different = implementations in the parallel operations, or more than 1+1. An Example of= this extreme can be found in the plane control systems of an X-29: 3 analo= g and 3 Digital computers. At the other extreme we have things like live-live video. Their need is pre= tty much that of MPLS TP. They want a non congruent plan B to be establishe= d between the content source and consumer so the path can be switched befor= e the user can feel it. In that case, most of the detnet features are actually done at the app laye= r and the buffers used to absorb jitter also compensate for duplicate and o= ut of sequence datagrams. How would they have designed this app if the netw= ork had been deterministic to start with ? I hope this helps, Pascal Le 7 avr. 2016 ? 13:28, Grossman, Ethan A. > a ?crit : Statement: Stream Start-up (or re-start) Time Discussion: It was noted that systems that really need a timely replacement for a faile= d device would probably use other methods (e.g. redundancy) rather than dep= ending on a bounded stream start-up time. I don't have a sense of the answ= er to this one. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_A6E90ED9E3C843328F985B6BB3806465ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Ethan

What you point at it very true, and the point is probably that since y= ou do not know what will break, you cannot guarantee that it can be fixed b= y a simple reboot or will require a complete rebuild of the system. So peop= le are after all forms of diversity to avoid that any individual cause of failure breaks the service. 

In wireless communications, such diversity includes not only path redu= ndancy but also time (ARQ), frequency (TSCH, FH), and encoding (network cod= ing, CDMA, FEC).

At one extreme we find safety related applications. People will apply = parallelism to any degree that they feel necessary, down to requiring diffe= rent implementations in the parallel operations, or more than 1+1. An E= xample of this extreme can be found in the plane control systems of an X-29: 3 analog and 3 Digital computers.=

At the other extreme we have things like live-live video. Their need i= s pretty much that of MPLS TP. They want a non congruent plan B to be estab= lished between the content source and consumer so the path can be switched = before the user can feel it. 

In that case, most of the detnet features are actually done at the app= layer and the buffers used to absorb jitter also compensate for duplicate = and out of sequence datagrams. How would they have designed this app if the= network had been deterministic to start with ? 

I hope this helps,

Pascal

Le 7 avr. 2016 à 13:28, Grossman, Ethan A. <eagros@dolby.com> a écrit :

Statement:
Stream Start-up (or re-start) Time
Discussion:
It was noted that systems that really need a timely replacement for a = failed device would probably use other methods (e.g. redundancy) rather tha= n depending on a bounded stream start-up time.  I don’t have a s= ense of the answer to this one.  
 
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.= ietf.org/mailman/listinfo/detnet
--_000_A6E90ED9E3C843328F985B6BB3806465ciscocom_-- From nobody Tue Apr 12 01:53:30 2016 Return-Path: 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 1BFCE12E8B5; Tue, 12 Apr 2016 01:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.216 X-Spam-Level: X-Spam-Status: No, score=-5.216 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, 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 XKgPL9d7cdvE; Tue, 12 Apr 2016 01:53:23 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6ED12E8B1; Tue, 12 Apr 2016 01:53:22 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CLX82344; Tue, 12 Apr 2016 08:53:19 +0000 (GMT) Received: from SZXEMA412-HUB.china.huawei.com (10.82.72.71) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.235.1; Tue, 12 Apr 2016 09:53:17 +0100 Received: from SZXEMA506-MBS.china.huawei.com ([169.254.4.160]) by SZXEMA412-HUB.china.huawei.com ([10.82.72.71]) with mapi id 14.03.0235.001; Tue, 12 Apr 2016 16:53:08 +0800 From: Jiangyuanlong To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Providing Synchronized Time Thread-Index: AdGRCKJDoI4EO4AYS9GGhMr+RHKjNgDhxzmg Date: Tue, 12 Apr 2016 08:53:07 +0000 Message-ID: <3B0A1BED22CAD649A1B3E97BE5DDD68B9168837A@szxema506-mbs.china.huawei.com> References: <8583e31212574c81ae93fbae34369b3d@DLB-XCHPW03.dolby.net> In-Reply-To: <8583e31212574c81ae93fbae34369b3d@DLB-XCHPW03.dolby.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.76.118] Content-Type: multipart/alternative; boundary="_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090202.570CB780.004D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 4fa66b7bfddeb80868c9fb51328e6b7e Archived-At: Cc: "scsn@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: Providing Synchronized Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 08:53:26 -0000 --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ethan, It seems to me this use case can be further partitioned into two different = problems: 1. Providing sync info within a DetNet, so that all nodes in the DetNet are= synchronized to the same clock, for example, each node runs in the BC mode= of IEEE 1588v2 and an external GPS/GNSS receiver provides the clock source= for all nodes in this DetNet network; 2. Transporting sync info for the 3rd party across a DetNet. This can furth= er be divided into two cases: a) The DetNet is not aware of the timing info, but take it as a low delay s= ervice. b) The DetNet is aware of the timing info, some of the nodes in the DetNet = may provide timing correction for the timing info. For example, several nod= es in the DetNet network can work in the TC mode of IEEE 1588v2. IMO, 2.a) is already in the scope of the DetNet; 1 is essential for DetNet,= but not yet in its scope; 2.b) can be an interesting application for the D= etNet. Regards, Yuanlong From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Friday, April 08, 2016 4:05 AM To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Providing Synchronized Time Statement: Providing Synchronized Time (not in scope) Discussion: A point came up about whether DetNet streams could serve as a way to delive= r timekeeping packets in a more timely way in order to provide more accurat= e time. We concluded that this was a possible use case for DetNet, and invi= te contributions of use case text on the topic. However since DetNet itself= depends on time sync to function, making timekeeping depend on DetNet is a= circular dependency so doesn't seem feasible. --_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ethan,<= o:p>

 = ;

It seems t= o me this use case can be further partitioned into two different problems:

1. Providi= ng sync info within a DetNet, so that all nodes in the DetNet are synchroni= zed to the same clock, for example, each node runs in the BC mode of IEEE 1588v2 and an external GPS/GNSS receiver provides the cloc= k source for all nodes in this DetNet network;

2. Transpo= rting sync info for the 3rd party across a DetNet. This can furt= her be divided into two cases:

a) The Det= Net is not aware of the timing info, but take it as a low delay service.

b) The Det= Net is aware of the timing info, some of the nodes in the DetNet may provid= e timing correction for the timing info. For example, several nodes in the DetNet network can work in the TC mode of IEEE 1588v2.

 = ;

IMO, 2.a) = is already in the scope of the DetNet; 1 is essential for DetNet, but not yet in its scope; 2.b) can be an interesting application for the DetNe= t.

 = ;

Regards,

Yuanlong



From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Etha= n A.
Sent: Friday, April 08, 2016 4:05 AM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Providing Synchronized= Time

 

Statement:

Providing Synchronized Time (not in scope)=

Discussion:

A point came up about whether DetNet streams co= uld serve as a way to deliver timekeeping packets in a more timely way in order to provide more accurate time. We concluded that this was a possi= ble use case for DetNet, and invite contributions of use case text on the t= opic. However since DetNet itself depends on time sync to function, making = timekeeping depend on DetNet is a circular dependency so doesn’t seem feasible.

 

 

--_000_3B0A1BED22CAD649A1B3E97BE5DDD68B9168837Aszxema506mbschi_-- From nobody Tue Apr 12 14:25:33 2016 Return-Path: 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 DA90412E9DC for ; Tue, 12 Apr 2016 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 M1oyQ1qXlvVN for ; Tue, 12 Apr 2016 14:25:30 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27A1212E9D8 for ; Tue, 12 Apr 2016 14:25:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10206; q=dns/txt; s=iport; t=1460496330; x=1461705930; h=from:to:subject:date:message-id:mime-version; bh=wQLMHyQmjec3K7aK+pemkM4KKae1XSPUI+z4l13ASMg=; b=lbnvO4ESGiE3tkygMzL9QuY2l3sIIQ5QaZzqh7uVNKmPWuPmAYGa70SD 9VTRgwrU0gMaQN4SurR+6Ebi9Kv26GipHEGoclAWIaw3A5GJsf5seWyFK 1J9UwpfbYbqEo+7wOO7XrXPEV7kSFwyQf8a/SaqJLEWT5+jS5Z9W1YdDk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAgDGZg1X/4YNJK1UCoJrTIFQBrVvh?= =?us-ascii?q?HMBDYF2hg4egR44FAEBAQEBAQFlJ4RBAQIEIwpeAQgRAwECKAMCBDAUCQoEARI?= =?us-ascii?q?biA2wE5IRAQEBAQEBBAEBAQEBARqGIYRLhA0ISoJgglYFmAgBiGmFI48QjyYBH?= =?us-ascii?q?gEBQoNnbIhIP34BAQE?= X-IronPort-AV: E=Sophos;i="5.24,476,1454976000"; d="scan'208,217";a="260579656" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 21:25:29 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3CLPT9A032140 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 21:25:29 GMT Received: from xch-rcd-018.cisco.com (173.37.102.28) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 16:25:28 -0500 Received: from xch-rcd-018.cisco.com ([173.37.102.28]) by XCH-RCD-018.cisco.com ([173.37.102.28]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 16:25:28 -0500 From: "Norman Finn (nfinn)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Link Aggregation Thread-Index: AQHRlQHVZXnFE6jkgUWcIcVkY84gAw== Date: Tue, 12 Apr 2016 21:25:28 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.1.160122 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.41.101] Content-Type: multipart/alternative; boundary="_000_D332B04B4BFB1nfinnciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 21:25:32 -0000 --_000_D332B04B4BFB1nfinnciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RXRoYW4sDQoNCkRvbuKAmXQgbG9zZSB0aGlzIHVzZSBjYXNlLiAgV2hldGhlciBpdCBpcyBhIHBy b2JsZW0gZm9yIERldE5ldCBpcyBhbiBvcGVuIHF1ZXN0aW9uLiAgV2hhdCB5b3VyIHByb2JsZW0g YW5kIHRoZSDigJxQYWNrZXQgUmVwbGljYXRpb24gYW5kIERlbGV0aW9uIChQUkQp4oCdIChvciBT ZWFtbGVzcyBSZWR1bmRhbmN5KSBoYXZlIGluIGNvbW1vbiBpcyB0aGF0IHRoZXkgY2FuIGJvdGgg YmUgc29sdmVkIGJ5IGEgc2VxdWVuY2UgbnVtYmVyIGluIGV2ZXJ5IHBhY2tldC4gIEJ1dCwgdGhl cmUgYXJlIGRpZmZlcmVuY2VzLg0KDQpQUkQ6ICAgIER1cGxpY2F0ZSBldmVyeSBwYWNrZXQgaW4g YSBzaW5nbGUgc3RyZWFtLiAgU2VuZCBvbiB0d28gcGF0aHMuICBEZWxldGUgdGhlIGR1cGxpY2F0 ZXMuICBTZXF1ZW5jZSBudW1iZXJzIGFyZSBlc3NlbnRpYWwgdG8gaWRlbnRpZnkgZHVwbGljYXRl IHBhY2tldHMuICBSZXN0b3JpbmcgcGFja2V0IG9yZGVyIGlzIGFuIG9wdGlvbiwgYnV0IG1hbnkg YXJlIHJlbHVjdGFudCB0byBtYWtlIHRoaXMgYW4gb2JqZWN0aXZlLg0KDQpZb3VyczogIFNwbGl0 IGEgc2luZ2xlIHN0cmVhbSwgc2VuZGluZyBzb21lIHBhY2tldHMgb24gb25lIHBhdGgsIGFuZCBv dGhlciBwYWNrZXRzIG9uIGFub3RoZXIgcGF0aC4gIEJyaW5nIHRoZW0gYmFjayB0b2dldGhlci4g IFNlcXVlbmNlIG51bWJlcnMgYXJlIG5lZWRlZCBvbmx5IGlmIHJlc3RvcmluZyBwYWNrZXQgb3Jk ZXIuDQoNCk5vcm1hbGx5LCB0b2RheSwgd2hlbiBvbmUgaGFzIG11bHRpcGxlIGxpbmtzIGJldHdl ZW4gdHdvIGRldmljZXMsIG9uZSB0cmllcyB2ZXJ5IGhhcmQgdG8gZW5zdXJlIHRoYXQgYW55IGdp dmVuIGZsb3cgaXMgYWxsIHB1dCBvbiBvbmUgb2YgdGhlIGxpbmtzLCBpbiBvcmRlciB0byBtaW5p bWl6ZSBvdXQtb2Ytb3JkZXIgZGVsaXZlcnkuICAoVXNpbmcgbXVsdGlwbGUgbGlua3MgZm9yIG9u ZSBzdHJlYW0gZ2VuZXJhbGx5IHNodWZmbGVzIHBhY2tldHMuKSAgT2YgY291cnNlLCB0aGlzIGlz IGV4YWN0bHkgd2hhdCB5b3XigJlyZSB0cnlpbmcgdG8gZml4LiAgVGVsbCBtZSDigJQgZG8gdGhl IHBhY2tldHMgbmVlZCB0byBiZSBkZWxpdmVyZWQgaW4gb3JkZXI/DQoNCklNTywgdGhlIHByb2Js ZW0geW914oCZcmUgYnJpbmdpbmcgdXAgaXMgaW1wb3J0YW50LCBidXQgaXMgb25seSByZWxhdGVk IHRvIHRoZSBEZXROZXQgcHJvYmxlbSBieSBoYXZpbmcgYSB1c2VyICh2aWRlbyBzdHVkaW8pIHRo YXQgbmVlZHMgc29sdXRpb25zIHRvIGJvdGggcHJvYmxlbXMuDQoNCuKAlCBOb3JtDQoNCkZyb206 IGRldG5ldCA8ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmRldG5ldC1ib3VuY2VzQGll dGYub3JnPj4gb24gYmVoYWxmIG9mICJHcm9zc21hbiwgRXRoYW4gQS4iIDxlYWdyb3NAZG9sYnku Y29tPG1haWx0bzplYWdyb3NAZG9sYnkuY29tPj4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCA3LCAy MDE2IGF0IDEzOjQ0IFBNDQpUbzogImRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYu b3JnPiIgPGRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPj4NClN1YmplY3Q6 IFtEZXRuZXRdIERldE5ldCBVc2UgQ2FzZSBTdGF0ZW1lbnRzOiBMaW5rIEFnZ3JlZ2F0aW9uDQoN ClN0YXRlbWVudDoNCkxpbmsgQWdncmVnYXRpb24NCkRpc2N1c3Npb246DQpJIHVzZWQgdGhlIHRl cm0g4oCcbGluayBhZ2dyZWdhdGlvbuKAnSB3aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhhdCBpdCBp cyBhIHJlc2VydmVkIHdvcmQgaW4gdGhpcyBjb250ZXh0LCBzbyBJIG5lZWQgdG8gZmlndXJlIG91 dCB3aGF0IHRoZSBjb3JyZWN0IHRlcm0gaXMuIFRoZSB1c2UgY2FzZSBpcyB0aGF0IHRoZSB1c2Vy IGhhcyBhIGhpZ2ggYmFuZHdpZHRoIHN0cmVhbSBzdWNoIGFzIHZpZGVvIGJ1dCB0aGVyZSBpcyBu byBzaW5nbGUgbmV0d29yayBsaW5rIGJldHdlZW4gdGFsa2VyIGFuZCBsaXN0ZW5lciB3aGljaCBo YXMgYXZhaWxhYmxlIGJhbmR3aWR0aCAoZm9yIHdoYXRldmVyIHJlYXNvbikgYW5kIHRoZSBxdWVz dGlvbiBpcyBjYW4gRGV0TmV0IOKAnHNlYW1sZXNzbHnigJ0gc3BsaXQgdGhlIHN0cmVhbSBhbmQg c2VuZCBwYXJ0cyBvZiBpdCBhY3Jvc3MgZGlmZmVyZW50IHBhdGhzIHRvIHRoZSBsaXN0ZW5lci4g SXQgc2VlbWVkIGxpa2UgdGhlIGZlZWwgb2YgdGhlIHJvb20gd2FzIHRoYXQgd2Ugc2hvdWxkbuKA mXQgYmUgaW52b2x2ZWQgaW4gZG9pbmcgdGhpcywgaG93ZXZlciBpdCB3YXMgYnJvdWdodCB1cCB0 aGF0IHRoaXMgZnVuY3Rpb24gY291bGQgYmUgaW1wbGVtZW50ZWQgaW4gYSBzaW1pbGFyIHdheSBh cyBwYWNrZXQgcmVwbGljYXRpb24gYW5kIGRlbGV0aW9uLCBleGNlcHQgdGhhdCB0aGUgcGFja2V0 IHNlcXVlbmNlIG51bWJlcnMgYXJlIG5vdCBkdXBsaWNhdGVzIHNvIHRoZXkgd291bGQgYmUgYWNj ZXB0ZWQgYW5kIGl0IG1pZ2h0IOKAnGp1c3Qgd29ya+KAnS4gSXQgc291bmRzIHRvIG1lIGxpa2Ug aXQgbWlnaHQgYmUgYSB1c2VmdWwgdGhpbmcgdG8ga2VlcCBpbiB0aGVyZSBzaW5jZSBpdCBkb2Vz buKAmXQgc2VlbSBsaWtlIGl0IHdvdWxkIGJlIHRoYXQgaGFyZCwgYnV0IHBlcmhhcHMgdGhpcyBp cyBhIERldE5ldCDigJxmdXR1cmUgZmVhdHVyZeKAnSB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0byBh ZGRyZXNzIG5vdyBhcyBsb25nIGFzIHdlIGRvbuKAmXQgZG8gYW55dGhpbmcgdGhhdCB3b3VsZCBw cmVjbHVkZSBkZXZlbG9waW5nIGl0IGxhdGVyLg0KDQo= --_000_D332B04B4BFB1nfinnciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7Ij4NCjxkaXY+RXRoYW4sPC9k aXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Eb27igJl0IGxvc2UgdGhpcyB1c2UgY2FzZS4g Jm5ic3A7V2hldGhlciBpdCBpcyBhIHByb2JsZW0gZm9yIERldE5ldCBpcyBhbiBvcGVuIHF1ZXN0 aW9uLiAmbmJzcDtXaGF0IHlvdXIgcHJvYmxlbSBhbmQgdGhlIOKAnFBhY2tldCBSZXBsaWNhdGlv biBhbmQgRGVsZXRpb24gKFBSRCnigJ0gKG9yIFNlYW1sZXNzIFJlZHVuZGFuY3kpIGhhdmUgaW4g Y29tbW9uIGlzIHRoYXQgdGhleSBjYW4gYm90aCBiZSBzb2x2ZWQgYnkgYSBzZXF1ZW5jZSBudW1i ZXIgaW4gZXZlcnkNCiBwYWNrZXQuICZuYnNwO0J1dCwgdGhlcmUgYXJlIGRpZmZlcmVuY2VzLjwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+UFJEOiAmbmJzcDsgJm5ic3A7RHVwbGljYXRl IGV2ZXJ5IHBhY2tldCBpbiBhIHNpbmdsZSBzdHJlYW0uICZuYnNwO1NlbmQgb24gdHdvIHBhdGhz LiAmbmJzcDtEZWxldGUgdGhlIGR1cGxpY2F0ZXMuICZuYnNwO1NlcXVlbmNlIG51bWJlcnMgYXJl IGVzc2VudGlhbCB0byBpZGVudGlmeSBkdXBsaWNhdGUgcGFja2V0cy4gJm5ic3A7UmVzdG9yaW5n IHBhY2tldCBvcmRlciBpcyBhbiBvcHRpb24sIGJ1dCBtYW55IGFyZSByZWx1Y3RhbnQgdG8gbWFr ZSB0aGlzIGFuIG9iamVjdGl2ZS48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PllvdXJz OiAmbmJzcDtTcGxpdCBhIHNpbmdsZSBzdHJlYW0sIHNlbmRpbmcgc29tZSBwYWNrZXRzIG9uIG9u ZSBwYXRoLCBhbmQgb3RoZXIgcGFja2V0cyBvbiBhbm90aGVyIHBhdGguICZuYnNwO0JyaW5nIHRo ZW0gYmFjayB0b2dldGhlci4gJm5ic3A7U2VxdWVuY2UgbnVtYmVycyBhcmUgbmVlZGVkIG9ubHkg aWYgcmVzdG9yaW5nIHBhY2tldCBvcmRlci48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2 Pk5vcm1hbGx5LCB0b2RheSwgd2hlbiBvbmUgaGFzIG11bHRpcGxlIGxpbmtzIGJldHdlZW4gdHdv IGRldmljZXMsIG9uZSB0cmllcyB2ZXJ5IGhhcmQgdG8gZW5zdXJlIHRoYXQgYW55IGdpdmVuIGZs b3cgaXMgYWxsIHB1dCBvbiBvbmUgb2YgdGhlIGxpbmtzLCBpbiBvcmRlciB0byBtaW5pbWl6ZSBv dXQtb2Ytb3JkZXIgZGVsaXZlcnkuICZuYnNwOyhVc2luZyBtdWx0aXBsZSBsaW5rcyBmb3Igb25l IHN0cmVhbSBnZW5lcmFsbHkgc2h1ZmZsZXMgcGFja2V0cy4pDQogJm5ic3A7T2YgY291cnNlLCB0 aGlzIGlzIGV4YWN0bHkgd2hhdCB5b3XigJlyZSB0cnlpbmcgdG8gZml4LiAmbmJzcDtUZWxsIG1l IOKAlCBkbyB0aGUgcGFja2V0cyBuZWVkIHRvIGJlIGRlbGl2ZXJlZCBpbiBvcmRlcj88L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PklNTywgdGhlIHByb2JsZW0geW914oCZcmUgYnJpbmdp bmcgdXAgaXMgaW1wb3J0YW50LCBidXQgaXMgb25seSByZWxhdGVkIHRvIHRoZSBEZXROZXQgcHJv YmxlbSBieSBoYXZpbmcgYSB1c2VyICh2aWRlbyBzdHVkaW8pIHRoYXQgbmVlZHMgc29sdXRpb25z IHRvIGJvdGggcHJvYmxlbXMuPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj7igJQgTm9y bTwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElP TiI+DQo8ZGl2IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpOyBmb250LXNpemU6MTFwdDsgdGV4 dC1hbGlnbjpsZWZ0OyBjb2xvcjpibGFjazsgQk9SREVSLUJPVFRPTTogbWVkaXVtIG5vbmU7IEJP UkRFUi1MRUZUOiBtZWRpdW0gbm9uZTsgUEFERElORy1CT1RUT006IDBpbjsgUEFERElORy1MRUZU OiAwaW47IFBBRERJTkctUklHSFQ6IDBpbjsgQk9SREVSLVRPUDogI2I1YzRkZiAxcHQgc29saWQ7 IEJPUkRFUi1SSUdIVDogbWVkaXVtIG5vbmU7IFBBRERJTkctVE9QOiAzcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkZyb206IDwvc3Bhbj5kZXRuZXQgJmx0OzxhIGhyZWY9Im1h aWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZyI+ZGV0bmV0LWJvdW5jZXNAaWV0Zi5vcmc8L2E+ Jmd0OyBvbiBiZWhhbGYgb2YgJnF1b3Q7R3Jvc3NtYW4sIEV0aGFuIEEuJnF1b3Q7ICZsdDs8YSBo cmVmPSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSI+ZWFncm9zQGRvbGJ5LmNvbTwvYT4mZ3Q7PGJy Pg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5UaHVyc2RheSwg QXByaWwgNywgMjAxNiBhdCAxMzo0NCBQTTxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5UbzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5vcmciPmRl dG5ldEBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRAaWV0Zi5v cmciPmRldG5ldEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0 OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj5bRGV0bmV0XSBEZXROZXQgVXNlIENhc2UgU3RhdGVtZW50 czogTGluayBBZ2dyZWdhdGlvbjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIGlkPSJNQUNfT1VUTE9PS19BVFRSSUJVVElPTl9CTE9DS1FVT1RFIiBzdHlsZT0iQk9S REVSLUxFRlQ6ICNiNWM0ZGYgNSBzb2xpZDsgUEFERElORzowIDAgMCA1OyBNQVJHSU46MCAwIDAg NTsiPg0KPGRpdj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IEV4 Y2hhbmdlIFNlcnZlciI+DQo8IS0tIGNvbnZlcnRlZCBmcm9tIHJ0ZiAtLT48c3R5bGU+PCEtLSAu RW1haWxRdW90ZSB7IG1hcmdpbi1sZWZ0OiAxcHQ7IHBhZGRpbmctbGVmdDogNHB0OyBib3JkZXIt bGVmdDogIzgwMDAwMCAycHggc29saWQ7IH0gLS0+PC9zdHlsZT4NCjxkaXY+PGZvbnQgZmFjZT0i Q2FsaWJyaSIgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMXB0OyI+DQo8ZGl2PlN0 YXRlbWVudDo8L2Rpdj4NCjxkaXY+TGluayBBZ2dyZWdhdGlvbjwvZGl2Pg0KPGRpdj5EaXNjdXNz aW9uOjwvZGl2Pg0KPGRpdj5JIHVzZWQgdGhlIHRlcm0g4oCcbGluayBhZ2dyZWdhdGlvbuKAnSB3 aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhhdCBpdCBpcyBhIHJlc2VydmVkIHdvcmQgaW4gdGhpcyBj b250ZXh0LCBzbyBJIG5lZWQgdG8gZmlndXJlIG91dCB3aGF0IHRoZSBjb3JyZWN0IHRlcm0gaXMu IFRoZSB1c2UgY2FzZSBpcyB0aGF0IHRoZSB1c2VyIGhhcyBhIGhpZ2ggYmFuZHdpZHRoIHN0cmVh bSBzdWNoIGFzIHZpZGVvIGJ1dCB0aGVyZSBpcyBubyBzaW5nbGUgbmV0d29yaw0KIGxpbmsgYmV0 d2VlbiB0YWxrZXIgYW5kIGxpc3RlbmVyIHdoaWNoIGhhcyBhdmFpbGFibGUgYmFuZHdpZHRoIChm b3Igd2hhdGV2ZXIgcmVhc29uKSBhbmQgdGhlIHF1ZXN0aW9uIGlzIGNhbiBEZXROZXQg4oCcc2Vh bWxlc3NseeKAnSBzcGxpdCB0aGUgc3RyZWFtIGFuZCBzZW5kIHBhcnRzIG9mIGl0IGFjcm9zcyBk aWZmZXJlbnQgcGF0aHMgdG8gdGhlIGxpc3RlbmVyLiBJdCBzZWVtZWQgbGlrZSB0aGUgZmVlbCBv ZiB0aGUgcm9vbSB3YXMgdGhhdCB3ZSBzaG91bGRu4oCZdA0KIGJlIGludm9sdmVkIGluIGRvaW5n IHRoaXMsIGhvd2V2ZXIgaXQgd2FzIGJyb3VnaHQgdXAgdGhhdCB0aGlzIGZ1bmN0aW9uIGNvdWxk IGJlIGltcGxlbWVudGVkIGluIGEgc2ltaWxhciB3YXkgYXMgcGFja2V0IHJlcGxpY2F0aW9uIGFu ZCBkZWxldGlvbiwgZXhjZXB0IHRoYXQgdGhlIHBhY2tldCBzZXF1ZW5jZSBudW1iZXJzIGFyZSBu b3QgZHVwbGljYXRlcyBzbyB0aGV5IHdvdWxkIGJlIGFjY2VwdGVkIGFuZCBpdCBtaWdodCDigJxq dXN0IHdvcmvigJ0uDQogSXQgc291bmRzIHRvIG1lIGxpa2UgaXQgbWlnaHQgYmUgYSB1c2VmdWwg dGhpbmcgdG8ga2VlcCBpbiB0aGVyZSBzaW5jZSBpdCBkb2VzbuKAmXQgc2VlbSBsaWtlIGl0IHdv dWxkIGJlIHRoYXQgaGFyZCwgYnV0IHBlcmhhcHMgdGhpcyBpcyBhIERldE5ldCDigJxmdXR1cmUg ZmVhdHVyZeKAnSB0aGF0IHdlIGRvbuKAmXQgaGF2ZSB0byBhZGRyZXNzIG5vdyBhcyBsb25nIGFz IHdlIGRvbuKAmXQgZG8gYW55dGhpbmcgdGhhdCB3b3VsZCBwcmVjbHVkZSBkZXZlbG9waW5nDQog aXQgbGF0ZXIuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_D332B04B4BFB1nfinnciscocom_-- From nobody Tue Apr 12 14:31:12 2016 Return-Path: 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 B769412EADE for ; Tue, 12 Apr 2016 14:31:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Z3q7GAvZQh7o for ; Tue, 12 Apr 2016 14:31:08 -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 C84D412EAD9 for ; Tue, 12 Apr 2016 14:31:08 -0700 (PDT) Received: from pps.filterd (m0000439.ppops.net [127.0.0.1]) by mx0a-000fd501.pphosted.com (8.16.0.11/8.16.0.11) with SMTP id u3CLQEDQ011101; Tue, 12 Apr 2016 14:31:07 -0700 Received: from dlb-xmrpw01.dolby.net (dcd-outbound.dolby.com [67.216.182.43]) by mx0a-000fd501.pphosted.com with ESMTP id 227004bxrp-1 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Tue, 12 Apr 2016 14:31:07 -0700 Received: from DLB-XCHPW04.dolby.net (10.233.7.4) by DLB-XMRPW01.dolby.net (10.213.22.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Tue, 12 Apr 2016 14:31:06 -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.1076.9; Tue, 12 Apr 2016 14:31:04 -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.1076.000; Tue, 12 Apr 2016 14:31:04 -0700 From: "Grossman, Ethan A." To: "Norman Finn (nfinn)" , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Link Aggregation Thread-Index: AQHRlQHVZXnFE6jkgUWcIcVkY84gA5+G2ksQ Date: Tue, 12 Apr 2016 21:31:04 +0000 Message-ID: References: In-Reply-To: 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: multipart/alternative; boundary="_000_faf1f6f9f64c48da88658310f46ddc3dDLBXCHPW03dolbynet_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-04-12_11:, , signatures=0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 21:31:10 -0000 --_000_faf1f6f9f64c48da88658310f46ddc3dDLBXCHPW03dolbynet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIE5vcm0sDQpZZXMgdGhlIGlkZWEgaXMgdGhhdCB0aGUgcGFja2V0cyB3b3VsZCBiZSBk ZWxpdmVyZWQgdG8gdGhlIGVuZCB1c2VyIGluIHRoZWlyIG9yaWdpbmFsIG9yZGVyLCBzbyBzZXF1 ZW5jZSBudW1iZXJzIHdvdWxkIGJlIHJlcXVpcmVkLiBJIHRoaW5rIG9mIHRoaXMgYXMgYSDigJxu aWNlIHRvIGhhdmXigJ0gZmVhdHVyZSwgbm90IGEgY29yZSByZXF1aXJlbWVudC4gT3IgbWF5YmUg YSDigJxEZXROZXQgMi4w4oCdIGZlYXR1cmUuIEkgd291bGQgcHJvYmFibHkgaGF2ZSBqdXN0IGRy b3BwZWQgaXQgZXhjZXB0IGZvciBQYXNjYWwgaGF2aW5nIG5vdGVkIHRoZSBvdmVybGFwIHdpdGgg UFJEIHdoaWNoIG1hZGUgaXQgc291bmQg4oCcbm90IGhhcmTigJ0uDQpFdGhhbi4NCg0KRnJvbTog Tm9ybWFuIEZpbm4gKG5maW5uKSBbbWFpbHRvOm5maW5uQGNpc2NvLmNvbV0NClNlbnQ6IFR1ZXNk YXksIEFwcmlsIDEyLCAyMDE2IDI6MjUgUE0NClRvOiBHcm9zc21hbiwgRXRoYW4gQS47IGRldG5l dEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtEZXRuZXRdIERldE5ldCBVc2UgQ2FzZSBTdGF0ZW1l bnRzOiBMaW5rIEFnZ3JlZ2F0aW9uDQoNCkV0aGFuLA0KDQpEb27igJl0IGxvc2UgdGhpcyB1c2Ug Y2FzZS4gIFdoZXRoZXIgaXQgaXMgYSBwcm9ibGVtIGZvciBEZXROZXQgaXMgYW4gb3BlbiBxdWVz dGlvbi4gIFdoYXQgeW91ciBwcm9ibGVtIGFuZCB0aGUg4oCcUGFja2V0IFJlcGxpY2F0aW9uIGFu ZCBEZWxldGlvbiAoUFJEKeKAnSAob3IgU2VhbWxlc3MgUmVkdW5kYW5jeSkgaGF2ZSBpbiBjb21t b24gaXMgdGhhdCB0aGV5IGNhbiBib3RoIGJlIHNvbHZlZCBieSBhIHNlcXVlbmNlIG51bWJlciBp biBldmVyeSBwYWNrZXQuICBCdXQsIHRoZXJlIGFyZSBkaWZmZXJlbmNlcy4NCg0KUFJEOiAgICBE dXBsaWNhdGUgZXZlcnkgcGFja2V0IGluIGEgc2luZ2xlIHN0cmVhbS4gIFNlbmQgb24gdHdvIHBh dGhzLiAgRGVsZXRlIHRoZSBkdXBsaWNhdGVzLiAgU2VxdWVuY2UgbnVtYmVycyBhcmUgZXNzZW50 aWFsIHRvIGlkZW50aWZ5IGR1cGxpY2F0ZSBwYWNrZXRzLiAgUmVzdG9yaW5nIHBhY2tldCBvcmRl ciBpcyBhbiBvcHRpb24sIGJ1dCBtYW55IGFyZSByZWx1Y3RhbnQgdG8gbWFrZSB0aGlzIGFuIG9i amVjdGl2ZS4NCg0KWW91cnM6ICBTcGxpdCBhIHNpbmdsZSBzdHJlYW0sIHNlbmRpbmcgc29tZSBw YWNrZXRzIG9uIG9uZSBwYXRoLCBhbmQgb3RoZXIgcGFja2V0cyBvbiBhbm90aGVyIHBhdGguICBC cmluZyB0aGVtIGJhY2sgdG9nZXRoZXIuICBTZXF1ZW5jZSBudW1iZXJzIGFyZSBuZWVkZWQgb25s eSBpZiByZXN0b3JpbmcgcGFja2V0IG9yZGVyLg0KDQpOb3JtYWxseSwgdG9kYXksIHdoZW4gb25l IGhhcyBtdWx0aXBsZSBsaW5rcyBiZXR3ZWVuIHR3byBkZXZpY2VzLCBvbmUgdHJpZXMgdmVyeSBo YXJkIHRvIGVuc3VyZSB0aGF0IGFueSBnaXZlbiBmbG93IGlzIGFsbCBwdXQgb24gb25lIG9mIHRo ZSBsaW5rcywgaW4gb3JkZXIgdG8gbWluaW1pemUgb3V0LW9mLW9yZGVyIGRlbGl2ZXJ5LiAgKFVz aW5nIG11bHRpcGxlIGxpbmtzIGZvciBvbmUgc3RyZWFtIGdlbmVyYWxseSBzaHVmZmxlcyBwYWNr ZXRzLikgIE9mIGNvdXJzZSwgdGhpcyBpcyBleGFjdGx5IHdoYXQgeW914oCZcmUgdHJ5aW5nIHRv IGZpeC4gIFRlbGwgbWUg4oCUIGRvIHRoZSBwYWNrZXRzIG5lZWQgdG8gYmUgZGVsaXZlcmVkIGlu IG9yZGVyPw0KDQpJTU8sIHRoZSBwcm9ibGVtIHlvdeKAmXJlIGJyaW5naW5nIHVwIGlzIGltcG9y dGFudCwgYnV0IGlzIG9ubHkgcmVsYXRlZCB0byB0aGUgRGV0TmV0IHByb2JsZW0gYnkgaGF2aW5n IGEgdXNlciAodmlkZW8gc3R1ZGlvKSB0aGF0IG5lZWRzIHNvbHV0aW9ucyB0byBib3RoIHByb2Js ZW1zLg0KDQrigJQgTm9ybQ0KDQpGcm9tOiBkZXRuZXQgPGRldG5ldC1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpkZXRuZXQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiAiR3Jvc3NtYW4s IEV0aGFuIEEuIiA8ZWFncm9zQGRvbGJ5LmNvbTxtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbT4+DQpE YXRlOiBUaHVyc2RheSwgQXByaWwgNywgMjAxNiBhdCAxMzo0NCBQTQ0KVG86ICJkZXRuZXRAaWV0 Zi5vcmc8bWFpbHRvOmRldG5ldEBpZXRmLm9yZz4iIDxkZXRuZXRAaWV0Zi5vcmc8bWFpbHRvOmRl dG5ldEBpZXRmLm9yZz4+DQpTdWJqZWN0OiBbRGV0bmV0XSBEZXROZXQgVXNlIENhc2UgU3RhdGVt ZW50czogTGluayBBZ2dyZWdhdGlvbg0KDQpTdGF0ZW1lbnQ6DQpMaW5rIEFnZ3JlZ2F0aW9uDQpE aXNjdXNzaW9uOg0KSSB1c2VkIHRoZSB0ZXJtIOKAnGxpbmsgYWdncmVnYXRpb27igJ0gd2l0aG91 dCB1bmRlcnN0YW5kaW5nIHRoYXQgaXQgaXMgYSByZXNlcnZlZCB3b3JkIGluIHRoaXMgY29udGV4 dCwgc28gSSBuZWVkIHRvIGZpZ3VyZSBvdXQgd2hhdCB0aGUgY29ycmVjdCB0ZXJtIGlzLiBUaGUg dXNlIGNhc2UgaXMgdGhhdCB0aGUgdXNlciBoYXMgYSBoaWdoIGJhbmR3aWR0aCBzdHJlYW0gc3Vj aCBhcyB2aWRlbyBidXQgdGhlcmUgaXMgbm8gc2luZ2xlIG5ldHdvcmsgbGluayBiZXR3ZWVuIHRh bGtlciBhbmQgbGlzdGVuZXIgd2hpY2ggaGFzIGF2YWlsYWJsZSBiYW5kd2lkdGggKGZvciB3aGF0 ZXZlciByZWFzb24pIGFuZCB0aGUgcXVlc3Rpb24gaXMgY2FuIERldE5ldCDigJxzZWFtbGVzc2x5 4oCdIHNwbGl0IHRoZSBzdHJlYW0gYW5kIHNlbmQgcGFydHMgb2YgaXQgYWNyb3NzIGRpZmZlcmVu dCBwYXRocyB0byB0aGUgbGlzdGVuZXIuIEl0IHNlZW1lZCBsaWtlIHRoZSBmZWVsIG9mIHRoZSBy b29tIHdhcyB0aGF0IHdlIHNob3VsZG7igJl0IGJlIGludm9sdmVkIGluIGRvaW5nIHRoaXMsIGhv d2V2ZXIgaXQgd2FzIGJyb3VnaHQgdXAgdGhhdCB0aGlzIGZ1bmN0aW9uIGNvdWxkIGJlIGltcGxl bWVudGVkIGluIGEgc2ltaWxhciB3YXkgYXMgcGFja2V0IHJlcGxpY2F0aW9uIGFuZCBkZWxldGlv biwgZXhjZXB0IHRoYXQgdGhlIHBhY2tldCBzZXF1ZW5jZSBudW1iZXJzIGFyZSBub3QgZHVwbGlj YXRlcyBzbyB0aGV5IHdvdWxkIGJlIGFjY2VwdGVkIGFuZCBpdCBtaWdodCDigJxqdXN0IHdvcmvi gJ0uIEl0IHNvdW5kcyB0byBtZSBsaWtlIGl0IG1pZ2h0IGJlIGEgdXNlZnVsIHRoaW5nIHRvIGtl ZXAgaW4gdGhlcmUgc2luY2UgaXQgZG9lc27igJl0IHNlZW0gbGlrZSBpdCB3b3VsZCBiZSB0aGF0 IGhhcmQsIGJ1dCBwZXJoYXBzIHRoaXMgaXMgYSBEZXROZXQg4oCcZnV0dXJlIGZlYXR1cmXigJ0g dGhhdCB3ZSBkb27igJl0IGhhdmUgdG8gYWRkcmVzcyBub3cgYXMgbG9uZyBhcyB3ZSBkb27igJl0 IGRvIGFueXRoaW5nIHRoYXQgd291bGQgcHJlY2x1ZGUgZGV2ZWxvcGluZyBpdCBsYXRlci4NCg0K --_000_faf1f6f9f64c48da88658310f46ddc3dDLBXCHPW03dolbynet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0KcC5lbWFpbHF1b3RlLCBsaS5lbWFpbHF1b3RlLCBkaXYu ZW1haWxxdW90ZQ0KCXttc28tc3R5bGUtbmFtZTplbWFpbHF1b3RlOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MS4wcHQ7DQoJYm9yZGVyOm5vbmU7DQoJcGFkZGluZzowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpz cGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0 IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3MgTm9ybSwNCjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5ZZXMgdGhlIGlkZWEgaXMgdGhhdCB0aGUgcGFja2V0 cyB3b3VsZCBiZSBkZWxpdmVyZWQgdG8gdGhlIGVuZCB1c2VyIGluIHRoZWlyIG9yaWdpbmFsIG9y ZGVyLCBzbyBzZXF1ZW5jZSBudW1iZXJzIHdvdWxkIGJlIHJlcXVpcmVkLiBJIHRoaW5rIG9mIHRo aXMgYXMgYSDigJxuaWNlDQogdG8gaGF2ZeKAnSBmZWF0dXJlLCBub3QgYSBjb3JlIHJlcXVpcmVt ZW50LiBPciBtYXliZSBhIOKAnERldE5ldCAyLjDigJ0gZmVhdHVyZS4gSSB3b3VsZCBwcm9iYWJs eSBoYXZlIGp1c3QgZHJvcHBlZCBpdCBleGNlcHQgZm9yIFBhc2NhbCBoYXZpbmcgbm90ZWQgdGhl IG92ZXJsYXAgd2l0aCBQUkQgd2hpY2ggbWFkZSBpdCBzb3VuZCDigJxub3QgaGFyZOKAnS4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5FdGhhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBO b3JtYW4gRmlubiAobmZpbm4pIFttYWlsdG86bmZpbm5AY2lzY28uY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFR1ZXNkYXksIEFwcmlsIDEyLCAyMDE2IDI6MjUgUE08YnI+DQo8Yj5Ubzo8L2I+IEdy b3NzbWFuLCBFdGhhbiBBLjsgZGV0bmV0QGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbRGV0bmV0XSBEZXROZXQgVXNlIENhc2UgU3RhdGVtZW50czogTGluayBBZ2dyZWdhdGlvbjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFj ayI+RXRoYW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29u c29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5Eb27igJl0IGxvc2UgdGhpcyB1c2Ug Y2FzZS4gJm5ic3A7V2hldGhlciBpdCBpcyBhIHByb2JsZW0gZm9yIERldE5ldCBpcyBhbiBvcGVu IHF1ZXN0aW9uLiAmbmJzcDtXaGF0IHlvdXIgcHJvYmxlbSBhbmQgdGhlIOKAnFBhY2tldCBSZXBs aWNhdGlvbiBhbmQgRGVsZXRpb24gKFBSRCnigJ0gKG9yIFNlYW1sZXNzIFJlZHVuZGFuY3kpDQog aGF2ZSBpbiBjb21tb24gaXMgdGhhdCB0aGV5IGNhbiBib3RoIGJlIHNvbHZlZCBieSBhIHNlcXVl bmNlIG51bWJlciBpbiBldmVyeSBwYWNrZXQuICZuYnNwO0J1dCwgdGhlcmUgYXJlIGRpZmZlcmVu Y2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+UFJEOiAmbmJzcDsgJm5ic3A7RHVwbGljYXRl IGV2ZXJ5IHBhY2tldCBpbiBhIHNpbmdsZSBzdHJlYW0uICZuYnNwO1NlbmQgb24gdHdvIHBhdGhz LiAmbmJzcDtEZWxldGUgdGhlIGR1cGxpY2F0ZXMuICZuYnNwO1NlcXVlbmNlIG51bWJlcnMgYXJl IGVzc2VudGlhbCB0byBpZGVudGlmeSBkdXBsaWNhdGUgcGFja2V0cy4gJm5ic3A7UmVzdG9yaW5n IHBhY2tldA0KIG9yZGVyIGlzIGFuIG9wdGlvbiwgYnV0IG1hbnkgYXJlIHJlbHVjdGFudCB0byBt YWtlIHRoaXMgYW4gb2JqZWN0aXZlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2Zv bnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+WW91cnM6ICZu YnNwO1NwbGl0IGEgc2luZ2xlIHN0cmVhbSwgc2VuZGluZyBzb21lIHBhY2tldHMgb24gb25lIHBh dGgsIGFuZCBvdGhlciBwYWNrZXRzIG9uIGFub3RoZXIgcGF0aC4gJm5ic3A7QnJpbmcgdGhlbSBi YWNrIHRvZ2V0aGVyLiAmbmJzcDtTZXF1ZW5jZSBudW1iZXJzIGFyZSBuZWVkZWQgb25seSBpZiBy ZXN0b3JpbmcNCiBwYWNrZXQgb3JkZXIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2NvbG9yOmJsYWNrIj5Ob3JtYWxs eSwgdG9kYXksIHdoZW4gb25lIGhhcyBtdWx0aXBsZSBsaW5rcyBiZXR3ZWVuIHR3byBkZXZpY2Vz LCBvbmUgdHJpZXMgdmVyeSBoYXJkIHRvIGVuc3VyZSB0aGF0IGFueSBnaXZlbiBmbG93IGlzIGFs bCBwdXQgb24gb25lIG9mIHRoZSBsaW5rcywgaW4gb3JkZXIgdG8gbWluaW1pemUgb3V0LW9mLW9y ZGVyDQogZGVsaXZlcnkuICZuYnNwOyhVc2luZyBtdWx0aXBsZSBsaW5rcyBmb3Igb25lIHN0cmVh bSBnZW5lcmFsbHkgc2h1ZmZsZXMgcGFja2V0cy4pICZuYnNwO09mIGNvdXJzZSwgdGhpcyBpcyBl eGFjdGx5IHdoYXQgeW914oCZcmUgdHJ5aW5nIHRvIGZpeC4gJm5ic3A7VGVsbCBtZSDigJQgZG8g dGhlIHBhY2tldHMgbmVlZCB0byBiZSBkZWxpdmVyZWQgaW4gb3JkZXI/PG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6Q29uc29sYXM7Y29sb3I6YmxhY2siPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFzO2Nv bG9yOmJsYWNrIj5JTU8sIHRoZSBwcm9ibGVtIHlvdeKAmXJlIGJyaW5naW5nIHVwIGlzIGltcG9y dGFudCwgYnV0IGlzIG9ubHkgcmVsYXRlZCB0byB0aGUgRGV0TmV0IHByb2JsZW0gYnkgaGF2aW5n IGEgdXNlciAodmlkZW8gc3R1ZGlvKSB0aGF0IG5lZWRzIHNvbHV0aW9ucyB0byBib3RoIHByb2Js ZW1zLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OkNvbnNvbGFz O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+4oCUIE5vcm08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+ZGV0bmV0ICZsdDs8YSBocmVmPSJtYWlsdG86ZGV0bmV0LWJvdW5jZXNAaWV0Zi5v cmciPmRldG5ldC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxmIG9mICZxdW90O0dy b3NzbWFuLCBFdGhhbiBBLiZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVhZ3Jvc0Bkb2xieS5j b20iPmVhZ3Jvc0Bkb2xieS5jb208L2E+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwg QXByaWwgNywgMjAxNiBhdCAxMzo0NCBQTTxicj4NCjxiPlRvOiA8L2I+JnF1b3Q7PGEgaHJlZj0i bWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmRldG5ldEBpZXRmLm9yZyI+ZGV0bmV0QGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OiA8L2I+W0RldG5ldF0gRGV0TmV0IFVzZSBDYXNlIFN0YXRlbWVudHM6IExp bmsgQWdncmVnYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTpDb25zb2xhcztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0I1 QzRERiA0LjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0O21hcmdpbi1sZWZ0OjMuNzVwdDtt YXJnaW4tcmlnaHQ6MGluIiBpZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSI+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPlN0YXRlbWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkxpbmsgQWdncmVnYXRpb248bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkRpc2N1c3Npb246PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JIHVzZWQgdGhlIHRlcm0g4oCcbGluayBhZ2dyZWdh dGlvbuKAnSB3aXRob3V0IHVuZGVyc3RhbmRpbmcgdGhhdCBpdCBpcyBhIHJlc2VydmVkIHdvcmQg aW4gdGhpcyBjb250ZXh0LCBzbyBJIG5lZWQgdG8gZmlndXJlIG91dCB3aGF0IHRoZSBjb3JyZWN0 IHRlcm0gaXMuIFRoZSB1c2UNCiBjYXNlIGlzIHRoYXQgdGhlIHVzZXIgaGFzIGEgaGlnaCBiYW5k d2lkdGggc3RyZWFtIHN1Y2ggYXMgdmlkZW8gYnV0IHRoZXJlIGlzIG5vIHNpbmdsZSBuZXR3b3Jr IGxpbmsgYmV0d2VlbiB0YWxrZXIgYW5kIGxpc3RlbmVyIHdoaWNoIGhhcyBhdmFpbGFibGUgYmFu ZHdpZHRoIChmb3Igd2hhdGV2ZXIgcmVhc29uKSBhbmQgdGhlIHF1ZXN0aW9uIGlzIGNhbiBEZXRO ZXQg4oCcc2VhbWxlc3NseeKAnSBzcGxpdCB0aGUgc3RyZWFtIGFuZCBzZW5kIHBhcnRzDQogb2Yg aXQgYWNyb3NzIGRpZmZlcmVudCBwYXRocyB0byB0aGUgbGlzdGVuZXIuIEl0IHNlZW1lZCBsaWtl IHRoZSBmZWVsIG9mIHRoZSByb29tIHdhcyB0aGF0IHdlIHNob3VsZG7igJl0IGJlIGludm9sdmVk IGluIGRvaW5nIHRoaXMsIGhvd2V2ZXIgaXQgd2FzIGJyb3VnaHQgdXAgdGhhdCB0aGlzIGZ1bmN0 aW9uIGNvdWxkIGJlIGltcGxlbWVudGVkIGluIGEgc2ltaWxhciB3YXkgYXMgcGFja2V0IHJlcGxp Y2F0aW9uIGFuZCBkZWxldGlvbiwgZXhjZXB0DQogdGhhdCB0aGUgcGFja2V0IHNlcXVlbmNlIG51 bWJlcnMgYXJlIG5vdCBkdXBsaWNhdGVzIHNvIHRoZXkgd291bGQgYmUgYWNjZXB0ZWQgYW5kIGl0 IG1pZ2h0IOKAnGp1c3Qgd29ya+KAnS4gSXQgc291bmRzIHRvIG1lIGxpa2UgaXQgbWlnaHQgYmUg YSB1c2VmdWwgdGhpbmcgdG8ga2VlcCBpbiB0aGVyZSBzaW5jZSBpdCBkb2VzbuKAmXQgc2VlbSBs aWtlIGl0IHdvdWxkIGJlIHRoYXQgaGFyZCwgYnV0IHBlcmhhcHMgdGhpcyBpcyBhIERldE5ldCDi gJxmdXR1cmUNCiBmZWF0dXJl4oCdIHRoYXQgd2UgZG9u4oCZdCBoYXZlIHRvIGFkZHJlc3Mgbm93 IGFzIGxvbmcgYXMgd2UgZG9u4oCZdCBkbyBhbnl0aGluZyB0aGF0IHdvdWxkIHByZWNsdWRlIGRl dmVsb3BpbmcgaXQgbGF0ZXIuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_faf1f6f9f64c48da88658310f46ddc3dDLBXCHPW03dolbynet_-- From nobody Tue Apr 12 14:47:38 2016 Return-Path: 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 A6BC312EB15 for ; Tue, 12 Apr 2016 14:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 12OER0lyl59t for ; Tue, 12 Apr 2016 14:47:34 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6813212DF0D for ; Tue, 12 Apr 2016 14:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11002; q=dns/txt; s=iport; t=1460497654; x=1461707254; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=N33doftslUC3JXS9YKrsr/bYuHVUmEQdTBaMzdNpuyo=; b=dfBqswZpaxE+hJZ/GTDwdQA7kFJ8ufCDVHP6XLglR5FBQgmmIz8VGapp e8nXFnwLJ4XIkDUfsUejlaqIb/yVP2C7Lc8ulU6mLLVCGECZHe6M8nRSy kd2hJe2NmZIDfjd3CwU6yku2gGDd1Kjroj/+tjbn/c7pKQ6EXqBez6KXp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BcAgDIbA1X/4kNJK1UCoJrTFNuD7V1h?= =?us-ascii?q?HMBDYF2FwEKhSJKAoE7OBQBAQEBAQEBZSeEQQEBAQQBAQEqQQsQAgEIEQMBAig?= =?us-ascii?q?HJwsUCQgCBA4FG4gNDsIOAQEBAQEBAQEBAQEBAQEBAQEBAQEBEQSGIYF1glaED?= =?us-ascii?q?QhKDYJ+gisFmAgBiGmFI4Fnh3aFM48mAR4BAUKDZ2yISIE9AQEB?= X-IronPort-AV: E=Sophos; i="5.24,476,1454976000"; d="scan'208,217"; a="92863191" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Apr 2016 21:47:30 +0000 Received: from XCH-RCD-019.cisco.com (xch-rcd-019.cisco.com [173.37.102.29]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u3CLlUDn001671 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Apr 2016 21:47:30 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-019.cisco.com (173.37.102.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 12 Apr 2016 16:47:29 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Tue, 12 Apr 2016 16:47:29 -0500 From: "Pascal Thubert (pthubert)" To: "Norman Finn (nfinn)" Thread-Topic: [Detnet] DetNet Use Case Statements: Link Aggregation Thread-Index: AQHRlQHVZXnFE6jkgUWcIcVkY84gA5+G3869 Date: Tue, 12 Apr 2016 21:47:29 +0000 Message-ID: <9F63985E-9F35-4B9B-B188-AC027DF55B75@cisco.com> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_9F63985E9F354B9BB188AC027DF55B75ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Grossman, Ethan A." , "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Apr 2016 21:47:36 -0000 --_000_9F63985E9F354B9BB188AC027DF55B75ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Norm This is also related to 1) low jitter, and 2) to network defragmentation. Regarding 1) If the use case requires low jitter, then in-order delivery is= , well, in order. The re-sequencing is a side effect of that need. Industri= al control networks want that. In TSCH networks, different packets of a sam= e flow will take different paths, not necessarily to distribute load but al= so to route around interference. Then, about 2) being able to split a stream in micro streams is one cool wa= y to avoid ending up with the fragmentation problem. This is the case where= all the paths are used to some percentage such that an additional flow can= not fit, whereas the overall bandwidth is present. Defragmentation needs to= take to allow the new flow in. This means moving existing flows and it hur= ts. My read is that some detnet properties are more or less difficult to achiev= e depending on the technology and the position in the network. We can descr= ibe them all, but not necessarily expect them from all devices. Regards, Pascal Le 12 avr. 2016 ? 14:25, Norman Finn (nfinn) > a ?crit : Ethan, Don't lose this use case. Whether it is a problem for DetNet is an open qu= estion. What your problem and the "Packet Replication and Deletion (PRD)" = (or Seamless Redundancy) have in common is that they can both be solved by = a sequence number in every packet. But, there are differences. PRD: Duplicate every packet in a single stream. Send on two paths. Del= ete the duplicates. Sequence numbers are essential to identify duplicate p= ackets. Restoring packet order is an option, but many are reluctant to mak= e this an objective. Yours: Split a single stream, sending some packets on one path, and other = packets on another path. Bring them back together. Sequence numbers are n= eeded only if restoring packet order. Normally, today, when one has multiple links between two devices, one tries= very hard to ensure that any given flow is all put on one of the links, in= order to minimize out-of-order delivery. (Using multiple links for one st= ream generally shuffles packets.) Of course, this is exactly what you're t= rying to fix. Tell me - do the packets need to be delivered in order? IMO, the problem you're bringing up is important, but is only related to th= e DetNet problem by having a user (video studio) that needs solutions to bo= th problems. - Norm From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Thursday, April 7, 2016 at 13:44 PM To: "detnet@ietf.org" > Subject: [Detnet] DetNet Use Case Statements: Link Aggregation Statement: Link Aggregation Discussion: I used the term "link aggregation" without understanding that it is a reser= ved word in this context, so I need to figure out what the correct term is.= The use case is that the user has a high bandwidth stream such as video bu= t there is no single network link between talker and listener which has ava= ilable bandwidth (for whatever reason) and the question is can DetNet "seam= lessly" split the stream and send parts of it across different paths to the= listener. It seemed like the feel of the room was that we shouldn't be inv= olved in doing this, however it was brought up that this function could be = implemented in a similar way as packet replication and deletion, except tha= t the packet sequence numbers are not duplicates so they would be accepted = and it might "just work". It sounds to me like it might be a useful thing t= o keep in there since it doesn't seem like it would be that hard, but perha= ps this is a DetNet "future feature" that we don't have to address now as l= ong as we don't do anything that would preclude developing it later. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_9F63985E9F354B9BB188AC027DF55B75ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hello Norm

This is also related to 1) low jitter, and 2= ) to network defragmentation.

Regarding 1) If the use case requires low ji= tter, then in-order delivery is, well, in order. The re-sequencing is a sid= e effect of that need. Industrial control networks want that. In TSCH netwo= rks, different packets of a same flow will take different paths, not necessarily to distribute load but also to = route around interference.

Then, about 2) being able to split a stream = in micro streams is one cool way to avoid ending up with the fragmentation = problem. This is the case where all the paths are used to some percentage s= uch that an additional flow cannot fit, whereas the overall bandwidth is present. Defragmentation needs to ta= ke to allow the new flow in. This means moving existing flows and it hurts.=

My read is that some detnet properties are more or less difficult to achiev= e depending on the technology and the position in the network. We can descr= ibe them all, but not necessarily expect them from all devices.

Regards,

Pascal

Le 12 avr. 2016 à 14:25, Norman Finn (nfinn) <nfinn@cisco.com> a écrit :

Ethan,

Don’t lose this use case.  Whether it is a problem for DetN= et is an open question.  What your problem and the “Packet Repli= cation and Deletion (PRD)” (or Seamless Redundancy) have in common is= that they can both be solved by a sequence number in every packet.  But, there are differences.

PRD:    Duplicate every packet in a single stream.  Sen= d on two paths.  Delete the duplicates.  Sequence numbers are ess= ential to identify duplicate packets.  Restoring packet order is an op= tion, but many are reluctant to make this an objective.

Yours:  Split a single stream, sending some packets on one path, = and other packets on another path.  Bring them back together.  Se= quence numbers are needed only if restoring packet order.

Normally, today, when one has multiple links between two devices, one = tries very hard to ensure that any given flow is all put on one of the link= s, in order to minimize out-of-order delivery.  (Using multiple links = for one stream generally shuffles packets.)  Of course, this is exactly what you’re trying to fix.  Te= ll me — do the packets need to be delivered in order?

IMO, the problem you’re bringing up is important, but is only re= lated to the DetNet problem by having a user (video studio) that needs solu= tions to both problems.

— Norm

From: detnet <detnet-bounces@ietf.org> on behalf of "= ;Grossman, Ethan A." <eagros@do= lby.com>
Date: Thursday, April 7, 2016 at 13= :44 PM
To: "detnet@ietf.org" <= detnet@ietf.org>
Subject: [Detnet] DetNet Use Case S= tatements: Link Aggregation

Statement:
Link Aggregation
Discussion:
I used the term “link aggregation” without understanding t= hat it is a reserved word in this context, so I need to figure out what the= correct term is. The use case is that the user has a high bandwidth stream= such as video but there is no single network link between talker and listener which has available bandwidth (for whatev= er reason) and the question is can DetNet “seamlessly” split th= e stream and send parts of it across different paths to the listener. It se= emed like the feel of the room was that we shouldn’t be involved in doing this, however it was brought up that this function co= uld be implemented in a similar way as packet replication and deletion, exc= ept that the packet sequence numbers are not duplicates so they would be ac= cepted and it might “just work”. It sounds to me like it might be a useful thing to keep in there since it = doesn’t seem like it would be that hard, but perhaps this is a DetNet= “future feature” that we don’t have to address now as lo= ng as we don’t do anything that would preclude developing it later.
 
_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.= ietf.org/mailman/listinfo/detnet
--_000_9F63985E9F354B9BB188AC027DF55B75ciscocom_-- From nobody Wed Apr 13 20:23:05 2016 Return-Path: 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 296F712DD5E for ; Wed, 13 Apr 2016 20:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 G6F0VuaLot6D for ; Wed, 13 Apr 2016 20:23:01 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAFCC12DE51 for ; Wed, 13 Apr 2016 20:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8485; q=dns/txt; s=iport; t=1460604179; x=1461813779; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=g2t6CH/P3UrJZPLeLQnU2UAn9ZeyJs7MQcYgTGsPk9M=; b=cUiM388/XLUYngJGzS/FAuzudSBIPiJb7o15bL83j4PuTBd+3EVTG6z6 yTgxKm/ocTSmVupEqd7/EYoPBchhIQWVptYIml1TRA/Vae0hSouIdSOkU g0Hz2zHdjyo+bhxHwf/1qQ3sNy+z7p69RYE5g+AyLM9fgBRAtljBj1/Ox Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A7BQA2DA9X/4gNJK1egmtNU30GtTOGc?= =?us-ascii?q?oYOAoE3OxEBAQEBAQEBZSeEQQEBAQQtXAIBCBEEAQEoBzIUCQgBAQQBEggXiAr?= =?us-ascii?q?DIwEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLhHWFIAWHb4cTiQYBjgWPF48mA?= =?us-ascii?q?TYsg2dsiHx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,482,1454976000"; d="scan'208,217";a="261261519" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 03:22:59 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u3E3Mwud020681 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 03:22:59 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 22:22:58 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 22:22:57 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Plug-And-Play Thread-Index: AdGRCNkIZirEvHznTV28oe5F8truEgE8zlXA Date: Thu, 14 Apr 2016 03:22:56 +0000 Deferred-Delivery: Thu, 14 Apr 2016 03:22:18 +0000 Message-ID: <51ff0ecfb507493faaa8bc93bd77fc2d@XCH-RCD-001.cisco.com> References: <179217173638485a976bafbcf1f3a7c5@DLB-XCHPW03.dolby.net> In-Reply-To: <179217173638485a976bafbcf1f3a7c5@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.232.50] Content-Type: multipart/alternative; boundary="_000_51ff0ecfb507493faaa8bc93bd77fc2dXCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:23:04 -0000 --_000_51ff0ecfb507493faaa8bc93bd77fc2dXCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ethan: In my world, the use case is a failing device replacement. What the use cas= e tells me is that there should be a way to provision the new device to tha= t it replaces the old device with a minimum of hassle, which means that it = could fit in the predecessor's shoes without having to recompute the paths = and/or reinstall them. Certainly this places also a requirement on the new device, which is expect= ed to have the same capabilities as the predecessor, or more. But that much= is acceptable. This also places requirements like that the semantics used = in the detnet signaling are universal enough so that there meaning is under= standable by the replacement. Eg, can the replacement use a label that was = locally significant to the predecessor? Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 14:00 To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play Statement: Plug-And-Play (new device, replace device) Discussion: Ethan: There are enough use cases and available technology for doing this, = and enough "feel of the room" that I claim it is in scope. It won't always = be possible (or useful) in every use case, so it must a feature that can be= selectively included in a given DetNet implementation. There is some disti= nction between introducing a "new" device into the network and replacing a = removed/failed device. However since a replacement for a failed device migh= t not be "exactly" the same as the original device (e.g. different firmware= revision) then some renegotiation seems inevitable (though maybe not as mu= ch as for a new device). --_000_51ff0ecfb507493faaa8bc93bd77fc2dXCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ethan:

 

In my world, the use case is a failin= g device replacement. What the use case tells me is that there should be a = way to provision the new device to that it replaces the old device with a minimum of hassle, which means that it could fit in = the predecessor’s shoes without having to recompute the paths and/or = reinstall them.

 

Certainly this places also a requirem= ent on the new device, which is expected to have the same capabilities as t= he predecessor, or more. But that much is acceptable. This also places requirements like that the semantics used in the detnet s= ignaling are universal enough so that there meaning is understandable by th= e replacement. Eg, can the replacement use a label that was locally signifi= cant to the predecessor?

 

Cheers,=

 <= /p>

Pascal<= /p>

 

From: detnet [mailto:detnet-bounces@= ietf.org] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 14:00
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play

 

Statement:

Plug-And-Play (new device, replace device)

Discussion:

Ethan: There are enough use cases and available tec= hnology for doing this, and enough “feel of the room” that I cl= aim it is in scope. It won’t always be possible (or useful) in every use case, so it must a feature that can be selectively included i= n a given DetNet implementation. There is some distinction between introduc= ing a “new” device into the network and replacing a removed/fai= led device. However since a replacement for a failed device might not be “exactly” the same as the origina= l device (e.g. different firmware revision) then some renegotiation seems i= nevitable (though maybe not as much as for a new device).

 

--_000_51ff0ecfb507493faaa8bc93bd77fc2dXCHRCD001ciscocom_-- From nobody Wed Apr 13 20:31:34 2016 Return-Path: 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 3CD7B12DEC2 for ; Wed, 13 Apr 2016 20:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 5fzGojN_DMYE for ; Wed, 13 Apr 2016 20:31:30 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BBFA12DEB7 for ; Wed, 13 Apr 2016 20:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12851; q=dns/txt; s=iport; t=1460604690; x=1461814290; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nCAGoDuNpJAzv9oviIP1NfO9PYT9dPSNaYcKoex0SyI=; b=gKBLbIxrsUvdLaUJd7Gu2VkS7zStm3+B941+FetnBQXvcLVgv8szdJLV 0+iRtvpvGH7jFMZiXxS+48ZbikxOtpOXjugmspmfVZuL5xwVOGzNW2gco L04U+5qlwtHqSSGWVcTUNhUlN0jr9wwCVmvKMmrSX3RW5CLKGQyNcdlDg k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgA8Dg9X/4YNJK1egmtNU30GtTOEc?= =?us-ascii?q?wENgXGGDgKBNzgUAQEBAQEBAWUnhEEBAQEELVwCAQgRAQMBASgHMhQDBggBAQQ?= =?us-ascii?q?BEgiIIcMkAQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYhhEuEdYUgBYdvhxOJBgGOB?= =?us-ascii?q?YFuh3aFM48mAR4BAUKDZ2yIfH4BAQE?= X-IronPort-AV: E=Sophos; i="5.24,482,1454976000"; d="scan'208,217"; a="91251789" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Apr 2016 03:31:28 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3E3VSWx032156 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 03:31:28 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 22:31:28 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 22:31:28 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time Thread-Index: AdGRD/0EQIWJvj4vQxOXPJJbjPfNYAE7PFFw Date: Thu, 14 Apr 2016 03:30:59 +0000 Deferred-Delivery: Thu, 14 Apr 2016 03:30:17 +0000 Message-ID: <35a35a285e2446a28a68f612342cf5d7@XCH-RCD-001.cisco.com> References: <1ee9e258c48d41f7926e7d0fbea92435@DLB-XCHPW03.dolby.net> In-Reply-To: <1ee9e258c48d41f7926e7d0fbea92435@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.232.50] Content-Type: multipart/alternative; boundary="_000_35a35a285e2446a28a68f612342cf5d7XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start) Time X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:31:32 -0000 --_000_35a35a285e2446a28a68f612342cf5d7XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ethan: Do I read this as something like the stream is pre-established and has a tr= ansmission opportunity of a minimum guaranteed burst at least every 3 seco= nds? Point is, it is hard to guarantee the establishment time of the detnet= path if that establishment may imply defragmenting the network, or droppin= g existing lower priority connections in use cases where that is acceptable= . If that's so, this means that there is a need for unused CBR circuits, mayb= e many of them, and if many is really many, that means that we must be able= to use the resources for non-critical traffic when the critical traffic is= not present. A variation of that would be to send critical traffic over a = path that is shorter than the reserved one when the reserved traffic over t= hat shorter path is not present. This is an item that we could describe as an optional feature in the archit= ecture. Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 13:57 To: detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-st= art) Time Here's the text from the Use Case draft as a reminder: Some audio systems installed in public environments (airports, hospitals) have unique requirements with regards to health, sa= fety and fire concerns. One such requirement is a maximum of 3 seconds for = a system to respond to an emergency detection and begin sending appropriate w= arning signals and alarms without human intervention. For this requirement to= be met, the system must support a bounded and acceptable time from a notifi= cation signal to specific stream establishment. For further details see [ISO7= 240-16] From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: Thursday, April 07, 2016 5:28 PM To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Stream Start-up (or re-start)= Time Statement: Stream Start-up (or re-start) Time Discussion: It was noted that systems that really need a timely replacement for a faile= d device would probably use other methods (e.g. redundancy) rather than dep= ending on a bounded stream start-up time. I don't have a sense of the answ= er to this one. --_000_35a35a285e2446a28a68f612342cf5d7XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ethan:

 

Do I read this as something like the = stream is pre-established and has a transmission opportunity of  a min= imum guaranteed burst at least every 3 seconds? Point is, it is hard to guarantee the establishment time of the detnet path if t= hat establishment may imply defragmenting the network, or dropping existing= lower priority connections in use cases where that is acceptable.

 

If that’s so, this means that t= here is a need for unused CBR circuits, maybe many of them, and if many is = really many, that means that we must be able to use the resources for non-critical traffic when the critical traffic is not pr= esent. A variation of that would be to send critical traffic over a path th= at is shorter than the reserved one when the reserved traffic over that sho= rter path is not present.

 

This is an item that we could describ= e as an optional feature in the architecture.

 

Cheers,=

 <= /p>

Pascal<= /p>

 

From: detnet [mailto:detnet-bounces@= ietf.org] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 13:57
To: detnet@ietf.org
Subject: Re: [Detnet] DetNet Use Case Statements: Stream Start-up (o= r re-start) Time

 

Here’s the text from the Use Ca= se draft as a reminder:

Some audio systems installed in publi= c environments (airports, hospitals)

      &= nbsp;           &nbs= p;     have unique requirements with regards to health,= safety and fire concerns.

      &= nbsp;           &nbs= p;     One such requirement is a maximum of 3 seconds f= or a system to respond to an

      &= nbsp;            &nb= sp;    emergency detection and begin sending appropriat= e warning signals and alarms

      &= nbsp;           &nbs= p;     without human intervention. For this requirement= to be met, the system must

      &= nbsp;           &nbs= p;     support a bounded and acceptable time from a not= ification signal to specific

      &= nbsp;           &nbs= p;     stream establishment. For further details see [I= SO7240-16]

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan A.
Sent: Thursday, April 07, 2016 5:28 PM
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Stream Start-up (or re= -start) Time

 

Statement:

Stream Start-up (or re-start) Time

Discussion:

It was noted that systems that really need a timely= replacement for a failed device would probably use other methods (e.g. red= undancy) rather than depending on a bounded stream start-up time.  I don’t have a sense of the answer to this one.=   

 

--_000_35a35a285e2446a28a68f612342cf5d7XCHRCD001ciscocom_-- From nobody Wed Apr 13 20:34:03 2016 Return-Path: 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 8638112DD72 for ; Wed, 13 Apr 2016 20:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 NzQ-UZp5H5GF for ; Wed, 13 Apr 2016 20:34:00 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F29E512DF87 for ; Wed, 13 Apr 2016 20:33:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7275; q=dns/txt; s=iport; t=1460604840; x=1461814440; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4AUNubKo3ddhQx8mxfi5aUTDNvwuUmjVsU1dIcAx3bA=; b=aT6d4Ur4lBtC09v1MShPZ9pdNrU5hSGtMCIIwlgeFm3mkuZHeTdcOa+Z q82dqeGP0ie5jwq+8bljt06YPaxRMtnKSkrx5aaJWov2DPABGCGNykL9r lpynnP8xko6OywuUDSc74Z8J8AVUUPUoWOtuFQHmPx32LOaaUVeJfzUNn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgBMDg9X/5RdJa1egmtNU30GtTOEc?= =?us-ascii?q?wENgXGGDgKBNzgUAQEBAQEBAWUnhEEBAQEELVwCAQgRBAEBKAcyFAkIAQEEARI?= =?us-ascii?q?IiCHDJAEBAQEBAQEBAQEBAQEBAQEBAQEBARWGIYRLhHWFIAWYCAGIaYUcjxePJ?= =?us-ascii?q?gEeAQFCg2dsiHx+AQEB?= X-IronPort-AV: E=Sophos;i="5.24,482,1454976000"; d="scan'208,217";a="261078984" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 03:33:59 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u3E3XwFZ011772 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 03:33:58 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 22:33:58 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 22:33:58 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: =?Windows-1252?Q?DetNet_Use_Case_Statements:_Latency_matching_=96_single-?= =?Windows-1252?Q?_or_bi-directional?= Thread-Index: AdGRDoe5uN0yG/UaRCyeY8Qx+bksUAE72+eg Date: Thu, 14 Apr 2016 03:33:57 +0000 Deferred-Delivery: Thu, 14 Apr 2016 03:33:50 +0000 Message-ID: <9138b60de842496e82097996aee175e1@XCH-RCD-001.cisco.com> References: <7516b05e9b4948d69ebfcd8d664ee414@DLB-XCHPW03.dolby.net> In-Reply-To: <7516b05e9b4948d69ebfcd8d664ee414@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.232.50] Content-Type: multipart/alternative; boundary="_000_9138b60de842496e82097996aee175e1XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] =?windows-1252?q?DetNet_Use_Case_Statements=3A_Latency_m?= =?windows-1252?q?atching_=96_single-_or_bi-directional?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:34:02 -0000 --_000_9138b60de842496e82097996aee175e1XCHRCD001ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Ethan: This seems related to the in-order packets delivery item. A tight latency control can be useful to maintain that order. But doesn=92t= this imply Time triggered operations? We could also add that feature of voluntary latency addition, probably asso= ciated to jitter elimination. Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 13:52 To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Latency matching =96 single- = or bi-directional Statement: Latency matching =96 single- or bi-directional Discussion: This came up because at least one use cases mentioned a need for multiple o= utgoing paths (or the send and return paths) to have matched latencies. I s= uppose one way to do this is to specify a latency which is the minimum, and= the add delay to the other path(s) to match it =96 but does this happen at= the DetNet level or is it something the application layer would do? --_000_9138b60de842496e82097996aee175e1XCHRCD001ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Ethan:

 

This seems related to the in-order pa= ckets delivery item.

 

A tight latency control can be useful= to maintain that order. But doesn=92t this imply Time triggered operations= ?

 

We could also add that feature of vol= untary latency addition, probably associated to jitter elimination.

 

Cheers,

 

Pascal

 

From: detnet [mailto:detnet-bounces@= ietf.org] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 13:52
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Latency matching =96 s= ingle- or bi-directional

 

Statement:

Latency matching =96 single- or bi-directional=

Discussion:

This came up because at least one use cases mention= ed a need for multiple outgoing paths (or the send and return paths) to hav= e matched latencies. I suppose one way to do this is to specify a latency which is the minimum, and the add delay to the oth= er path(s) to match it =96 but does this happen at the DetNet level or is i= t something the application layer would do?

 

--_000_9138b60de842496e82097996aee175e1XCHRCD001ciscocom_-- From nobody Wed Apr 13 20:36:04 2016 Return-Path: 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 416BA12E1BD for ; Wed, 13 Apr 2016 20:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.516 X-Spam-Level: X-Spam-Status: No, score=-15.516 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 JXVidhsmW5tc for ; Wed, 13 Apr 2016 20:36:00 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C29C512E27D for ; Wed, 13 Apr 2016 20:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6344; q=dns/txt; s=iport; t=1460604959; x=1461814559; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=GeU9zmw9ZaKOR9R3VcIbDfqxTGpWRwFTQ/naFj7qNNA=; b=KDhDHWtSoDqpKA1CEHzjHPU8nu76phe38HB0NZvwQSYViY1no7uBcpW4 LkcjxynOy0+hWjxQbnGFp0CNrBWD02j95paWumNrifLI+pA8o6A/PgVJV WF5oXFbDvUqeoy3amLAsIe1lSSFlQ9NZ0onmKsjjnjB6cv2G2Y02oZ/zQ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAgAFDw9X/5NdJa1egmtNU30GtTOEc?= =?us-ascii?q?wENgXGGDgKBNzgUAQEBAQEBAWUnhEEBAQEELVwCAQgRBAEBKAcyFAkIAQEEARI?= =?us-ascii?q?IE4gOwx0BAQEBAQEBAQEBAQEBAQEBAQEBAQEVhiGES4R1hSAFmAgBjgWPF48mA?= =?us-ascii?q?R4BAUKDZ2yIfH4BAQE?= X-IronPort-AV: E=Sophos;i="5.24,482,1454976000"; d="scan'208,217";a="259705622" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Apr 2016 03:35:59 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u3E3ZwAd006461 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Apr 2016 03:35:58 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 13 Apr 2016 22:35:58 -0500 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 13 Apr 2016 22:35:58 -0500 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption Thread-Index: AdGRDBv0VuW29UCmQxSgR0D546MjQwE8kI4g Date: Thu, 14 Apr 2016 03:34:57 +0000 Deferred-Delivery: Thu, 14 Apr 2016 03:34:53 +0000 Message-ID: References: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> In-Reply-To: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.82.232.50] Content-Type: multipart/alternative; boundary="_000_b231b4e52ef84ad892467a14fb8681e0XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 03:36:03 -0000 --_000_b231b4e52ef84ad892467a14fb8681e0XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Ethan I'm not sure this is (related to) a detnet function? It seems to be another= component of a solution. Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 13:33 To: detnet@ietf.org Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encrypt= ion Statement: Link Authentication/Encryption Discussion: This statement came from a section of the Pro Audio use case (which was wri= tten by my co-author :-) and I haven't looked into the details of whether t= here is anything implied in that statement that would require us to do anyt= hing other than our current strategy of "don't break security". Perhaps Mr.= Gunther will enlighten us... :- ) --_000_b231b4e52ef84ad892467a14fb8681e0XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Ethan

 

I’m not sure this is (related t= o) a detnet function? It seems to be another component of a solution.<= /o:p>

 

Cheers,

 

Pascal

 

From: detnet [mailto:detnet-bounces@= ietf.org] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 13:33
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/= Encryption

 

Statement:

Link Authentication/Encryption

Discussion:

This statement came from a section of the Pro Audio= use case (which was written by my co-author :-) and I haven’t looked= into the details of whether there is anything implied in that statement that would require us to do anything other than our curr= ent strategy of “don’t break security”. Perhaps Mr. Gunth= er will enlighten us… :- )

 

 

--_000_b231b4e52ef84ad892467a14fb8681e0XCHRCD001ciscocom_-- From nobody Thu Apr 14 00:24:38 2016 Return-Path: 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 E500B12B037 for ; Thu, 14 Apr 2016 00:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 haTcY_39u5ep for ; Thu, 14 Apr 2016 00:24:35 -0700 (PDT) Received: from lizzard.sbs.de (lizzard.sbs.de [194.138.37.39]) (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 63CF012B00E for ; Thu, 14 Apr 2016 00:24:34 -0700 (PDT) Received: from mail2.sbs.de (mail2.sbs.de [192.129.41.66]) by lizzard.sbs.de (8.15.2/8.15.2) with ESMTPS id u3E7OWSc008965 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for ; Thu, 14 Apr 2016 09:24:32 +0200 Received: from DEFTHW99ERGMSX.ww902.siemens.net (defthw99ergmsx.ww902.siemens.net [139.22.70.132]) by mail2.sbs.de (8.15.2/8.15.2) with ESMTPS id u3E7OTj6006552 (version=TLSv1 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 14 Apr 2016 09:24:32 +0200 Received: from DEFTHW99EK3MSX.ww902.siemens.net ([169.254.4.234]) by DEFTHW99ERGMSX.ww902.siemens.net ([139.22.70.132]) with mapi id 14.03.0279.002; Thu, 14 Apr 2016 09:24:30 +0200 From: "Schmitt, Juergen" To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Plug-And-Play Thread-Index: AdGRCNkIZirEvHznTV28oe5F8truEgE8zlXAAAhoyfA= Date: Thu, 14 Apr 2016 07:24:30 +0000 Message-ID: <4E310F17BD503646BD155B102AF875E81E18873C@DEFTHW99EK3MSX.ww902.siemens.net> References: <179217173638485a976bafbcf1f3a7c5@DLB-XCHPW03.dolby.net> <51ff0ecfb507493faaa8bc93bd77fc2d@XCH-RCD-001.cisco.com> In-Reply-To: <51ff0ecfb507493faaa8bc93bd77fc2d@XCH-RCD-001.cisco.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.41] Content-Type: multipart/alternative; boundary="_000_4E310F17BD503646BD155B102AF875E81E18873CDEFTHW99EK3MSXw_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2016 07:24:38 -0000 --_000_4E310F17BD503646BD155B102AF875E81E18873CDEFTHW99EK3MSXw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Pascal, I'm not sure this is the only use case for new devices. Especially in indus= try publish-subcribe is a widespread communication pattern. Not to be able = to add additional subscribers (such as a measurement system) at runtime wou= ld be a major issue. Juergen Von: detnet [mailto:detnet-bounces@ietf.org] Im Auftrag von Pascal Thubert = (pthubert) Gesendet: Donnerstag, 14. April 2016 05:23 An: Grossman, Ethan A.; detnet@ietf.org Betreff: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play Hello Ethan: In my world, the use case is a failing device replacement. What the use cas= e tells me is that there should be a way to provision the new device to tha= t it replaces the old device with a minimum of hassle, which means that it = could fit in the predecessor's shoes without having to recompute the paths = and/or reinstall them. Certainly this places also a requirement on the new device, which is expect= ed to have the same capabilities as the predecessor, or more. But that much= is acceptable. This also places requirements like that the semantics used = in the detnet signaling are universal enough so that there meaning is under= standable by the replacement. Eg, can the replacement use a label that was = locally significant to the predecessor? Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 14:00 To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play Statement: Plug-And-Play (new device, replace device) Discussion: Ethan: There are enough use cases and available technology for doing this, = and enough "feel of the room" that I claim it is in scope. It won't always = be possible (or useful) in every use case, so it must a feature that can be= selectively included in a given DetNet implementation. There is some disti= nction between introducing a "new" device into the network and replacing a = removed/failed device. However since a replacement for a failed device migh= t not be "exactly" the same as the original device (e.g. different firmware= revision) then some renegotiation seems inevitable (though maybe not as mu= ch as for a new device). --_000_4E310F17BD503646BD155B102AF875E81E18873CDEFTHW99EK3MSXw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Pascal,

 

I’m not sure this is = the only use case for new devices. Especially in industry publish-subcribe = is a widespread communication pattern. Not to be able to add additional subscribers (such as a measurement system) at runtime would be a major iss= ue.

 

Juergen

 

Von: detnet [mailto:detnet-bounces@ietf.org] Im Auftrag von Pascal Thubert (pthubert)
Gesendet: Donnerstag, 14. April 2016 05:23
An: Grossman, Ethan A.; detnet@ietf.org
Betreff: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play=

 

Hello Ethan:

 <= /p>

In my world, the use case= is a failing device replacement. What the use case tells me is that there = should be a way to provision the new device to that it replaces the old device with a minimum of hassle, which means that it could fit in = the predecessor’s shoes without having to recompute the paths and/or = reinstall them.

 <= /p>

Certainly this places als= o a requirement on the new device, which is expected to have the same capab= ilities as the predecessor, or more. But that much is acceptable. This also places requirements like that the semantics used in the detnet s= ignaling are universal enough so that there meaning is understandable by th= e replacement. Eg, can the replacement use a label that was locally signifi= cant to the predecessor?

 <= /p>

Cheers,<= /o:p>

 

Pascal

 <= /p>

From: detnet= [mailto:detnet-bounces@ietf.org= ] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 14:00
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play

 

Statement:

Plug-And-Play (new device, replace devi= ce)

Discussion:

Ethan: There are enough use cases and a= vailable technology for doing this, and enough “feel of the room̶= 1; that I claim it is in scope. It won’t always be possible (or usefu= l) in every use case, so it must a feature that can be selectively included i= n a given DetNet implementation. There is some distinction between introduc= ing a “new” device into the network and replacing a removed/fai= led device. However since a replacement for a failed device might not be “exactly” the same as the origina= l device (e.g. different firmware revision) then some renegotiation seems i= nevitable (though maybe not as much as for a new device).

 

--_000_4E310F17BD503646BD155B102AF875E81E18873CDEFTHW99EK3MSXw_-- From nobody Mon Apr 18 06:55:56 2016 Return-Path: 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 75B3212D816 for ; Mon, 18 Apr 2016 06:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 dp3n9YCsHhTo for ; Mon, 18 Apr 2016 06:55:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37C9412D87A for ; Mon, 18 Apr 2016 06:55:51 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-16-5714e764ecc7 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 45.76.26920.467E4175; Mon, 18 Apr 2016 15:55:49 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.234]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 15:55:48 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Pascal Thubert (pthubert)" , "Norman Finn (nfinn)" Thread-Topic: [Detnet] DetNet Use Case Statements: Link Aggregation Thread-Index: AQHRlQHVZXnFE6jkgUWcIcVkY84gA5+G3869gAjPGCA= Date: Mon, 18 Apr 2016 13:55:47 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EF9F914@ESESSMB103.ericsson.se> References: <9F63985E-9F35-4B9B-B188-AC027DF55B75@cisco.com> In-Reply-To: <9F63985E-9F35-4B9B-B188-AC027DF55B75@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F914ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrAIsWRmVeSWpSXmKPExsUyM2K7om7qc5Fwg44nXBa/P81mseh7vJ3d 4n2vqcWMKe8YHVg8pvzeyOqxb+IRFo8lS34yBTBHcdmkpOZklqUW6dslcGU83veRueDNXcaK u0u7mRsYzxxk7GLk5JAQMJFY928LlC0mceHeerYuRi4OIYEjjBL3nrawQDhLGCVeLvrMBlLF JuAq8bnjIZgtIhAvcfTqMyYQm1kgSOLKlW9gtrCAk8TNs7OYIWqcJc52Xoaqt5K4efAU2DYW AVWJfS27wOK8Ar4SH/adBIsLAc2cPP0cmM0pYCsxY9dOdhCbEei676fWQO0Sl7j1ZD4TxNUC Ekv2nGeGsEUlXj7+x9rFyAFkK0lM25oGUZ4vcX7xOVaIVYISJ2c+YZnAKDoLyaRZSMpmISmD iOtJ3Jg6hQ3C1pZYtvA1M4StKzHj3yEWZPEFjOyrGEWLU4uLc9ONjPVSizKTi4vz8/TyUks2 MQLj8eCW37o7GFe/djzEKMDBqMTDm8AuEi7EmlhWXJl7iFGCg1lJhLfpKVCINyWxsiq1KD++ qDQntfgQozQHi5I4b07kvzAhgfTEktTs1NSC1CKYLBMHp1QD4/T/00+zZt2Lsy3ad1KR0fHb 2kWVWgeWz+LnPnijuPxcZPY7LYOP+vN6Ig/k/CvLmqSR52b9+mklS81W477zCyb03t452Z3P 9VxKrPR7nbCEX35LZ23bcTJS5tOei27a13vCzlmdNmRudfcM64+V3JDft/Dql8x1l3WUbrtX 8K5a2ObyyTpOX4mlOCPRUIu5qDgRADYDIR3DAgAA Archived-At: Cc: "Grossman, Ethan A." , "detnet@ietf.org" Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:55:54 -0000 --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F914ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Some more aspects related to PRD (Packet Replication and Deletion) and LA (= Link Aggregation) for the "in-order delivery" context. I am sure there are scenarios where in-order delivery is a must, but not fo= r all the scenarios. Let's call as "merging node", where PRD or LA merges the detnet packets arr= iving over different paths. Let's assume that the merging node is somewhere in the middle of the detnet network. The same fun= ction can be used for both PRD and LA to ensure the correct packet order. The different paths from the source to the mergin= g node have different delays and jitters. The path with the longest delay will determine packet delivery. B / \ Source--A D--E--Sink \ / C NodeA: replication point (PRD) or distribution point (LA) NodeD: merging node pathA-B-D: fast path pathA-C-D: slow path Let's assume we lost a packet over path A-B-D and analyze the impact. Adding a function (to "D") to ensure in-order delivery may have some negati= ve impacts: - it needs more resources: on the merging node as you need buffering. - it can increase delay: if on nodeD we have sent packetN-1 to nodeE than w= e expect to receive packetN. However if we receive packetN+1, than we have to wait until packetN is received. I= f packetN is lost than we may have to wait until we are sure it is lost (determine waiting time depends on traffic cha= racteristics and network scenario, just as an example "waiting-time=3Dmaximum delay differences of used paths from source= -to-nodeD"). Therefore forwarding of packetN+1 could be delayed. - it can increase flow burstyness: Due to the additional waiting of packetN= +1 (and maybe also N+2, etc.) burstyness and jitter is increased. - it can increase loss: if we do not wait long enough (e.g., miscalculation= ) and have sent already packetN+1 towards nodeE when packetN arrives, than it will be dropped otherwise out-of-order = delivery happens. Therefore from networking perspective the optimal place to ensure correct p= acket order is at the endpoint (sink) of the detnet flow. If the endpoint can handle out-of-order delivery, than = we do not need an "put-in-order" function and detnet node implementations become more simple. There are also some net= work scenarios what makes in-order-delivery and the related nodal function obsolete (e.g. CBR source = with 1packet/sec and a network with 100msec max latency). So I agree that we should target in-order delivery as a requirement, but I = would argue to have it as an optional requirement (or DetNet 2.0 as formulated by Ethan). Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Tuesday, April 12, 2016 11:47 PM To: Norman Finn (nfinn) Cc: Grossman, Ethan A.; detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation Hello Norm This is also related to 1) low jitter, and 2) to network defragmentation. Regarding 1) If the use case requires low jitter, then in-order delivery is= , well, in order. The re-sequencing is a side effect of that need. Industri= al control networks want that. In TSCH networks, different packets of a sam= e flow will take different paths, not necessarily to distribute load but al= so to route around interference. Then, about 2) being able to split a stream in micro streams is one cool wa= y to avoid ending up with the fragmentation problem. This is the case where= all the paths are used to some percentage such that an additional flow can= not fit, whereas the overall bandwidth is present. Defragmentation needs to= take to allow the new flow in. This means moving existing flows and it hur= ts. My read is that some detnet properties are more or less difficult to achiev= e depending on the technology and the position in the network. We can descr= ibe them all, but not necessarily expect them from all devices. Regards, Pascal Le 12 avr. 2016 =E0 14:25, Norman Finn (nfinn) > a =E9crit : Ethan, Don't lose this use case. Whether it is a problem for DetNet is an open qu= estion. What your problem and the "Packet Replication and Deletion (PRD)" = (or Seamless Redundancy) have in common is that they can both be solved by = a sequence number in every packet. But, there are differences. PRD: Duplicate every packet in a single stream. Send on two paths. Del= ete the duplicates. Sequence numbers are essential to identify duplicate p= ackets. Restoring packet order is an option, but many are reluctant to mak= e this an objective. Yours: Split a single stream, sending some packets on one path, and other = packets on another path. Bring them back together. Sequence numbers are n= eeded only if restoring packet order. Normally, today, when one has multiple links between two devices, one tries= very hard to ensure that any given flow is all put on one of the links, in= order to minimize out-of-order delivery. (Using multiple links for one st= ream generally shuffles packets.) Of course, this is exactly what you're t= rying to fix. Tell me - do the packets need to be delivered in order? IMO, the problem you're bringing up is important, but is only related to th= e DetNet problem by having a user (video studio) that needs solutions to bo= th problems. - Norm From: detnet > on b= ehalf of "Grossman, Ethan A." > Date: Thursday, April 7, 2016 at 13:44 PM To: "detnet@ietf.org" > Subject: [Detnet] DetNet Use Case Statements: Link Aggregation Statement: Link Aggregation Discussion: I used the term "link aggregation" without understanding that it is a reser= ved word in this context, so I need to figure out what the correct term is.= The use case is that the user has a high bandwidth stream such as video bu= t there is no single network link between talker and listener which has ava= ilable bandwidth (for whatever reason) and the question is can DetNet "seam= lessly" split the stream and send parts of it across different paths to the= listener. It seemed like the feel of the room was that we shouldn't be inv= olved in doing this, however it was brought up that this function could be = implemented in a similar way as packet replication and deletion, except tha= t the packet sequence numbers are not duplicates so they would be accepted = and it might "just work". It sounds to me like it might be a useful thing t= o keep in there since it doesn't seem like it would be that hard, but perha= ps this is a DetNet "future feature" that we don't have to address now as l= ong as we don't do anything that would preclude developing it later. _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F914ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Some more aspects related= to PRD (Packet Replication and Deletion) and LA (Link Aggregation) for the= “in-order delivery” context.

I am sure there are scena= rios where in-order delivery is a must, but not for all the scenarios.

 <= /p>

Let’s call as ̶= 0;merging node”, where PRD or LA merges the detnet packets arriving o= ver different paths. Let’s assume that the

merging node is somewhere= in the middle of the detnet network. The same function can be used for bot= h PRD and LA to ensure

the correct packet order.= The different paths from the source to the merging node have different del= ays and jitters.

The path with the longest= delay will determine packet delivery.

 <= /p>

       &n= bsp;    B

       &n= bsp;   / \

 Source--A   D--E--Sink<= /o:p>

       &n= bsp;   \ /

       &n= bsp;    C

 <= /p>

NodeA: replication point = (PRD) or distribution point (LA)

NodeD: merging node<= /o:p>

pathA-B-D: fast path=

pathA-C-D: slow path=

Let’s assume we los= t a packet over path A-B-D and analyze the impact.

 <= /p>

Adding a function (to = 220;D”) to ensure in-order delivery may have some negative impacts:

- it needs more resources= : on the merging node as you need buffering.

- it can increase delay: = if on nodeD we have sent packetN-1 to nodeE than we expect to receive packe= tN. However

if  we receive packe= tN+1, than we have to wait until packetN is received. If packetN is los= t than we may have to wait

until we are sure it is l= ost (determine waiting time depends on traffic characteristics and network = scenario, just as an

example “waiting-ti= me=3Dmaximum delay differences of used paths from source-to-nodeD”). = Therefore forwarding

of packetN+1 could be= delayed.

- it can increase flow bu= rstyness: Due to the additional waiting of packetN+1 (and maybe also N&= #43;2, etc.) burstyness

and jitter is increased.<= o:p>

- it can increase loss: i= f we do not wait long enough (e.g., miscalculation) and have sent already p= acketN+1 towards

nodeE when packetN arrive= s, than it will be dropped otherwise out-of-order delivery happens.

 <= /p>

Therefore from networking= perspective the optimal place to ensure correct packet order is at the end= point (sink)

of the detnet flow. If th= e endpoint can handle out-of-order delivery, than we do not need an “= put-in-order” function

and detnet node implement= ations become more simple. There are also some network scenarios what makes

in-order-delivery and the= related nodal function obsolete (e.g. CBR source with 1packet/sec and a ne= twork with

100msec max latency).

 <= /p>

So I agree that we should= target in-order delivery as a requirement, but I would argue to have it as= an optional requirement

(or DetNet 2.0 as formula= ted by Ethan).

 <= /p>

Cheers<= /p>

Bala’zs<= /span>

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Tuesday, April 12, 2016 11:47 PM
To: Norman Finn (nfinn)
Cc: Grossman, Ethan A.; detnet@ietf.org
Subject: Re: [Detnet] DetNet Use Case Statements: Link Aggregation

 

Hello Norm

 

This is also related to 1) low jitter, and 2) to net= work defragmentation.

 

Regarding 1) If the use case requires low jitter, th= en in-order delivery is, well, in order. The re-sequencing is a side effect= of that need. Industrial control networks want that. In TSCH networks, dif= ferent packets of a same flow will take different paths, not necessarily to distribute load but also to route= around interference.

 

Then, about 2) being able to split a stream in micro= streams is one cool way to avoid ending up with the fragmentation problem.= This is the case where all the paths are used to some percentage such that= an additional flow cannot fit, whereas the overall bandwidth is present. Defragmentation needs to take to allow t= he new flow in. This means moving existing flows and it hurts.

My read is that some detnet properties are more or less difficult to achiev= e depending on the technology and the position in the network. We can descr= ibe them all, but not necessarily expect them from all devices.<= /p>

 

Regards,

 

Pascal


Le 12 avr. 2016 =E0 14:25, Norman Finn (nfinn) <nfinn@cisco.com> a =E9crit :

Ethan,

 

Don’t lose this use case.  Whether it is = a problem for DetNet is an open question.  What your problem and the &= #8220;Packet Replication and Deletion (PRD)” (or Seamless Redundancy)= have in common is that they can both be solved by a sequence number in every packet.  But, there are differences.

 

PRD:    Duplicate every packet in a single= stream.  Send on two paths.  Delete the duplicates.  Sequen= ce numbers are essential to identify duplicate packets.  Restoring pac= ket order is an option, but many are reluctant to make this an objective.

 

Yours:  Split a single stream, sending some pac= kets on one path, and other packets on another path.  Bring them back = together.  Sequence numbers are needed only if restoring packet order.=

 

Normally, today, when one has multiple links between= two devices, one tries very hard to ensure that any given flow is all put = on one of the links, in order to minimize out-of-order delivery.  (Usi= ng multiple links for one stream generally shuffles packets.)  Of course, this is exactly what you’re tryi= ng to fix.  Tell me — do the packets need to be delivered in ord= er?

 

IMO, the problem you’re bringing up is importa= nt, but is only related to the DetNet problem by having a user (video studi= o) that needs solutions to both problems.

 

— Norm

 

From: detnet <detnet-bounces@ietf.org> on behalf of "Grossman,= Ethan A." <eagros@dolby.com>
Date: Thursday, April 7, 2016 at 13:44 PM
To: "detnet@ietf.org&quo= t; <detnet@ietf.org>
Subject: [Detnet] DetNet Use Case Statements: Link Aggregation<= /o:p>

 

Statement:

Link Aggregation

Discussion:

I used the term “link aggregation= ” without understanding that it is a reserved word in this context, s= o I need to figure out what the correct term is. The use case is that the user has a high bandwidth stream such as video but there is no single = network link between talker and listener which has available bandwidth (for= whatever reason) and the question is can DetNet “seamlessly” s= plit the stream and send parts of it across different paths to the listener. It seemed like the feel of the room was t= hat we shouldn’t be involved in doing this, however it was brought up= that this function could be implemented in a similar way as packet replica= tion and deletion, except that the packet sequence numbers are not duplicates so they would be accepted and it might= “just work”. It sounds to me like it might be a useful thing t= o keep in there since it doesn’t seem like it would be that hard, but= perhaps this is a DetNet “future feature” that we don’t have to address now as long as we don’t do anything that= would preclude developing it later.

 

_______________________________________________
detnet mailing list
detnet@ietf.org
https://www.ietf.o= rg/mailman/listinfo/detnet

--_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F914ESESSMB103erics_-- From nobody Mon Apr 18 06:57:31 2016 Return-Path: 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 C24F212DE19 for ; Mon, 18 Apr 2016 06:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 vSe4p3SZBuaE for ; Mon, 18 Apr 2016 06:57:28 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C6312DDD9 for ; Mon, 18 Apr 2016 06:57:27 -0700 (PDT) X-AuditID: c1b4fb30-f79d86d0000062a1-0d-5714e7c5e09b Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 68.5A.25249.5C7E4175; Mon, 18 Apr 2016 15:57:25 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.234]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 15:56:35 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Pascal Thubert (pthubert)" , "Grossman, Ethan A." , "detnet@ietf.org" Thread-Topic: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption Thread-Index: AQHRlf7HB7C4DyqjkkqfBGq5XhhCYJ+Pop9Q Date: Mon, 18 Apr 2016 13:56:35 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EF9F927@ESESSMB103.ericsson.se> References: <5138314d76cd4e3cb444ab674552f8d4@DLB-XCHPW03.dolby.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F927ESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUyM2J7lO6x5yLhBowWvz/NZrHoe7yd3WLG lHeMDsweU35vZPXYN/EIi8eSJT+ZApijuGxSUnMyy1KL9O0SuDI2/PvOWtDkXrH/Xw97A+Nd +y5GTg4JAROJ50ffsEHYYhIX7q0Hsrk4hASOMEos3bOPHSQhJLCEUeLZLC4Qm03AVeJzx0Ow IhGBFkaJTXOeMXcxcnAIC4RINDabg9SICIRK/N45gR3CNpJY+HQ1C4jNIqAq8Wv/JLBlvAK+ Ek2XXrCAtAoJ1Ev0bmAECXMCjZ+86iJYCSPQPd9PrWECsZkFxCVuPZnPBHGngMSSPeeZIWxR iZeP/7GCjJEQUJKYtjUNojxf4nH/TnaITYISJ2c+YZnAKDILyaRZSMpmISmDiOtJ3Jg6hQ3C 1pZYtvA1M4StKzHj3yEWZPEFjOyrGEWLU4uTctONjPRSizKTi4vz8/TyUks2MQJj7OCW3wY7 GF8+dzzEKMDBqMTDm8AuEi7EmlhWXJl7iFGCg1lJhFfmDlCINyWxsiq1KD++qDQntfgQozQH i5I4b3bkvzAhgfTEktTs1NSC1CKYLBMHp1QDY9SUXob38ZN6ZBeqSb9on921647up5uZPPu+ SX/fOE/ytxiTfJqHwbQUPRnjS+erqmce9XXdfzzlYvHnDVv8v2hPqGovkeW5EXGz+nTnR4bC 3rVPfYxro/ZdP62zzsf7E2Pf1NuSLO1nP9jlL188p3dljbPORHk1Bz7zpcHrHPamv3loH9Dy SYmlOCPRUIu5qDgRAOStyfqtAgAA Archived-At: Subject: Re: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encryption X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:57:29 -0000 --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F927ESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Agree, this seems to be orthogonal to detnet, as it is a link-only function= . Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: Thursday, April 14, 2016 5:35 AM To: Grossman, Ethan A.; detnet@ietf.org Subject: Re: [Detnet] DetNet Use Cases Statmements: Link Authentication/Enc= ryption Hello Ethan I'm not sure this is (related to) a detnet function? It seems to be another= component of a solution. Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 13:33 To: detnet@ietf.org Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/Encrypt= ion Statement: Link Authentication/Encryption Discussion: This statement came from a section of the Pro Audio use case (which was wri= tten by my co-author :-) and I haven't looked into the details of whether t= here is anything implied in that statement that would require us to do anyt= hing other than our current strategy of "don't break security". Perhaps Mr.= Gunther will enlighten us... :- ) --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F927ESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Agree, this seems to be o= rthogonal to detnet, as it is a link-only function.

Cheers<= /p>

Bala’zs<= /span>

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert)
Sent: Thursday, April 14, 2016 5:35 AM
To: Grossman, Ethan A.; detnet@ietf.org
Subject: Re: [Detnet] DetNet Use Cases Statmements: Link Authenticat= ion/Encryption

 

Hello Ethan

 <= /p>

I’m not sure this i= s (related to) a detnet function? It seems to be another component of a sol= ution.

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: detnet= [mailto:detnet-bounces@ietf.org= ] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 13:33
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Cases Statmements: Link Authentication/= Encryption

 

Statement:

Link Authentication/Encryption

Discussion:

This statement came from a section of t= he Pro Audio use case (which was written by my co-author :-) and I haven= 217;t looked into the details of whether there is anything implied in that statement that would require us to do anything other than our curr= ent strategy of “don’t break security”. Perhaps Mr. Gunth= er will enlighten us… :- )

 

 

--_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F927ESESSMB103erics_-- From nobody Mon Apr 18 06:58:06 2016 Return-Path: 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 C753C12DE93 for ; Mon, 18 Apr 2016 06:58:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 6K89DmgchAGW for ; Mon, 18 Apr 2016 06:58:03 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC4B12DE3E for ; Mon, 18 Apr 2016 06:58:02 -0700 (PDT) X-AuditID: c1b4fb2d-f79006d000006928-1f-5714e7e80b31 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BC.C6.26920.8E7E4175; Mon, 18 Apr 2016 15:58:01 +0200 (CEST) Received: from ESESSMB103.ericsson.se ([169.254.3.234]) by ESESSHC022.ericsson.se ([153.88.183.84]) with mapi id 14.03.0248.002; Mon, 18 Apr 2016 15:58:00 +0200 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "detnet@ietf.org" Thread-Topic: DetNet Use Case Statements: Plug-And-Play Thread-Index: AdGRCNkIZirEvHznTV28oe5F8truEgE8zlXAAAhoyfAA0aD6gA== Date: Mon, 18 Apr 2016 13:57:59 +0000 Message-ID: <3002A87EA61E0A4DB56546AC16A0D5171EF9F93B@ESESSMB103.ericsson.se> References: <179217173638485a976bafbcf1f3a7c5@DLB-XCHPW03.dolby.net> <51ff0ecfb507493faaa8bc93bd77fc2d@XCH-RCD-001.cisco.com> <4E310F17BD503646BD155B102AF875E81E18873C@DEFTHW99EK3MSX.ww902.siemens.net> In-Reply-To: <4E310F17BD503646BD155B102AF875E81E18873C@DEFTHW99EK3MSX.ww902.siemens.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: multipart/alternative; boundary="_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F93BESESSMB103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupikeLIzCtJLcpLzFFi42KZGbE9RPflc5Fwg62XhCx+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujA+bvrAVnO1grOjpWsXYwLi7oouRk0NCwETieMs3RghbTOLC vfVsXYxcHEICRxgl/s9oY4JwljBKzG9dyApSxSbgKvG54yEbiC0ioC7R9uYaWLewgJnEzPNN QDYHUNxc4sxsZ4gSJ4kX13awgNgsAqoSR/+ALODg4BXwlfj5Uh5i/FlGibnrOsDGcwpESMz+ c4cZxGYEOuj7qTVMIDazgLjErSfzmSAOFZBYsuc8M4QtKvHy8T9WkJkSAkoS07amQZTnS9z+ 9BqshFdAUOLkzCcsExhFZiGZNAtJ2SwkZRBxPYkbU6ewQdjaEssWQtQwC+hKzPh3iAVZfAEj +ypG0eLU4uLcdCNjvdSizOTi4vw8vbzUkk2MwBg6uOW37g7G1a8dDzEKcDAq8fAmsIuEC7Em lhVX5h5ilOBgVhLhbXoKFOJNSaysSi3Kjy8qzUktPsQozcGiJM6bE/kvTEggPbEkNTs1tSC1 CCbLxMEp1cDo0D1xV5rg9zfT9y9sDty7yrF5WduP64anz6SyVZlwB8vmn41aF9MR6rlZk9cj iukf76OsSydmtmhOdvRd9npeeUCZZz6LyiwXy0vaf9yeiZ+62BHo4Xb1Y9fGZ65XDrlcufrv z3/Z515qJzXSb4ucaTyx4v/25Y7Mmk6nRUMelGhXObaa349TYinOSDTUYi4qTgQAzkia3p0C AAA= Archived-At: Subject: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2016 13:58:06 -0000 --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F93BESESSMB103erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In my view plug-and-play operation should cover all possible changes in the= population of the involved endpoints: 1, adding new device: which was not part of detnet communications before (s= ee J=FCrgen's comment). 2, replacing an existing device: due to failure or application update or wh= atever other reason we intend to replace a device (see Pascal's comment) 3, removing a device: this is the case where (e.g., due to the change of th= e network scenario) a device is removed from the group of detnet endpoints = (e.g., you do not need a given sensor anymore, etc.). That removal should a= utomatically free-up the booked network resources. We have discussed so far= , that unused BW of detnet flows should be available for non-critical traff= ic, however the booked resources of a removed endpoint may block the additi= on of new detnet flows. Therefore removing a device (and related network re= sources) should be also part of Plag-and-Play considerations. I think the "Stream start-up (or re-start) time" is also related to plug-an= d-play functions. It is something to be considered for the first case (add = new device), but also impacts heavily how the second case (replacing) is de= signed. Cheers Bala'zs From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Schmitt, Juergen Sent: Thursday, April 14, 2016 9:25 AM To: detnet@ietf.org Subject: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play Hi Pascal, I'm not sure this is the only use case for new devices. Especially in indus= try publish-subcribe is a widespread communication pattern. Not to be able = to add additional subscribers (such as a measurement system) at runtime wou= ld be a major issue. Juergen Von: detnet [mailto:detnet-bounces@ietf.org] Im Auftrag von Pascal Thubert = (pthubert) Gesendet: Donnerstag, 14. April 2016 05:23 An: Grossman, Ethan A.; detnet@ietf.org Betreff: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play Hello Ethan: In my world, the use case is a failing device replacement. What the use cas= e tells me is that there should be a way to provision the new device to tha= t it replaces the old device with a minimum of hassle, which means that it = could fit in the predecessor's shoes without having to recompute the paths = and/or reinstall them. Certainly this places also a requirement on the new device, which is expect= ed to have the same capabilities as the predecessor, or more. But that much= is acceptable. This also places requirements like that the semantics used = in the detnet signaling are universal enough so that there meaning is under= standable by the replacement. Eg, can the replacement use a label that was = locally significant to the predecessor? Cheers, Pascal From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Grossman, Ethan = A. Sent: jeudi 7 avril 2016 14:00 To: detnet@ietf.org Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play Statement: Plug-And-Play (new device, replace device) Discussion: Ethan: There are enough use cases and available technology for doing this, = and enough "feel of the room" that I claim it is in scope. It won't always = be possible (or useful) in every use case, so it must a feature that can be= selectively included in a given DetNet implementation. There is some disti= nction between introducing a "new" device into the network and replacing a = removed/failed device. However since a replacement for a failed device migh= t not be "exactly" the same as the original device (e.g. different firmware= revision) then some renegotiation seems inevitable (though maybe not as mu= ch as for a new device). --_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F93BESESSMB103erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

In my view plug-and-play = operation should cover all possible changes in the population of the involv= ed endpoints:

1, adding new device: whi= ch was not part of detnet communications before (see J=FCrgen’s comme= nt).

2, replacing an existing = device: due to failure or application update or whatever other reason we in= tend to replace a device (see Pascal’s comment)

3, removing a device: thi= s is the case where (e.g., due to the change of the network scenario) a dev= ice is removed from the group of detnet endpoints (e.g., you do not need a given sensor anymore, etc.). That removal should automat= ically free-up the booked network resources. We have discussed so far, that= unused BW of detnet flows should be available for non-critical traffic, ho= wever the booked resources of a removed endpoint may block the addition of new detnet flows. Therefore rem= oving a device (and related network resources) should be also part of Plag-= and-Play considerations.

 <= /p>

I think the “Stream= start-up (or re-start) time” is also related to plug-and-play functi= ons. It is something to be considered for the first case (add new device), but also impacts heavily how the second case (replacing) is designed.=

 <= /p>

Cheers<= /p>

Bala’zs<= /span>

 <= /p>

From: detnet [= mailto:detnet-bounces@ietf.org] On Behalf Of Schmitt, Juergen
Sent: Thursday, April 14, 2016 9:25 AM
To: detnet@ietf.org
Subject: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play=

 

Hi Pascal,

 

I’m not sure this is = the only use case for new devices. Especially in industry publish-subcribe = is a widespread communication pattern. Not to be able to add additional subscribers (such as a measurement system) at runtime would be a major iss= ue.

 

Juergen

 

Von: detnet [mailto:de= tnet-bounces@ietf.org] Im Auftrag von Pascal Thubert (pthubert)
Gesendet: Donnerstag, 14. April 2016 05:23
An: Grossman, Ethan A.; detnet@ie= tf.org
Betreff: Re: [Detnet] DetNet Use Case Statements: Plug-And-Play=

 

Hello Ethan:

 <= /p>

In my world, the use case= is a failing device replacement. What the use case tells me is that there = should be a way to provision the new device to that it replaces the old device with a minimum of hassle, which means that it could fit in = the predecessor’s shoes without having to recompute the paths and/or = reinstall them.

 <= /p>

Certainly this places als= o a requirement on the new device, which is expected to have the same capab= ilities as the predecessor, or more. But that much is acceptable. This also places requirements like that the semantics used in the detnet s= ignaling are universal enough so that there meaning is understandable by th= e replacement. Eg, can the replacement use a label that was locally signifi= cant to the predecessor?

 <= /p>

Cheers,<= /o:p>

 

Pascal

 <= /p>

From: detnet= [mailto:detnet-bounces@ietf.org= ] On Behalf Of Grossman, Ethan A.
Sent: jeudi 7 avril 2016 14:00
To: detnet@ietf.org
Subject: [Detnet] DetNet Use Case Statements: Plug-And-Play

 

Statement:

Plug-And-Play (new device, replace devi= ce)

Discussion:

Ethan: There are enough use cases and a= vailable technology for doing this, and enough “feel of the room̶= 1; that I claim it is in scope. It won’t always be possible (or usefu= l) in every use case, so it must a feature that can be selectively included i= n a given DetNet implementation. There is some distinction between introduc= ing a “new” device into the network and replacing a removed/fai= led device. However since a replacement for a failed device might not be “exactly” the same as the origina= l device (e.g. different firmware revision) then some renegotiation seems i= nevitable (though maybe not as much as for a new device).

 

--_000_3002A87EA61E0A4DB56546AC16A0D5171EF9F93BESESSMB103erics_-- From nobody Tue Apr 26 10:02:16 2016 Return-Path: X-Original-To: detnet@ietf.org Delivered-To: detnet@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 208E512D0DD; Tue, 26 Apr 2016 10:02:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.19.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160426170214.30132.12340.idtracker@ietfa.amsl.com> Date: Tue, 26 Apr 2016 10:02:14 -0700 Archived-At: Cc: detnet@ietf.org, lberger@labn.net, db3546@att.com, detnet-chairs@ietf.org Subject: [Detnet] detnet - New Meeting Session Request for IETF 96 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2016 17:02:14 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the detnet working group. --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: mpls netmod ccamp teas pce 6tisch dime dmm Second Priority: bess pals tsvwg nvo3 Special Requests: ---------------------------------------------------------