From nobody Thu Feb 1 08:12:33 2018 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 292F712EB62 for ; Thu, 1 Feb 2018 08:12:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 DA1oSLgg4Cow for ; Thu, 1 Feb 2018 08:12:24 -0800 (PST) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 E285512EB4C for ; Thu, 1 Feb 2018 08:12:23 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id c189so13054164oib.12 for ; Thu, 01 Feb 2018 08:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fvDgG6LPI0VNQQkyt9j0wfw0at8Fp/I4bMuAIOoa1Ds=; b=fg0XcpfkboVKRvXhhjlE0zNoZcBqa+HpENc+HfBpVg1qrBQ0989nz+KINAiO+49XpC O3L/woTbWftUQCzjjAZq1sqoPjW8yEMsn3zueu7jz7PC/9F9Eyt9pYoVsuvxJDbMLa2U /TwTevCJYK77mQScnw3KkQ6aL0aD7WrAfOaDJJnPcCb/n2KUDobX0e6Q3KeNgmaR8ORb aqSjkEK8jESO7fzwRbnaLYSWmpCqIioB9ke/Q3x7jo8ztUH7oE4XnTjwhVes76ZtP5RQ yN4Tyg0UFkF9BXMn97vaes+oovPlOediDzbhQuaUSx1R2oJ2h5S/Onty3eLQwfcsV3CB AR2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fvDgG6LPI0VNQQkyt9j0wfw0at8Fp/I4bMuAIOoa1Ds=; b=GUa7s7Glq9bPiG5uh7kSph8GbAFuHMGafwMWLRj+CBjnaLRd6Ptb50Mrp2otEHajpw RSGTzEGzKZiDaXwdWpJpOSNNpAMZOd4kklhKyygcASwu80Z7u7bgG97+JZZkSv4P2To4 n8QvHHPijTp3MLyZP+yGJnQkEcJeSw6ss8FVrOxZdu8HVLRFtvusMzTzyM7Hp3yICNXm lAW863hV06hoWh1NWSliC+tKNDhSG5JKLEfw8Jw1J33deuQ8p10h71dUp4/RudDfvvNQ jaUYakjsA7BB/z0hgRbh5SLsxsZfWRaroRehVk8pAtg4o5zSnRTpu7JIXy1oK8d6izp+ maWA== X-Gm-Message-State: AKwxytecrnmHOnsuykA8SMOuwjvCj+oK9/9pzX/U8L88IdTI+XkKZ92y z26FP4mzf/eo15LqmLCMLmnwrnAvkQ98tUz8yFI= X-Google-Smtp-Source: AH8x2267uq7B1ZlQxCq/dmd1O7K8+ceoizo/jnMFBMbdkMkrxwjgXv9uB02lQY4pNu4FSkos2TTlt+h4yG1MIycxIZg= X-Received: by 10.202.104.135 with SMTP id o7mr10659010oik.296.1517501543212; Thu, 01 Feb 2018 08:12:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.72 with HTTP; Thu, 1 Feb 2018 08:12:02 -0800 (PST) In-Reply-To: <067601d39955$98063590$c812a0b0$@gmail.com> References: <151726683471.27507.12373717618852607689.idtracker@ietfa.amsl.com> <067601d39955$98063590$c812a0b0$@gmail.com> From: "Andrew G. Malis" Date: Thu, 1 Feb 2018 11:12:02 -0500 Message-ID: To: Jouni Cc: DetNet WG Content-Type: multipart/alternative; boundary="001a11409cd86dea5e056428dc2a" Archived-At: Subject: Re: [Detnet] FW: New Version Notification for draft-ietf-detnet-dp-sol-01.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 01 Feb 2018 16:12:32 -0000 --001a11409cd86dea5e056428dc2a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jouni, I have a small nit on Figure 4. The =E2=80=9CDetNet data plane MPLS encapsu= lation=E2=80=9D should include the T-Label(s). Thanks, Andy On Mon, Jan 29, 2018 at 6:05 PM, Jouni wrote: > FYI.. this is the -01 of the draft where I left off (based on the > input/guidance I got and some of my own). The draft still has both MPLS a= nd > IPv6 solutions in it as agreed in the last interim - now just arranged fo= r > easier split of the solution documents. > > - Jouni > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, January 30, 2018 01:01 AM > To: Carlos J. Bernardos ; Norman Finn < > norman.finn@mail01.huawei.com>; Tal Mizrahi ; Carlos > Bernardos ; Bal=C3=A1zs Varga ; > Janos Farkas ; Balazs Varga < > balazs.a.varga@ericsson.com>; Jouni Korhonen ; > Loa Andersson ; Lou Berger ; Yuanlong Jiang = < > jiangyuanlong@huawei.com> > Subject: New Version Notification for draft-ietf-detnet-dp-sol-01.txt > > > A new version of I-D, draft-ietf-detnet-dp-sol-01.txt has been > successfully submitted by Jouni Korhonen and posted to the IETF repositor= y. > > Name: draft-ietf-detnet-dp-sol > Revision: 01 > Title: DetNet Data Plane Encapsulation > Document date: 2018-01-29 > Group: detnet > Pages: 37 > URL: https://www.ietf.org/internet-drafts/draft-ietf-detnet-dp= - > sol-01.txt > Status: https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol= / > Htmlized: https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-ietf-detnet-dp-sol-01 > Diff: https://www.ietf.org/rfcdiff? > url2=3Ddraft-ietf-detnet-dp-sol-01 > > Abstract: > This document specifies Deterministic Networking data plane > encapsulation solutions. The described data plane solutions can be > applied over either IP or MPLS Packet Switched Networks. > > > > > 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. > > The IETF Secretariat > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a11409cd86dea5e056428dc2a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jouni,

I have a small nit on Figure 4. = The =E2=80=9CDetNet data plane MPLS encapsulation=E2=80=9D should include t= he T-Label(s).

Thanks,
Andy

On = Mon, Jan 29, 2018 at 6:05 PM, Jouni <jouni.nospam@gmail.com> wrote:
FYI.. this is the -01 of the= draft where I left off (based on the input/guidance I got and some of my o= wn). The draft still has both MPLS and IPv6 solutions in it as agreed in th= e last interim - now just arranged for easier split of the solution documen= ts.

- Jouni

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: Tuesday, January 30, 2018 01:01 AM
To: Carlos J. Bernardos <cjbc@it.uc3m= .es>; Norman Finn <norman.finn@mail01.huawei.com>; Tal Mizrahi <talmi@marvell.com>; Carlos Bernardos <cjbc@it.uc3m.es>; Bal=C3=A1zs Varga= <balazs.a.varga@ericsson= .com>; Janos Farkas <janos.farkas@ericsson.com>; Balazs Varga <balazs.a.varga@ericsson.com>; Jouni Korhone= n <jouni.nospam@gmail.com&= gt;; Loa Andersson <loa@pi.nu>; Lou = Berger <lberger@labn.net>; Yu= anlong Jiang <jiangyuanlong@= huawei.com>
Subject: New Version Notification for draft-ietf-detnet-dp-sol-01.txt<= br>

A new version of I-D, draft-ietf-detnet-dp-sol-01.txt has been success= fully submitted by Jouni Korhonen and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-detnet-dp-sol
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet Data Plane Encapsulation Document date:=C2=A0 2018-01-29
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 detnet
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 37
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-ietf-detnet-d= p-sol-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-ietf-detnet-dp-sol-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-0= 1
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-dp-sol-= 01

Abstract:
=C2=A0 =C2=A0This document specifies Deterministic Networking data plane =C2=A0 =C2=A0encapsulation solutions.=C2=A0 The described data plane soluti= ons can be
=C2=A0 =C2=A0applied over either IP or MPLS Packet Switched Networks.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


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

--001a11409cd86dea5e056428dc2a-- From nobody Thu Feb 1 12:24:29 2018 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 9096612D942 for ; Thu, 1 Feb 2018 12:24:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 hR8x43BgZSM8 for ; Thu, 1 Feb 2018 12:24:26 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (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 E0C5E1276AF for ; Thu, 1 Feb 2018 12:24:25 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id f136so28160349lff.8 for ; Thu, 01 Feb 2018 12:24:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UKrcB5QpEef5hRx3DJbYEViEzG7roZjp0wM+dpLUIuM=; b=FynqK7MCbLSjD4cPs5InQsiAvHqQGnyk7Px9tD69RYOIGZap45SJk+Jf6M2pO/w+9Q nZfv5upv4sEr07juK7g+hgcHQqawXdxTa2tsleVuOqtzoIOWWHPWA8vWDwzgauNsP7hr PvqCsRKZu3VP0pkV065R1yWqot29d+qyVZbeW88iRsPLghtXjXMKLEm3is47oxXU1FCc YhX3s/ql92q0UWJLrt4BE+7AOY8D0h2x3bN10hyWCKSqWrrMcHYSO4pviiLCUgRipImx 1OWrde3Hibdtl0h+S+ckB4xBqhGDizN2hIAsh1e0RFEp4THYGUpedYfX2Jj2DLmZQGOs lX2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UKrcB5QpEef5hRx3DJbYEViEzG7roZjp0wM+dpLUIuM=; b=m++wMJm9F/XMUuEdVLqEwCIbo2aTqj18eSpxKZ2Vv0TQjkt3wHO5pkbyXzoRQIK9qs jlAwvOPJDwVNx5dytMiG4JYZyB889SWJVbUn9TcU/pkb612hChlVFCce9DQGwq6Ylj1s lGTsjjR2RzABjVKDMpexEbOh2ehy2oB1LbSX8sRNEepgPCu5M6OACmMb+T3ad4BHJaHL uFMxK79P7GltWOynSrS9iqmf7D3PrayEY8yD1a1moI8M7s9JYSDoDPJaEdwpH9CDKP+t pt6adMQgS0gsmawjkcRmEvRMGYaF9VMDyHvVxjCAxpQ9S3azTrwTRr8VBV76vU32l5tP ecHw== X-Gm-Message-State: AKwxytfW2ti5iSI70NdOECR6jEn0F1rUZue8OktBCXvKKN7ATDcLo8Dn 81Gupaw88hR5a0fjf5z7NBM= X-Google-Smtp-Source: AH8x226L668/N+mZE4QkasGPsvnfwjrq7rak2LBkaSt/B6bO5P6tgA2PPWmACtL8fbpO3jbhAhr1bw== X-Received: by 10.46.54.11 with SMTP id d11mr11507308lja.80.1517516664171; Thu, 01 Feb 2018 12:24:24 -0800 (PST) Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id s67sm66859lje.22.2018.02.01.12.24.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Feb 2018 12:24:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Thu, 1 Feb 2018 22:24:18 +0200 Cc: DetNet WG Content-Transfer-Encoding: quoted-printable Message-Id: <86EBE5BD-4787-4952-865B-2323280BCF8B@gmail.com> References: <151726683471.27507.12373717618852607689.idtracker@ietfa.amsl.com> <067601d39955$98063590$c812a0b0$@gmail.com> To: "Andrew G. Malis" X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Detnet] New Version Notification for draft-ietf-detnet-dp-sol-01.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 01 Feb 2018 20:24:28 -0000 Ack. Thanks. - Jouni > On 01 Feb 2018, at 18:12, Andrew G. Malis wrote: >=20 > Jouni, >=20 > I have a small nit on Figure 4. The =E2=80=9CDetNet data plane MPLS = encapsulation=E2=80=9D should include the T-Label(s). >=20 > Thanks, > Andy >=20 >=20 > On Mon, Jan 29, 2018 at 6:05 PM, Jouni wrote: > FYI.. this is the -01 of the draft where I left off (based on the = input/guidance I got and some of my own). The draft still has both MPLS = and IPv6 solutions in it as agreed in the last interim - now just = arranged for easier split of the solution documents. >=20 > - Jouni >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Tuesday, January 30, 2018 01:01 AM > To: Carlos J. Bernardos ; Norman Finn = ; Tal Mizrahi ; Carlos = Bernardos ; Bal=C3=A1zs Varga = ; Janos Farkas ; = Balazs Varga ; Jouni Korhonen = ; Loa Andersson ; Lou Berger = ; Yuanlong Jiang > Subject: New Version Notification for draft-ietf-detnet-dp-sol-01.txt >=20 >=20 > A new version of I-D, draft-ietf-detnet-dp-sol-01.txt has been = successfully submitted by Jouni Korhonen and posted to the IETF = repository. >=20 > Name: draft-ietf-detnet-dp-sol > Revision: 01 > Title: DetNet Data Plane Encapsulation > Document date: 2018-01-29 > Group: detnet > Pages: 37 > URL: = https://www.ietf.org/internet-drafts/draft-ietf-detnet-dp-sol-01.txt > Status: = https://datatracker.ietf.org/doc/draft-ietf-detnet-dp-sol/ > Htmlized: = https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-ietf-detnet-dp-sol-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-detnet-dp-sol-01 >=20 > Abstract: > This document specifies Deterministic Networking data plane > encapsulation solutions. The described data plane solutions can be > applied over either IP or MPLS Packet Switched Networks. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat >=20 >=20 > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet >=20 From nobody Tue Feb 6 07:12:42 2018 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 D6D501243FE; Tue, 6 Feb 2018 07:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 hZr5ZaZa5ky4; Tue, 6 Feb 2018 07:12:38 -0800 (PST) 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 A2B4112D7F8; Tue, 6 Feb 2018 07:12:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15603; q=dns/txt; s=iport; t=1517929958; x=1519139558; h=from:to:cc:subject:date:message-id:mime-version; bh=IamEsiQSk6Lt0NIaTkCiINCCLI/9R1yDCDdJ55BEhis=; b=di4zJZiJ+NDoiHMB5g+HYASymOqYHPkknuJE81lzLqy14EOeLrEZRI+G YmkRpi1DD4UkzgxbhSCgMy1fPRg0KPd5SARd6MkrrduPZ8iN8Imji1/rh r/YCGHX+0/yyhR5Hw8gFXGyH4ZiTXz7VEYvXSK1kRIDJHyTvqSwyYZ7CE 0=; X-Files: image001.jpg, image002.gif : 2607, 87 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAADJxHla/4cNJK1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZeGZwKAqNf44xk3WFVRWCAwcBAiOFGAKCXFQYAQEBAQEBAQE?= =?us-ascii?q?CayiFJQEJIAIGATYVDgQBGgsBAQEKFQkFEAQCBwIMFAMPAQQBDQQBCAaKJxC0d?= =?us-ascii?q?4JzITqIfIF4AQEBAQEBAQEBAQEBAQEBAQEBAQEBDg8FhGWBNWCBV2yDVoN4CwE?= =?us-ascii?q?BAQEBgTEKARIBJQYLHwiFPgWTGAqHAYV0AQKCZoEuAocTAYEEOo0XgidnhUASi?= =?us-ascii?q?g+BVo1xiWICERkBgTsBHzlgcHAVgwMJgwEYgVV4AYxQDRiBDYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,469,1511827200"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="350747270" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 15:12:36 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w16FCaEE017459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 6 Feb 2018 15:12:36 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.1320.4; Tue, 6 Feb 2018 09:12:36 -0600 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.1320.000; Tue, 6 Feb 2018 09:12:36 -0600 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?J=E1nos_Farkas?= , =?iso-8859-1?Q?Bal=E1zs_Varga_A?= CC: "detnet@ietf.org" , "draft-ietf-detnet-flow-information-model@ietf.org" Thread-Topic: typos in https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-00 Thread-Index: AdOfU3eRgt9HPeKSTLWlQJnKo0d4nA== Date: Tue, 6 Feb 2018 15:12:22 +0000 Deferred-Delivery: Tue, 6 Feb 2018 15:12:18 +0000 Message-ID: <562a9f9f1be143ef99aa741220c1b865@XCH-RCD-001.cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.225.85] Content-Type: multipart/related; boundary="_005_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: Subject: [Detnet] typos in https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-00 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 06 Feb 2018 15:12:41 -0000 --_005_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_ Content-Type: multipart/alternative; boundary="_000_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_" --_000_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Janos and Balazs (Happy new year : ) Reading https://tools.ietf.org/html/draft-ietf-detnet-flow-information-mode= l-00 I came onto the following: Use of "DetNetwork" -> seems that a Net->Network transform happened to wid= ely Section 6.4 discusses a service rank but is located in the Flow section. I = expected a slightly different structure that would reflect the initial dich= otomy in flows and services, where flows comprise source and destination in= formation, as well as status, etc... That would place sections 7, 8 and 9 i= n section 6, and 10...13 into a new "flow" section that would include 6.4. For flow identification over the UNI, would be good to mention the 5-tuple = (source/destination addresses/port and flow label) in IPv6 and the 4-tuple = in IPv4. Cheers, Pascal [banner4] Pascal Thubert Principal Engineer Chief Technology & Architecture Office pthubert@cisco.com Phone :+33 497 23 26 34 Mobile :+33 619 98 29 85 Cisco Systems Building D (Regus) 45 Allee des Ormes - BP1200 06254 MOUGINS cedex France Cisco.com [Description: Think before you print.]Think before you print. This email may contain confidential and privileged material for the sole us= e of the intended recipient. Any review, use, distribution or disclosure by= others is strictly prohibited. If you are not the intended recipient (or a= uthorized to receive for the recipient), please contact the sender by reply= email and delete all copies of this message. Please click here for Company Registration Information. --_000_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Janos and Balazs<= /span>

 

(Happy new year : )

 

Reading https://tools.ietf.org/html/draft-ietf-detnet-flow-information-model-00= I came onto the following:

 

Use of “DetNetwork” -> seems that a N= et->Network  transform happened to widely

 

Section 6.4 discusses a service rank but is located = in the Flow section. I expected a slightly different structure that would r= eflect the initial dichotomy in flows and services, where flows comprise so= urce and destination information, as well as status, etc… That would place sections 7, 8 and 9 in sect= ion 6, and 10…13 into a new “flow” section that would inc= lude 6.4.

 

For flow identification over the UNI, would be good = to mention the 5-tuple (source/destination addresses/port and flow label) i= n IPv6 and the 4-tuple in IPv4.

 

Cheers,

 

Pascal

 

 

 

 

 

 

 

 

 

3D"banner4"=

Pascal Thubert
Principal Engineer
Chief Technology & Architecture Office

pthubert@cisco.com
Phone :+33 497 23 26 34
Mobile :+33 619 98 29 85

Cisco Systems
Building D (Regus) 
45 Allee des Ormes - BP1200
06254 MOUGINS cedex
France
Cisco.com

3D"Description:Think before you print.

This email may contain confidential and privileged mat= erial for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibit= ed. If you are not the intended recipient (or authorized to receive for the= recipient), please contact the sender by reply email and delete all copies= of this message.

Please click here for Company Registratio= n Information.=

 

 

--_000_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_-- --_005_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=2607; creation-date="Tue, 06 Feb 2018 15:12:21 GMT"; modification-date="Tue, 06 Feb 2018 15:12:21 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwgHBgoICAgLCgoLDhgQDg0NDh0VFhEYIx8lJCIf IiEmKzcvJik0KSEiMEExNDk7Pj4+JS5ESUM8SDc9Pjv/2wBDAQoLCw4NDhwQEBw7KCIoOzs7Ozs7 Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozs7Ozv/wAARCABOAloDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0Kiii uw5gooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKK KACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKt2P8f4VUq3Y/x/ hUy2Gty3RRRWRoFRXP8Ax7v9KlqK5/493+lNbiexnUUUVsZhT0id/urx61JbxeYdzfdH61cHFS5W KSuUvssvoPzqzboyRYYY5NSVLGMp+NQ5OxSiR0UrrtPtSVIwqC7/ANUP96p6gu/9UP8AeqluJ7FK pIf9en+9UdSQ/wCvT/erR7EI0qKKKxNAooooAzJv9c/+8aZT5v8AXP8A7xplbLYyCiiimAUVBeX1 tYRLLdSiNGYICR1J7VQ1vUrixn09LcrtuJwj5GcqaTdhpFu51O2tL23s5Swluf8AV4HH41crnNd/ 5GnRvqf51cm1G4TxVBp6lfIeBnYY5zSuOxrUtV1vrZ75rFZQbhF3MnoKz9M1K4utd1KzlK+VbsBH gcjincVi7Zalb6g9wkBYm3fY+Rjn2q1XP+F/+PjWP+vn+lWfD+qT3+nT3F2y5ilYZAxwKSY2jXoq G0u4L62S5tn8yJ87WxjNTVRIUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUU AFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABVux/j/CqlW7H+P8KmWw1u W6KKKyNAqK5/493+lS1Fc/8AHu/0prcT2M6iiitjMu23+pH1NTVFbf6gfU1LWT3NFsFTRfc/Goal i+7+NSykEvQfWo6kl+6PrUdCBhUF3/qh/vVPVe8P7sDvmqW5L2KdSQ/69P8AeqOpIf8AXp/vVo9i EaVFFFYmgUUUUAZk3+uf/eNMp83+uf8A3jTK2WxkFFFFMClqulxatbJBM7IqSCQFfUUX+lRag9oz uyfZZA64747GrtYmsaxeQ6jFpemQrJdSLuZn6KKl26jVx2q6fdXWv6ZdRIDFAT5hJ6c1ck0uKTWY 9TLt5kcZjC9jnvVSW81Wx0G6ub0Q/aogSuzlSKg1LXrqz8P2V6kaGa5C7mI+VMjrSuh6mlHpUMes yaoHbzZE2Fe31otNKis9Rur5HZnuiCynov0qvZajNFpU97fXNvcJECwe36EelUtN1DxBqTRXgt4I 7KRvuk/Nt9ad0FmWtBsLmyn1JrhAqzz7oyDnIx1qzp+jw6dYzWkcjuszMWLdeazr3WNSutXl07Ro oybcfvZZOgPpVjQ9YnvpbiyvoRFeWx+cL0YetJW2B3L2mWCaXp8dnG7OsecM3U5OatUUVZIUUUUA FFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU UUUAFFFFABRRRQAUUUUAFFFFABVux/j/AAqpVqyYBmXuamWw1uXKKKKyNAqK5/493+lS1DdMFgYe vAprcT2M+iiitjMvW3+oH1NS1Fbf6gfU1LWT3NFsFORtp9qbRUjJZCCox61HVe6YqqlSQc9qredJ /wA9G/OqUdBOWpfd1QZY4FUZpTK+egHQUwksckkn3pKtRsS3cKkh/wBen+9UdSQ/69P96m9hI0qK KKxNAooooAzJv9c/+8aZT5v9c/8AvGmVstjIKKKKYBWHrGj3smpxarpcqLdIuxlk4DCtyik1cadj HmtNWv8AQLq2vBCLqUEIEb5QPrSy2mow6JaWlvbWtzJGgWWOdvlOB2rXoosFzn9J8Oyw2N/DelEF 7/yyiOVj+lN0yx8RacYrPzLeSzjb/WE/Nt9MV0VFLlQ7s5+70jVLTWJdR0Z4iLgfvYpTgZ9asaHp FzZz3F9fyrJeXP3tnRR6VsUUcquK7CiiiqEFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRR QAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAVJDC0zYHAHU1HWlboEhXHcZNTJ 2Q0riJbRIPu5Pqad5Mf/ADzX8qfRWV2aFWa0GC0fB9KqdK1aoXaBZsj+IZrSL6ENEFOVirBl4Ipt FWSaEV0jjDHa3vUu4eo/Osqio5CuY0nmjjHzMM+gqjNM0zZPAHQVHRTUUhN3CiiiqEXrb/UD6mpa itv9QPqalrJ7mi2CiiikMr3n3F+tVKt3n3F+tVK0jsRLcKKKKokKfEQsqE9AaZRQBrUVVt7kEBJD gjoatDnpzWLVjRO4UUHjrxVW4uRgpGck9TQlcG7FaQhpWI6E0yiitjMKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigArUi/1Sf7orLrUi/wBUn+6KiZUR1FFFZlhVK9/1i/7tXapXv+sX /dqo7ilsVqKKK1MwooooAKKKKACiiigC9bf6gfU1LUVt/qB9TUtZPc0WwUUUUhle8+4v1qpVu8+4 v1qpWkdiJbhRRRVEhRRRQAU4Mw6MR+NNooAUsx6sT+NJRRQAUUUUAf/Z --_005_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=87; creation-date="Tue, 06 Feb 2018 15:12:21 GMT"; modification-date="Tue, 06 Feb 2018 15:12:21 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEgATAJEAAAAAAP///wCZAP///yH5BAEAAAMALAAAAAASABMAAAIojI+pGyK8nINqUiTf bVnfvHEg1UmhdZRqaawu6XZVjKb0/CYxo8JOAQA7 --_005_562a9f9f1be143ef99aa741220c1b865XCHRCD001ciscocom_-- From nobody Wed Feb 7 05:27:32 2018 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 761EA126E64 for ; Wed, 7 Feb 2018 05:27:30 -0800 (PST) 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 dsg8lW5xKBI4 for ; Wed, 7 Feb 2018 05:27:28 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E71C812D775 for ; Wed, 7 Feb 2018 05:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=45311; q=dns/txt; s=iport; t=1518010047; x=1519219647; h=from:to:subject:date:message-id:mime-version; bh=OcU92NF0zW4gTZrbStMUX+R9i9UqpP4fub6Qxq+iXNQ=; b=cXdLwUseNVNMjbOlYdzdtq746QO0iLct64rDcOP/SBgkRIZq7Ha7FZwh aA8ufExJHBCCMjNB4mNi1O7QpdRBRmsmiU5UInUwLMVQzCxNpGQkNF+hM cxxgEXOqdeT2bZ930Ta2hJ2aGd4vmLzMkXl8N9wzPxze/XaFugRlZ9QSr o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CtAACO/npa/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZeGZwKAqNf44kmVQVggMKI4gDVBgBAgEBAQEBAQJrHQuFV14?= =?us-ascii?q?BQAE/JgEEG4lJZBC0FIh2ggoBAQEBAQUBAQEBAQEBHAWEdYIVgVeBaIZdAQECA?= =?us-ascii?q?YE2hhQgBYpqmT8JAogcjVSUR416iWMCERkBgTsBHzmBUHAVgwSEdngBAYx7gRc?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208,217";a="353069235" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 13:27:22 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w17DRMiS002793 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 7 Feb 2018 13:27:22 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.1320.4; Wed, 7 Feb 2018 07:27:22 -0600 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.1320.000; Wed, 7 Feb 2018 07:27:22 -0600 From: "Pascal Thubert (pthubert)" To: "detnet@ietf.org" Thread-Topic: IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQ== Date: Wed, 7 Feb 2018 13:27:09 +0000 Deferred-Delivery: Wed, 7 Feb 2018 13:26:41 +0000 Message-ID: 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.228.216.11] Content-Type: multipart/alternative; boundary="_000_cff50c52d2f945cfa8eff149f5242fb0XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 13:27:30 -0000 --_000_cff50c52d2f945cfa8eff149f5242fb0XCHRCD001ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all This is about the IPv6 encapsulation and more precisely Therefore, if a DetNet-aware end system only inserted the DetNet Destination Option into the IPv6 but e.g., a DetNet Edge node is configured to enforce an explicit route for the IPv6 packet using a source routing header, then it has no other possibility than add an outer tunneling IPv6 header with required extension headers in it. The processing of IPv6 packets in a DetNet Edge node is discussed further in Section 6.4.1. With the current spec, a source sends a DetNet packet as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ This creates a duplication of the DetNet Destination Option. There are alternatives a) whereby the packet is tunneled from the source to the detnet ingress, a= nd based on its state the DetNet ingress accepts the packet, processes it a= nd then resends it. The tunneled version of this could be: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (dest =3D final destination) | /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge) | | (with set Flow label) | +---------------------------------+ Which allows the ingress to tunnel to the egress as follows: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (to final destination) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet egress edge) | | (with set Flow label) | +---------------------------------+ b) whereby the PREF is done by the end nodes and the tunnel is transport o= nly, meaning that there are 2 tunnels A and B and that the source sends twi= ce a packet like this: +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge X)| | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D final destination) | | (with set Flow label) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | +---------------------------------+ | IPv6 header | | (dest =3D DetNet egress edge X) | | (with set Flow label) | +---------------------------------+ Cheers, Pascal --_000_cff50c52d2f945cfa8eff149f5242fb0XCHRCD001ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

= This is about the IPv6 encapsulation and more precisely

=  

            &nb=
sp;           Theref=
ore, if a DetNet-aware end system only
   inserted the DetNet Destination Option into the IPv6 but =
e.g., a
   DetNet Edge node is configured to enforce an explicit rou=
te for the
   IPv6 packet using a source routing header, then it has no=
 other
   possibility than add an outer tunneling IPv6 header with =
required
   extension headers in it.  The processing of IPv6 pac=
kets in a DetNet
   Edge node is discussed further in Section 6.4.1.

=  

=  

= With the current spec, a source sends a DetNet packet as<= /p>

 

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          /-----------------= ----------------\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

= And then the ingress node needs to re-encapsulate as

 
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        |     =
;      DetNet Flow     &n=
bsp;     |
           &nbs=
p;        |     =
;        Payload    =
         |
            &nb=
sp;       |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

           &nbs=
p;        \-----------------------------=
----/
           &nbs=
p;        |     =
;     IPv6 header      &n=
bsp;     |
            &nb=
sp;       |     (wit=
h set Flow label)       |
           &nbs=
p;        +-------------------------=
--------+

=  

= This creates a duplication of the DetNet Destination Option.

=  

= There are alternatives

=  

a)  whereby the packet is tunneled from the source to the detnet ingres= s, and based on its state the DetNet ingress accepts the packet, processes = it and then resends it. The tunneled version of this could be:

=  

=

         &nbs= p;          +--------= -------------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D final destination)    |

         &nbs= p;          /=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet ingress edge)  |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

=  

= Which allows the ingress to tunnel to the egress as follows:

=

         &nbs= p;          +--------= -------------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   &nbs= p;  (to final destination)     |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        /-----------------------------=
----\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet egress edge)   |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

 

b)  whereby the PREF is done by the end nodes and the tunnel is transpo= rt only, meaning that there are 2 tunnels A and B and that the source sends= twice a packet like this:

 

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          /-----------------= ----------------\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet ingress edge X)|

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

= And then the ingress node needs to re-encapsulate as

 
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        |     =
;      DetNet Flow     &n=
bsp;     |
           &nbs=
p;        |     =
;        Payload    =
         |
            &nb=
sp;       |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D final destination)    |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;     IPv6 header      &n=
bsp;     |
           &nbs=
p;        |   (dest =3D DetNet=
 egress edge X) |
            &nb=
sp;       |     (wit=
h set Flow label)       |
           &nbs=
p;        +-------------------------=
--------+

 

Cheers,

 

Pascal

--_000_cff50c52d2f945cfa8eff149f5242fb0XCHRCD001ciscocom_-- From nobody Wed Feb 7 06:13:37 2018 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 4A9081200B9 for ; Wed, 7 Feb 2018 06:13:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 yD9S94JjnKID for ; Wed, 7 Feb 2018 06:13:34 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 5FE621205F0 for ; Wed, 7 Feb 2018 06:13:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518012812; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a5DYYKPlZTUIj4FiyNSjBjyBcM0wmgUuNlz8LX8kAo4=; b=d2ZDMN0V6x+0XRRkoR+rxMTCmgpCiEx9b/GgJAfGvLrZ89tE53b5UAtcCcqmdQwF qO3a006Q/RkOVMud92z2NbryyG76SyHyA4t6IFyC/3ijloO5NcGn4yrow40Inp16 NpXnBCzs81ljOizCHTlyYI8AcjjR3F9+IOja9KdWPCU=; X-AuditID: c1b4fb30-399ff70000004778-7d-5a7b098ce348 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 82.74.18296.C890B7A5; Wed, 7 Feb 2018 15:13:32 +0100 (CET) Received: from [159.107.143.208] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.352.0; Wed, 7 Feb 2018 15:13:32 +0100 To: CC: From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: Date: Wed, 7 Feb 2018 15:13:31 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGLMWRmVeSWpSXmKPExsUyM2K7t24PZ3WUwful2ha/P81msej/7+jA 5LFkyU+mAMYoLpuU1JzMstQifbsErowLZy+yFSzmrThx+SJTA+Nc7i5GTg4JAROJL4tus3Qx cnEICRxmlLjXsYAZwlnDKDHpzkw2kCoRAVGJE1M62UFsZgFZiRN/lrGA2GwC9hJ3L21gBrGF BTwlOncvAavnBYq/+zSTEcRmEVCRuPrtFFAvB4eoQIzE+r4EiBJBiZMzn7BAjLSQmDn/PCOE LS+x/e0csJFCAmoSn94+ZJ/AyDcLScssJC2zkLQsYGRexShanFqclJtuZKSXWpSZXFycn6eX l1qyiREYWge3/DbYwfjyueMhRgEORiUe3oVfqqKEWBPLiitzDzFKcDArifC6s1dHCfGmJFZW pRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamDs+LmWo3R+Y//xCZef P4ztVeY+lbPhk5e31pK1954/5mJz2a1vlhu4csPB2mKGO6mLmVSbiyt/8cbkTd81ed5J8cTP CSt5RNq+z4hYNyXl8ZGbmmvezp+4dXpM1Zq65HOpKnvYHm6PyP/rs91mZc3pbN4jB5ek2a1y FH5ca1Ai2HEvTvmQI/d7JZbijERDLeai4kQAAt4CMCkCAAA= Archived-At: Subject: [Detnet] Virtual interim on DetNet Data Plane - February 14, 1500-1700GMT X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 14:13:36 -0000 Dear All, We are planning to hold our third virtual interim to discuss the DetNet Data Plane document, https://tools.ietf.org/html/draft-ietf-detnet-dp-sol [1]. The intent is to continue working through open issues on the draft based on revision 01 and where we left off at the previous virtual interims. Contributions on multiple open items were encouraged at the last interim [5]. The main focus of this interim is to discuss those contributions. The meeting will be held February 14 at 1500GMT. We are aiming for a 90 minute meeting, but are scheduling to allow 30 minutes of extra discussion time if needed. Webex details will be announced when available. The agenda is less formal than our normal meetings and is: - Administrativa (chairs) - Draft status update (authors) - Contributions to address open issues (contributors) - Next steps, including future meetings [1] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 [2] IETF 100 open issues: https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/ [3] IETF 100 open issues - PREF: https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/ [4] 1st DetNet Interim: https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet [5] 2nd DetNet Interim: https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet Note that low participation is expected from Asia due to the Chinese New Year; therefore, this slot has been chosen by the main contributors for this meeting. Thank you, DetNet WG Chairs From nobody Wed Feb 7 06:59:55 2018 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 CD32D12D7ED for ; Wed, 7 Feb 2018 06:59:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 eiHzBtVg3VhC for ; Wed, 7 Feb 2018 06:59:50 -0800 (PST) Received: from gproxy3-pub.mail.unifiedlayer.com (gproxy3-pub.mail.unifiedlayer.com [69.89.30.42]) (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 5654C120454 for ; Wed, 7 Feb 2018 06:59:50 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy3.mail.unifiedlayer.com (Postfix) with ESMTP id BBAAF40090 for ; Wed, 7 Feb 2018 07:59:48 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id 7qzk1x00l2SSUrH01qzneT; Wed, 07 Feb 2018 07:59:48 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=edVRhR5uXvItvEUqdWMA:9 a=CjuIK1q_8ugA:10 a=dNJ83vk1-jzlG1m8c9sA:9 a=t8RzVVZd_nQIQRLl:21 a=UiCQ7L4-1S4A:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=T4DvZzjFH3eXogmcZ2NsO3Ul3YpSm3KcPwGTJlhMrfU=; b=z1MJErSdk/5A5fBZEZEsTOpVRw IEI04wF3O3zfqcH8sOoYkHYAwijd28s/RJBb7hhnuchFIxznF5sNGEnAcik7m4bDmL/WosPuEbZZD uHTByXAbqtteVZMHejk15iWtr; Received: from [172.58.185.2] (port=33241 helo=[IPV6:2607:fb90:6443:9639:0:47:ab3a:2b01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ejRCK-001Yz2-1m; Wed, 07 Feb 2018 07:59:44 -0700 From: Lou Berger To: "Pascal Thubert (pthubert)" , Date: Wed, 07 Feb 2018 09:59:42 -0500 Message-ID: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------16170c7918341de27d39d32005" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.185.2 X-Exim-ID: 1ejRCK-001Yz2-1m X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:6443:9639:0:47:ab3a:2b01]) [172.58.185.2]:33241 X-Source-Auth: lberger@labn.net X-Email-Count: 7 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 14:59:54 -0000 This is a multi-part message in MIME format. ------------16170c7918341de27d39d32005 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Pascal/all, At the last interim a proposal was made to simplify IP processing, at least for the initial detnet solution, by leaving PREF to the subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow identification based on typical IP 5-tuple perhaps + dscp. This approach has several benefits beyond simplification, notably it will work for both ipv4 and IPv6, and doesn't require any modification to encapsulation / formats. It would be really valuable to get feedback from the whole working group if this simplification is acceptable or has unacceptable limitations. Lou On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" wrote: > Dear all > > This is about the IPv6 encapsulation and more precisely > > > Therefore, if a DetNet-aware end system only > > inserted the DetNet Destination Option into the IPv6 but e.g., a > > DetNet Edge node is configured to enforce an explicit route for the > > IPv6 packet using a source routing header, then it has no other > > possibility than add an outer tunneling IPv6 header with required > > extension headers in it. The processing of IPv6 packets in a DetNet > > Edge node is discussed further in Section > 6.4.1. > > > With the current spec, a source sends a DetNet packet as > > +---------------------------------+ > | | > | DetNet Flow | > | Payload | > | | > /---------------------------------\ > H Optional DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (with set Flow label) | > +---------------------------------+ > > And then the ingress node needs to re-encapsulate as > > > > +---------------------------------+ > > | | > > | DetNet Flow | > > | Payload | > > | | > > /---------------------------------\ > > H DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (with set Flow label) | > +=================================+ > > | Routing header | > > /---------------------------------\ > > H DetNet DstOpt Hdr H > > \---------------------------------/ > > | IPv6 header | > > | (with set Flow label) | > > +---------------------------------+ > > This creates a duplication of the DetNet Destination Option. > > There are alternatives > > > a) whereby the packet is tunneled from the source to the detnet ingress, > and based on its state the DetNet ingress accepts the packet, processes it > and then resends it. The tunneled version of this could be: > > +---------------------------------+ > | | > | DetNet Flow | > | Payload | > | | > +---------------------------------+ > | IPv6 header | > | (dest = final destination) | > /=================================\ > H Optional DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (dest = DetNet ingress edge) | > | (with set Flow label) | > +---------------------------------+ > > Which allows the ingress to tunnel to the egress as follows: > +---------------------------------+ > | | > | DetNet Flow | > | Payload | > | | > +---------------------------------+ > | IPv6 header | > | (to final destination) | > +=================================+ > > | Routing header | > > /---------------------------------\ > H Optional DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (dest = DetNet egress edge) | > | (with set Flow label) | > +---------------------------------+ > > > > b) whereby the PREF is done by the end nodes and the tunnel is transport > only, meaning that there are 2 tunnels A and B and that the source sends > twice a packet like this: > > +---------------------------------+ > | | > | DetNet Flow | > | Payload | > | | > /---------------------------------\ > H Optional DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (dest = DetNet ingress edge X)| > | (with set Flow label) | > +---------------------------------+ > > And then the ingress node needs to re-encapsulate as > > > > +---------------------------------+ > > | | > > | DetNet Flow | > > | Payload | > > | | > > /---------------------------------\ > > H DetNet DstOpt Hdr H > \---------------------------------/ > | IPv6 header | > | (dest = final destination) | > | (with set Flow label) | > +=================================+ > > | Routing header | > > +---------------------------------+ > > | IPv6 header | > > | (dest = DetNet egress edge X) | > > | (with set Flow label) | > > +---------------------------------+ > > Cheers, > > Pascal > > > > ---------- > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > ------------16170c7918341de27d39d32005 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Pascal/all,

At the last interim a proposa= l was made to simplify IP processing, at least for the initial detnet solut= ion, by leaving PREF to the subnet/transport layers (i.e., TSN and MPLS) an= d providing DetNet flow identification based on typical IP 5-tuple perhaps = + dscp. This approach has several benefits beyond simplification, notably i= t will work for both ipv4 and IPv6, and doesn't require any modification to= encapsulation / formats.

It would be really valuable t= o get feedback from the whole working group if this simplification is accep= table or has unacceptable limitations.

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthub= ert)" <pthubert@cisco.com> wrote:

Dear all

 

= This is about the IPv6 encapsulation and more precisely

=  

            &nb=
sp;           Theref=
ore, if a DetNet-aware end system only
   inserted the DetNet Destination Option into the IPv6 but =
e.g., a
   DetNet Edge node is configured to enforce an explicit rou=
te for the
   IPv6 packet using a source routing header, then it has no=
 other
   possibility than add an outer tunneling IPv6 header with =
required
   extension headers in it.  The processing of IPv6 pac=
kets in a DetNet
   Edge node is discussed further in Section 6.4.1.

=  

=  

= With the current spec, a source sends a DetNet packet as<= /p>

 

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          /-----------------= ----------------\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

= And then the ingress node needs to re-encapsulate as

 
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        |     =
;      DetNet Flow     &n=
bsp;     |
           &nbs=
p;        |     =
;        Payload    =
         |
            &nb=
sp;       |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

           &nbs=
p;        \-----------------------------=
----/
           &nbs=
p;        |     =
;     IPv6 header      &n=
bsp;     |
            &nb=
sp;       |     (wit=
h set Flow label)       |
           &nbs=
p;        +-------------------------=
--------+

=  

= This creates a duplication of the DetNet Destination Option.

=  

= There are alternatives

=  

a)  whereby the packet is tunneled from the source to the detnet ingres= s, and based on its state the DetNet ingress accepts the packet, processes = it and then resends it. The tunneled version of this could be:

=  

=

         &nbs= p;          +--------= -------------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D final destination)    |

         &nbs= p;          /=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet ingress edge)  |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

=  

= Which allows the ingress to tunnel to the egress as follows:

=

         &nbs= p;          +--------= -------------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   &nbs= p;  (to final destination)     |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        /-----------------------------=
----\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet egress edge)   |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

 

b)  whereby the PREF is done by the end nodes and the tunnel is transpo= rt only, meaning that there are 2 tunnels A and B and that the source sends= twice a packet like this:

 

         &nbs= p;          +-------------= --------------------+

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          |   = ;        DetNet Flow   &n= bsp;       |

         &nbs= p;          |   = ;          Payload  =            |

         &nbs= p;          |   = ;            &n= bsp;            = ;     |

         &nbs= p;          /-----------------= ----------------\

         &nbs= p;          H   Opti= onal DetNet DstOpt Hdr    H

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D DetNet ingress edge X)|

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +-------------= --------------------+

 

= And then the ingress node needs to re-encapsulate as

 
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        |     =
;      DetNet Flow     &n=
bsp;     |
           &nbs=
p;        |     =
;        Payload    =
         |
            &nb=
sp;       |     =
;            &n=
bsp;            =
;   |
           &nbs=
p;        /-----------------------------=
----\
           &nbs=
p;        H     =
;   DetNet DstOpt Hdr        H=

         &nbs= p;          \-----------------= ----------------/

         &nbs= p;          |   = ;       IPv6 header    &n= bsp;       |

         &nbs= p;          |   (des= t =3D final destination)    |

         &nbs= p;          |   = ;  (with set Flow label)       |

         &nbs= p;          +=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D+

           &nbs=
p;        |     =
;     Routing header      =
;   |
           &nbs=
p;        +-------------------------=
--------+
           &nbs=
p;        |     =
;     IPv6 header      &n=
bsp;     |
           &nbs=
p;        |   (dest =3D DetNet=
 egress edge X) |
            &nb=
sp;       |     (wit=
h set Flow label)       |
           &nbs=
p;        +-------------------------=
--------+

 

Cheers,

 

Pascal

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

------------16170c7918341de27d39d32005-- From nobody Wed Feb 7 08:18:19 2018 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 5B9201243FE; Wed, 7 Feb 2018 08:18:18 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151802029825.4893.12024663690137951599@ietfa.amsl.com> Date: Wed, 07 Feb 2018 08:18:18 -0800 Archived-At: Subject: [Detnet] Deterministic Networking (detnet) WG Virtual Meeting: 2018-02-14 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 07 Feb 2018 16:18:18 -0000 The Deterministic Networking (detnet) Working Group will hold a virtual interim meeting on 2018-02-14 from 15:00 to 17:00 GMT. Agenda: We are planning to hold our third virtual interim to discuss the DetNet Data Plane document, https://tools.ietf.org/html/draft-ietf-detnet-dp-sol [1]. The intent is to continue working through open issues on the draft based on revision 01 and where we left off at the previous virtual interims. Contributions on multiple open items were encouraged at the last interim [5]. The main focus of this interim is to discuss those contributions. The meeting will be held February 14 at 1500GMT. We are aiming for a 90 minute meeting, but are scheduling to allow 30 minutes of extra discussion time if needed. Webex details will be announced when available. The agenda is less formal than our normal meetings and is: - Administrativa (chairs) - Draft status update (authors) - Contributions to address open issues (contributors) - Next steps, including future meetings [1] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 [2] IETF 100 open issues: https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/ [3] IETF 100 open issues - PREF: https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/ [4] 1st DetNet Interim: https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet [5] 2nd DetNet Interim: https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet Note that low participation is expected from Asia due to the Chinese New Year; therefore, this slot has been chosen by the main contributors for this meeting. Thank you, DetNet WG Chairs Information about remote participation: WebEx details will be announced on the DETNET Mailing List From nobody Thu Feb 8 00:49:25 2018 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 56BCF12D86D for ; Thu, 8 Feb 2018 00:49:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 OVa4aoUg4Tuw for ; Thu, 8 Feb 2018 00:49:21 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 C850E120726 for ; Thu, 8 Feb 2018 00:49:20 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x20so3324510lff.6 for ; Thu, 08 Feb 2018 00:49:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=rS29/0dTT8MGrmRU18wpu8gjhhrETzLA3L/RGnkllQU=; b=KfB9AFKEJooAXFsWGWebhezLNym2aFNA9gfqxpCemFyCzedfi63mSOMsPcPnVTwymk glnODXlXjQG+yTSGku8j5Z8RptFSE8X/v/hApv/MYvdnlROD4fkQGDn04gayVLPUhtbE +ah4c8BLBtOgRAxzAikY+hvGiGL75a67h/hEOlKND4/lO4xmllomZo1V7oMJ2CDFBKGm QCKWHyUNvhjEUn8Hgs8mH8nZDgUOk0AFUD3ziRXYpvAw6kSLWfiuLBMyNqViY/g8IJ7C k66TpkxMV5oekf1svccnNhtuJa8QsAG0us0tWzFqijfP6sAJhEw7p0pREpCy+SWoxT7b FSPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=rS29/0dTT8MGrmRU18wpu8gjhhrETzLA3L/RGnkllQU=; b=T4D1nIzJuO70E79w5lVRtTgI53Lx4+YeP+4Y72D8068t4WynwQf2KTWWrmPY+L9qGP Gs6sR/m+OvCE/dVIolY8uHuE3mGTjIm53JjcGGs7O19YMk5NRhDkO1/ICzILf16Fpwbo nv8CXqpOD9KMyyz2/vlbHAAKpRyHgMlwdQ505jJ70zpmS09YkLDf+myFL6J73MgbssIO Bqn54H2IUkoOwor7LeyBoOSchqubiJgorjFVXesRkx5pFJyNWHfiwBRuxIo+P7qRNnX4 FVcQtH7cJHXk26I6jI4v5zyduSw8xzOad2tOc+uZ4/wVHlWzcFUD4mp+A8GBl4vEfG5k Sk2Q== X-Gm-Message-State: APf1xPCAk8X9nOl1iszpMFC7SndE1c6VRcNPOJZPc8VevDtAlB1/o7/P LmbyHXIfkC7AEv7YWeiqB9xZ2g== X-Google-Smtp-Source: AH8x227XNo1+o0hoimArTY4a/CsEXuy/wSgbpZ2YkbJk00W7PC0LY1SGcmMC/YP5dcyI8bDgQEV6Jw== X-Received: by 10.25.202.9 with SMTP id a9mr6200829lfg.144.1518079758561; Thu, 08 Feb 2018 00:49:18 -0800 (PST) Received: from JOKO (81-175-169-204.co.dnainternet.fi. [81.175.169.204]) by smtp.gmail.com with ESMTPSA id z14sm690641ljc.23.2018.02.08.00.49.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Feb 2018 00:49:17 -0800 (PST) From: "Jouni" To: "'Pascal Thubert \(pthubert\)'" , References: In-Reply-To: Date: Thu, 8 Feb 2018 10:49:16 +0200 Message-ID: <220801d3a0b9$b441ee50$1cc5caf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_2209_01D3A0CA.77CF0410" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQD5O4QjESRxtG/4YhDnUM8lkFE3YKVO+flg Content-Language: en-us Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 08:49:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_2209_01D3A0CA.77CF0410 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pascal, Thanks for reading the draft and elaborating the option handling further. In the current draft Section 6.4.1 elaborates handling/processing of options further than in the introductory part of the options and packet formats. The alternative a) below is already described in the draft to some extent - thus I fully agree. The alternative b) would also fit but there is no explicit description for it yet - again I fully agree. The figure 11 is heading exactly where your alternatives point at. Thnaks, jouni From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Wednesday, February 7, 2018 15:27 PM To: detnet@ietf.org Subject: [Detnet] IPv6 encapsulation in dataplane doc Dear all This is about the IPv6 encapsulation and more precisely Therefore, if a DetNet-aware end system only inserted the DetNet Destination Option into the IPv6 but e.g., a DetNet Edge node is configured to enforce an explicit route for the IPv6 packet using a source routing header, then it has no other possibility than add an outer tunneling IPv6 header with required extension headers in it. The processing of IPv6 packets in a DetNet Edge node is discussed further in Section 6.4.1 . With the current spec, a source sends a DetNet packet as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +=================================+ | Routing header | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ This creates a duplication of the DetNet Destination Option. There are alternatives a) whereby the packet is tunneled from the source to the detnet ingress, and based on its state the DetNet ingress accepts the packet, processes it and then resends it. The tunneled version of this could be: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (dest = final destination) | /=================================\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet ingress edge) | | (with set Flow label) | +---------------------------------+ Which allows the ingress to tunnel to the egress as follows: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (to final destination) | +=================================+ | Routing header | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet egress edge) | | (with set Flow label) | +---------------------------------+ b) whereby the PREF is done by the end nodes and the tunnel is transport only, meaning that there are 2 tunnels A and B and that the source sends twice a packet like this: +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet ingress edge X)| | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = final destination) | | (with set Flow label) | +=================================+ | Routing header | +---------------------------------+ | IPv6 header | | (dest = DetNet egress edge X) | | (with set Flow label) | +---------------------------------+ Cheers, Pascal ------=_NextPart_000_2209_01D3A0CA.77CF0410 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Pascal,

 

Thanks for reading the = draft and elaborating the option handling further. In the current draft = Section 6.4.1 elaborates handling/processing of options further than in = the introductory part of the options and packet formats. The alternative = a) below is already described in the draft to some extent – thus I = fully agree. The alternative b) would also fit but there is no explicit = description for it yet – again I fully agree. The figure 11 is = heading exactly where your alternatives point = at.

 

Thnaks,

        &= nbsp;       jouni

 

From: = detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal = Thubert (pthubert)
Sent: Wednesday, February 7, 2018 15:27 = PM
To: detnet@ietf.org
Subject: [Detnet] IPv6 = encapsulation in dataplane doc

 

Dear = all

 

This is = about the IPv6 encapsulation and more precisely

 

   =
            &=
nbsp;        Therefore, if a =
DetNet-aware end system only
   inserted =
the DetNet Destination Option into the IPv6 but e.g., =
a
   DetNet Edge node is configured to =
enforce an explicit route for the
   IPv6 =
packet using a source routing header, then it has no =
other
   possibility than add an outer =
tunneling IPv6 header with required
   =
extension headers in it.  The processing of IPv6 packets in a =
DetNet
   Edge node is discussed further =
in Section 6.4.1.

 

 

With the current spec, a source = sends a DetNet packet as

 

           &= nbsp;        = +---------------------------------+

           &= nbsp;      =   |          =             &= nbsp;          = |

           &= nbsp;        = |           DetNet = Flow           = |

           &= nbsp;        = |            = = Payload           =   |

           &= nbsp;        = |            =             &= nbsp;        = |

           &= nbsp;        = /---------------------------------\

           &= nbsp;        H   Optional = DetNet DstOpt Hdr    H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +---------------------------------+

 

And then the ingress node needs to = re-encapsulate = as

 
  &nbs=
p;            =
;     =
+---------------------------------+
  &nbs=
p;            =
;     =
|            =
            &=
nbsp;        =
|
        &n=
bsp;           =
|           DetNet =
Flow           =
|
        &n=
bsp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   =
|
        &n=
bsp;           =
/---------------------------------\
  &nbs=
p;            =
;     H        =
DetNet DstOpt Hdr        =
H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

   =
            &=
nbsp;    =
|          Routing =
header         =
|
        &n=
bsp;           =
/---------------------------------\
  &nbs=
p;            =
;     H        =
DetNet DstOpt Hdr        =
H
        &n=
bsp;           =
\---------------------------------/
  &nbs=
p;            =
;     =
|          IPv6 =
header            =
|
         =
           | =
    (with set Flow =
label)       =
|
        &n=
bsp;           =
+---------------------------------+

 

This creates a duplication of the = DetNet Destination Option.

 

There are alternatives =

 

a)  whereby the packet is tunneled from = the source to the detnet ingress, and based on its state the DetNet = ingress accepts the packet, processes it and then resends it. The = tunneled version of this could be:

 

 

           &= nbsp;        +-------------------= --------------+

           &= nbsp;      =   |          =             &= nbsp;          = |

           &= nbsp;        = |           DetNet = Flow           = |

           &= nbsp;        = |            = = Payload           =   |

           &= nbsp;        = |            =             &= nbsp;        = |

           &= nbsp;        = +---------------------------------+

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   (dest =3D = final destination)    |

           &= nbsp;        = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D\

           &= nbsp;        H   Optional = DetNet DstOpt Hdr    H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   (dest =3D = DetNet ingress edge)  |

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +---------------------------------+

 

Which allows the ingress to tunnel = to the egress as follows:

 

           &= nbsp;        +-------------------= --------------+

           &= nbsp;      =   |          =             &= nbsp;          = |

           &= nbsp;        = |           DetNet = Flow           = |

           &= nbsp;        = |            = = Payload           =   |

           &= nbsp;        = |            =             &= nbsp;        = |

           &= nbsp;        = +---------------------------------+

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   =    (to final destination)     = |

           &= nbsp;        = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

   =
            &=
nbsp;    =
|          Routing =
header         =
|
        &n=
bsp;           =
/---------------------------------\

           &= nbsp;        H   Optional = DetNet DstOpt Hdr    H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   (dest =3D = DetNet egress edge)   |

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +---------------------------------+

 

 

b)  whereby the PREF is done by the end = nodes and the tunnel is transport only, meaning that there are 2 tunnels = A and B and that the source sends twice a packet like = this:

 

           &= nbsp;        = +---------------------------------+

           &= nbsp;      =   |          =             &= nbsp;          = |

           &= nbsp;        = |           DetNet = Flow           = |

           &= nbsp;        = |            = = Payload           =   |

           &= nbsp;        = |            =             &= nbsp;        = |

           &= nbsp;        = /---------------------------------\

           &= nbsp;        H   Optional = DetNet DstOpt Hdr    H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   (dest =3D = DetNet ingress edge X)|

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +---------------------------------+

 

And then the ingress node needs to = re-encapsulate = as

 
  &nbs=
p;            =
;     =
+---------------------------------+
  &nbs=
p;            =
;     =
|            =
            &=
nbsp;        =
|
        &n=
bsp;           =
|           DetNet =
Flow           =
|
        &n=
bsp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   =
|
        &n=
bsp;           =
/---------------------------------\
  &nbs=
p;            =
;     H        =
DetNet DstOpt Hdr        =
H

           &= nbsp;        = \---------------------------------/

           &= nbsp;        = |          IPv6 = header            = |

           &= nbsp;        |   (dest =3D = final destination)    |

           &= nbsp;        = |     (with set Flow = label)       |

           &= nbsp;        = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

   =
            &=
nbsp;    =
|          Routing =
header         =
|
        &n=
bsp;           =
+---------------------------------+
  &nbs=
p;            =
;     =
|          IPv6 =
header            =
|
        &n=
bsp;           |  =
 (dest =3D DetNet egress edge X) =
|
         =
           | =
    (with set Flow =
label)       =
|
        &n=
bsp;           =
+---------------------------------+

 

Cheers,

 

Pascal

------=_NextPart_000_2209_01D3A0CA.77CF0410-- From nobody Thu Feb 8 01:08:19 2018 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 B157D12421A for ; Thu, 8 Feb 2018 01:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 BhIEOsrzg4u8 for ; Thu, 8 Feb 2018 01:08:14 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 0DE261204DA for ; Thu, 8 Feb 2018 01:08:14 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id f136so5351736lff.8 for ; Thu, 08 Feb 2018 01:08:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=0bL4KJMTmqElGXlUNJcDYl5q3BUcLiAJN1S7mutIc/A=; b=gPKyXHR1icfidmb7meqB/Xxv6zmPwo6u9HWivGJqtI1k8+t1ySprK5+aVtRx7v+Dl0 ODQXu2I+E6bURkroUtxsa1NcNnkPv7alEjTq/SBR+izZwKl+V8FVdE4cPAFHyPk6q3U+ vCgICiw363Ga/FFzie/b8mHhr+KOCY8//Ykv3nNwH65Z2n2kzNHhY9/sNMiA5/JzWB3v 3IJNCozx4SF9XfuDhae83GbZQ9V+F/IkKngFlvbx7euAbdRv4sl4Qo0ZZ/e4zK03x7hi csVo5FpV4ltjaf549eF0/mEplu3Z6NlKyUH0s8/eF0zhSK2qYp2cIRfq+XvbpxUnDyZx zFgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=0bL4KJMTmqElGXlUNJcDYl5q3BUcLiAJN1S7mutIc/A=; b=Z3kgwNEFnnFbZgtIcMNmf4KPRA0EcJg7h+ndNVjoXw37KrlCC3Pcf3B/40DaWJh/1w NUBM7avI/m8joDRYrAQAUUDIqTHAK6ZoKw9vkTmfoz345zuRSqAtOzyHHAGnMbCgw6H9 bc+WGq0wzsM7TkuJmNBk4n4mN+fjlMsZZDN4YcedFqCSUIEkUEnGhDsrxtLi12ukMe5g GYmHe+yrLHkYenapploIRcjVI7U6rWJ/q3jDqM3Tj6GQPoR94LNpaxfzwhkJfikuIjwo AEfBydnfzneSOxm6WTg9my+gWfA/PNWwzfd8+RMAQMeLz1pKmk8H/07sFnEbSBOUw02E NGSw== X-Gm-Message-State: APf1xPAP/8Ex65YboKHnlEsIwyp1h89/zfjPA7KdJ3fVFFgRxRg8Rebn m5I9fGLWjZfa+BfjfcZVsTZMMg== X-Google-Smtp-Source: AH8x225Tz5Y6BSSqolZpL/lWhrD+xH+O8JCyud/VOqh70738sMC4H+WtldZX59qlA2NVMa9tv7L8yg== X-Received: by 10.25.210.11 with SMTP id j11mr6302lfg.42.1518080891976; Thu, 08 Feb 2018 01:08:11 -0800 (PST) Received: from JOKO (81-175-169-204.co.dnainternet.fi. [81.175.169.204]) by smtp.gmail.com with ESMTPSA id w21sm747934lfi.86.2018.02.08.01.08.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Feb 2018 01:08:10 -0800 (PST) From: "Jouni" To: "'Lou Berger'" , "'Pascal Thubert \(pthubert\)'" , References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Thu, 8 Feb 2018 11:08:09 +0200 Message-ID: <22c101d3a0bc$5795b080$06c11180$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_22C2_01D3A0CD.1B26BDE0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQD5O4QjESRxtG/4YhDnUM8lkFE3YADceJ0bpUgYq4A= Content-Language: en-us Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 09:08:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_22C2_01D3A0CD.1B26BDE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Yes, we discussed this to an extent in the last call. I've been thinking this a bit more lately (cross country skiing conditions have been great thus you got a lot of time while on the skiing tracks ;) Few concerns/points to think I see here are: * End systems cannot participate to DetNet service layer packet elimination & duplication business. If they still do e.g. using DetNet DstOpt that is separate from subnet/transport layer provided service. * Different subnet/transport layer segments in the DetNet domain are likely to use their own sequencing and duplication & elimination solutions. I am not sure how independent those will be e.g., is the sequence numbering unified across or only per segment. The former is not IMO easy and the latter easily reduces to single points between segments to handle number book keeping properly. Regardless the above I am keen to explore this alternative approach.. - Jouni From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, February 7, 2018 17:00 PM To: Pascal Thubert (pthubert) ; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Pascal/all, At the last interim a proposal was made to simplify IP processing, at least for the initial detnet solution, by leaving PREF to the subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow identification based on typical IP 5-tuple perhaps + dscp. This approach has several benefits beyond simplification, notably it will work for both ipv4 and IPv6, and doesn't require any modification to encapsulation / formats. It would be really valuable to get feedback from the whole working group if this simplification is acceptable or has unacceptable limitations. Lou On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" > wrote: Dear all This is about the IPv6 encapsulation and more precisely Therefore, if a DetNet-aware end system only inserted the DetNet Destination Option into the IPv6 but e.g., a DetNet Edge node is configured to enforce an explicit route for the IPv6 packet using a source routing header, then it has no other possibility than add an outer tunneling IPv6 header with required extension headers in it. The processing of IPv6 packets in a DetNet Edge node is discussed further in Section 6.4.1 . With the current spec, a source sends a DetNet packet as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +=================================+ | Routing header | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ This creates a duplication of the DetNet Destination Option. There are alternatives a) whereby the packet is tunneled from the source to the detnet ingress, and based on its state the DetNet ingress accepts the packet, processes it and then resends it. The tunneled version of this could be: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (dest = final destination) | /=================================\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet ingress edge) | | (with set Flow label) | +---------------------------------+ Which allows the ingress to tunnel to the egress as follows: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (to final destination) | +=================================+ | Routing header | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet egress edge) | | (with set Flow label) | +---------------------------------+ b) whereby the PREF is done by the end nodes and the tunnel is transport only, meaning that there are 2 tunnels A and B and that the source sends twice a packet like this: +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = DetNet ingress edge X)| | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest = final destination) | | (with set Flow label) | +=================================+ | Routing header | +---------------------------------+ | IPv6 header | | (dest = DetNet egress edge X) | | (with set Flow label) | +---------------------------------+ Cheers, Pascal _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet ------=_NextPart_000_22C2_01D3A0CD.1B26BDE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Yes, we discussed this = to an extent in the last call. I’ve been thinking this a bit more = lately (cross country skiing conditions have been great thus you got a = lot of time while on the skiing tracks ;) Few concerns/points to think I = see here are:

* End systems cannot participate to DetNet = service layer packet elimination & duplication business. If they = still do e.g. using DetNet DstOpt that is separate from subnet/transport = layer provided service.

* Different subnet/transport layer segments in = the DetNet domain are likely to use their own sequencing and duplication = & elimination solutions. I am not sure how independent those will be = e.g., is the sequence numbering unified across or only per segment. The = former is not IMO easy and the latter easily reduces to single points = between segments to handle number book keeping properly. =  

 

Regardless the above I = am keen to explore this alternative approach..

 

-          = Jouni

 

 

From: = detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou = Berger
Sent: Wednesday, February 7, 2018 17:00 = PM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; = detnet@ietf.org
Subject: Re: [Detnet] IPv6 encapsulation in = dataplane doc

 

Pascal/all,

At the last interim a proposal = was made to simplify IP processing, at least for the initial detnet = solution, by leaving PREF to the subnet/transport layers (i.e., TSN and = MPLS) and providing DetNet flow identification based on typical IP = 5-tuple perhaps + dscp. This approach has several benefits beyond = simplification, notably it will work for both ipv4 and IPv6, and doesn't = require any modification to encapsulation / = formats.

It would be really valuable to = get feedback from the whole working group if this simplification is = acceptable or has unacceptable limitations.

Lou

On = February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" <pthubert@cisco.com> = wrote:

Dear = all

 

This is about the IPv6 = encapsulation and more precisely

 

   =
            &=
nbsp;        Therefore, if a =
DetNet-aware end system only
   inserted the DetNet Destination =
Option into the IPv6 but e.g., a
   DetNet Edge node is configured to =
enforce an explicit route for the
   IPv6 packet using a source routing =
header, then it has no other
   possibility than add an outer =
tunneling IPv6 header with required
   extension headers in it.  The =
processing of IPv6 packets in a DetNet
   Edge node is discussed further in Section 6.4.1.

 

 

With the current spec, a = source sends a DetNet packet as

 

         &= nbsp;          = +---------------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = /---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

And then the ingress = node needs to re-encapsulate as

 
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|            =
            &=
nbsp;        =
|
        &nb=
sp;           =
|           DetNet =
Flow           =
|
        &nb=
sp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   |
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H
        &nb=
sp;           =
\---------------------------------/
        &nb=
sp;           =
|          IPv6 =
header            =
|
         =
           | =
    (with set Flow =
label)       =
|
        &nb=
sp;           =
+---------------------------------+

 

This creates a = duplication of the DetNet Destination Option.

 

There are alternatives =

 

a)  whereby the packet is = tunneled from the source to the detnet ingress, and based on its state = the DetNet ingress accepts the packet, processes it and then resends it. = The tunneled version of this could be:

 

         &= nbsp;          +-------= --------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = +---------------------------------+

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D final destination)    |

         &= nbsp;          = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet ingress edge)  |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

Which allows the ingress = to tunnel to the egress as follows:

         &= nbsp;          +-------= --------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = +---------------------------------+

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |      (to final = destination)     |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
/---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet egress edge)   |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

 

b)  whereby the PREF is done = by the end nodes and the tunnel is transport only, meaning that there = are 2 tunnels A and B and that the source sends twice a packet like = this:

 

         &= nbsp;          = +---------------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = /---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet ingress edge X)|

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

And then the ingress = node needs to re-encapsulate as

 
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|            =
            &=
nbsp;        =
|
        &nb=
sp;           =
|           DetNet =
Flow           =
|
        &nb=
sp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   |
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D final destination)    |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|          IPv6 =
header            =
|
        &nb=
sp;           |  =
 (dest =3D DetNet egress edge X) =
|
         =
           | =
    (with set Flow =
label)       =
|
        &nb=
sp;           =
+---------------------------------+

 

Cheers,

 

Pascal

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

------=_NextPart_000_22C2_01D3A0CD.1B26BDE0-- From nobody Thu Feb 8 02:46:15 2018 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 63D3112D941 for ; Thu, 8 Feb 2018 02:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 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, URIBL_BLOCKED=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 pfMGD_2GA3Kc for ; Thu, 8 Feb 2018 02:46:11 -0800 (PST) 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 ACF4712D893 for ; Thu, 8 Feb 2018 02:46:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=79183; q=dns/txt; s=iport; t=1518086770; x=1519296370; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=J+QA5JbYiFN9jDCNCNoKR+rCETmQqvYrXxxBi+gzi6E=; b=kiS7Y4KH9Mxq6Pd9gHrjsdWEBYvdh8ZXgsFeQjfsIuMVZ+cMekK+XerL d8M5q8EwH6HI9fke/Ml5ioIxH1A4lFUPpnqq02ZxgCEIcoC/XPqOl5jb6 yWrea6heawe8tjWz5ll8dSlol7KhuKNgY74Qw2Wr6ULr5uKUf6XQzphdu 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CwAAA+KXxa/4kNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZeGZwKAqNf44mggKJF45BFYIAAwoYAQqESU8CgmhUGAECAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEEAQErGicbAgEIEQQBASEBBgchBgsUCQgBAQQBEggTiTZMA?= =?us-ascii?q?xUQsgqBQoF+g3kNgTGCCgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EdYIVgVeBaII?= =?us-ascii?q?ggQ6Ca0QBAQIBgTYcUoUmIAWKaogvkF01CQKIHIQFhFKEfoInZ4lZh2CNe0iJG?= =?us-ascii?q?wIRGQGBOwEfOSWBK3AVPYJGCYRtAXgBAYxtgRcBAQE?= X-IronPort-AV: E=Sophos; i="5.46,478,1511827200"; d="scan'208,217"; a="67482189" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 10:46:09 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w18Ak84E025936 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 8 Feb 2018 10:46:08 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 8 Feb 2018 04:46:08 -0600 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.1320.000; Thu, 8 Feb 2018 04:46:08 -0600 From: "Pascal Thubert (pthubert)" To: Jouni , "'Lou Berger'" , "detnet@ietf.org" Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQAP298AACYDgIAADDxBEA== Date: Thu, 8 Feb 2018 10:45:55 +0000 Deferred-Delivery: Thu, 8 Feb 2018 10:45:41 +0000 Message-ID: <80c83125729f42beb2c55072ca1e80e3@XCH-RCD-001.cisco.com> References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> In-Reply-To: <22c101d3a0bc$5795b080$06c11180$@gmail.com> 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.228.216.11] Content-Type: multipart/alternative; boundary="_000_80c83125729f42beb2c55072ca1e80e3XCHRCD001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 10:46:14 -0000 --_000_80c83125729f42beb2c55072ca1e80e3XCHRCD001ciscocom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I fully agree, Jouni ; For your first point: In the case of wireless, PRP (a form of PREF) is a cr= itical feature for industrial deployments; this is shipping and deployed to= day. The link that needs protection the most is the first hop (the UNI from= /to the device) since it is over Wi-Fi. If the PREF starts at the network e= dge (say the controller), then most of the benefit is lost. So DetNet must = enable E2E Services, in particular over IPv4 which is dominant in industria= l use cases. What DetNet could bring to the art could that a single wireles= s transmission received by 2 APs end up on 2 parallel end-to-end paths. For your second point: there are a number of potential issues if the sequen= cing is not done by the source end point. If a packet is received at one ed= ge and not at another, then the sequences will differ over the 2 paths and = reconciliation will be impossible. Packets received out of order at the ing= ress will be delivered out of order at the egress meaning that whatever sup= port for in-order-delivery (IOD) is defeated. My conclusion is that the end points must contribute to the effort. They mu= st stream the data at a reasonable pace, and if Service Layer functions are= expected from the network, they really should indicate the flow ID and th= e sequence number from their perspective. Now what can we expect from current end points? - Existing industrial devices can claim a rough need for a given ra= te but were not necessarily designed to provide guarantees for burstiness i= n DetNet terms. Failure to comply to DetNet terms may cause loss/reclassifi= cation by ingress filtering in the edge router, which would defeat one purp= ose of DetNet for reliability. For a close-to-acceptable sources, one can i= magine a jitter absorption feature at the DetNet ingress edge router. But t= hat also mean an additional latency, which may defeat another purpose of De= tNet of in-time-delivery. - TCP is adverse to DetNet, and will not maintain the optimal rate;= in any case, the sense of sequence that can be inferred from the offset ca= n be defeated by retries. In order to support TCP endpoints, one would pro= bably need to devise a L4-proxy function (ala DLSW) that terminates TCP at = the ingress edge and maps it into something more DetNet friendly. - UDP does not provide sequencing information - this is probably th= e use case for the DetNet Destination Option in the inner header. - Arguably RTP can signal both flow and sequence, but does not have= network coding, does not expect multipath, and I'm not sure if the rate co= ntrol work has gone beyond the research papers. Then again, packets may be = lost or reclassified at the ingress edge. - This leaves rate control (e.g. adaptive bitrate streaming) to the= application layer (typically over HTTP), meaning that each application as = to cover for the network deficiencies in its own ways. Which is sad because= it adds complexity to each and every application, a complexity that is not= the core business of the app and could be handled in common at a lower lay= er. DetNet has the power to simplify the application, remove jitter recovery bu= ffers and the like, by transporting the near-perfect rate in near-perfect t= ime. It would be better that the end points contribution happens without i= mpacting each and every time sensitive application, by providing DetNet Ser= vice Layer functionality at the L4 transport. Flow identification (by port), IOD and duplicate elimination are classical = L4-transport features (e.g. TCP). MP-TCP already distributes packets over d= ifferent paths. It is not a gigantic conceptual step to place DetNet Servic= e Layer features in a L4 transport. If a DetNet friendly transport -to be d= esigned- adds DetNet Service Layer capabilities like PREF and/or network co= ding in the end points, 2 parallel DetNet Transport Layer circuits based on= the discussion at the interim would enable the end-to-end service without = knowing it. So 'd say that the proposal is still useful, but depends on L4 = transport capabilities that would be fully transparent to the DetNet signal= ing and would not use the Destination Option. Alternatively, say we want DetNet to provide the S-level functions, e.g. PR= EF. Considering that we expect that an edge router can read the ports, then= it can figure what the L4 transport can be recognized and that for some tr= ansports, e.g. RTP and the suggested new transport, the edge router can der= ive a sequence from the transport header in a non-ambiguous way. All the best, Pascal From: Jouni [mailto:jouni.nospam@gmail.com] Sent: jeudi 8 f=E9vrier 2018 10:08 To: 'Lou Berger' ; Pascal Thubert (pthubert) ; detnet@ietf.org Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc Hi, Yes, we discussed this to an extent in the last call. I've been thinking th= is a bit more lately (cross country skiing conditions have been great thus = you got a lot of time while on the skiing tracks ;) Few concerns/points to = think I see here are: * End systems cannot participate to DetNet service layer packet elimination= & duplication business. If they still do e.g. using DetNet DstOpt that is = separate from subnet/transport layer provided service. * Different subnet/transport layer segments in the DetNet domain are likely= to use their own sequencing and duplication & elimination solutions. I am = not sure how independent those will be e.g., is the sequence numbering unif= ied across or only per segment. The former is not IMO easy and the latter e= asily reduces to single points between segments to handle number book keepi= ng properly. Regardless the above I am keen to explore this alternative approach.. - Jouni From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, February 7, 2018 17:00 PM To: Pascal Thubert (pthubert) >; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Pascal/all, At the last interim a proposal was made to simplify IP processing, at least= for the initial detnet solution, by leaving PREF to the subnet/transport l= ayers (i.e., TSN and MPLS) and providing DetNet flow identification based o= n typical IP 5-tuple perhaps + dscp. This approach has several benefits bey= ond simplification, notably it will work for both ipv4 and IPv6, and doesn'= t require any modification to encapsulation / formats. It would be really valuable to get feedback from the whole working group if= this simplification is acceptable or has unacceptable limitations. Lou On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" > wrote: Dear all This is about the IPv6 encapsulation and more precisely Therefore, if a DetNet-aware end system only inserted the DetNet Destination Option into the IPv6 but e.g., a DetNet Edge node is configured to enforce an explicit route for the IPv6 packet using a source routing header, then it has no other possibility than add an outer tunneling IPv6 header with required extension headers in it. The processing of IPv6 packets in a DetNet Edge node is discussed further in Section 6.4.1. With the current spec, a source sends a DetNet packet as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ This creates a duplication of the DetNet Destination Option. There are alternatives a) whereby the packet is tunneled from the source to the detnet ingress, a= nd based on its state the DetNet ingress accepts the packet, processes it a= nd then resends it. The tunneled version of this could be: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (dest =3D final destination) | /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge) | | (with set Flow label) | +---------------------------------+ Which allows the ingress to tunnel to the egress as follows: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (to final destination) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet egress edge) | | (with set Flow label) | +---------------------------------+ b) whereby the PREF is done by the end nodes and the tunnel is transport o= nly, meaning that there are 2 tunnels A and B and that the source sends twi= ce a packet like this: +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge X)| | (with set Flow label) | +---------------------------------+ And then the ingress node needs to re-encapsulate as +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D final destination) | | (with set Flow label) | +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | +---------------------------------+ | IPv6 header | | (dest =3D DetNet egress edge X) | | (with set Flow label) | +---------------------------------+ Cheers, Pascal _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet --_000_80c83125729f42beb2c55072ca1e80e3XCHRCD001ciscocom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I fully ag= ree, Jouni ;

 = ;

For your first point: = In the case of wireless, PRP (a form of PREF) is a critical feature for ind= ustrial deployments; this is shipping and deployed today. The link that nee= ds protection the most is the first hop (the UNI from/to the device) since it is over Wi-Fi. If the PREF start= s at the network edge (say the controller), then most of the benefit is los= t. So DetNet must enable E2E Services, in particular over IPv4 which is dom= inant in industrial use cases. What DetNet could bring to the art could that a single wireless transmission re= ceived by 2 APs end up on 2 parallel end-to-end paths.

 

For your second point:= there are a number of potential issues if the sequencing is not done by th= e source end point. If a packet is received at one edge and not at another,= then the sequences will differ over the 2 paths and reconciliation will be impossible. Packets received out of= order at the ingress will be delivered out of order at the egress meaning = that whatever support for in-order-delivery (IOD) is defeated.

 

My conclusion is that = the end points must contribute to the effort. They must stream the data at = a reasonable pace, and if Service Layer functions are expected from the net= work,  they really should indicate the flow ID and the sequence number from their perspective.<= /p>

 

Now what can we expect= from current end points?

 

-&n= bsp;        Existing indus= trial devices can claim a rough need for a given rate but were not necessar= ily designed to provide guarantees for burstiness in DetNet terms. Failure = to comply to DetNet terms may cause loss/reclassification by ingress filtering in the edge router, which would= defeat one purpose of DetNet for reliability. For a close-to-acceptable so= urces, one can imagine a jitter absorption feature at the DetNet ingress ed= ge router. But that also mean an additional latency, which may defeat another purpose of DetNet of in-time-= delivery.

-&n= bsp;        TCP is adverse= to DetNet, and will not maintain the optimal rate; in any case, the sense = of sequence that can be inferred from the offset can be defeated by retries= .  In order to support TCP endpoints, one would probably need to devise a L4-proxy function (ala DLSW) that term= inates TCP at the ingress edge and maps it into something more DetNet frien= dly.

-&n= bsp;        UDP does not p= rovide sequencing information - this is probably the use case for the DetNe= t Destination Option in the inner header.

-&n= bsp;        Arguably RTP c= an signal both flow and sequence, but does not have network coding, does no= t expect multipath, and I’m not sure if the rate control work has gon= e beyond the research papers. Then again, packets may be lost or reclassified at the ingress edge.=

-&n= bsp;        This leaves ra= te control (e.g. adaptive bitrate streaming) to the application layer (typi= cally over HTTP), meaning that each application as to cover for the network= deficiencies in its own ways. Which is sad because it adds complexity to each and every application, a complex= ity that is not the core business of the app and could be handled in common= at a lower layer.

 

DetNet has the power t= o simplify the application, remove jitter recovery buffers and the like, by= transporting the near-perfect rate in near-perfect time.  It would be= better that the end points contribution happens without impacting each and every time sensitive application, by pr= oviding DetNet Service Layer functionality at the L4 transport.<= /span>

Flow identification (b= y port), IOD and duplicate elimination are classical L4-transport features = (e.g. TCP). MP-TCP already distributes packets over different paths. It is = not a gigantic conceptual step to place DetNet Service Layer features in a L4 transport. If a DetNet friendly tran= sport -to be designed- adds DetNet Service Layer capabilities like PREF and= /or network coding in the end points, 2 parallel DetNet Transport Layer cir= cuits based on the discussion at the interim would enable the end-to-end service without knowing it. So = 216;d say that the proposal is still useful, but depends on L4 transport ca= pabilities that would be fully transparent to the DetNet signaling and woul= d not use the Destination Option.

 

Alternatively, say we = want DetNet to provide the S-level functions, e.g. PREF. Considering that w= e expect that an edge router can read the ports, then it can figure what th= e L4 transport can be recognized and that for some transports, e.g. RTP and the suggested new transport, the ed= ge router can derive a sequence from the transport header in a non-ambiguou= s way.

 

All the best,

 

Pascal

 

From: Jouni [mai= lto:jouni.nospam@gmail.com]
Sent: jeudi 8 f=E9vrier 2018 10:08
To: 'Lou Berger' <lberger@labn.net>; Pascal Thubert (pthubert)= <pthubert@cisco.com>; detnet@ietf.org
Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc=

 

Hi,

 

Yes, we discussed this to an extent in the last call. I’ve bee= n thinking this a bit more lately (cross country skiing conditions have bee= n great thus you got a lot of time while on the skiing tracks ;) Few concerns/points to think I see here are:

* End systems cannot participate to DetNet service layer packet elim= ination & duplication business. If they still do e.g. using DetNet DstO= pt that is separate from subnet/transport layer provided service.

* Different subnet/transport layer segments in the DetNet domain are= likely to use their own sequencing and duplication & elimination solut= ions. I am not sure how independent those will be e.g., is the sequence numbering unified across or only per segment= . The former is not IMO easy and the latter easily reduces to single points= between segments to handle number book keeping properly.  =

 

Regardless the above I am keen to explore this alternative approach.= .

 

-  = ;       Jouni

 

 

From: detnet [mailto:detnet-bounces@ietf.org= ] On Behalf Of Lou Berger
Sent: Wednesday, February 7, 2018 17:00 PM
To: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc=

 

Pascal/all,

At the last interim a proposal was made to simp= lify IP processing, at least for the initial detnet solution, by leaving PR= EF to the subnet/transport layers (i.e., TSN and MPLS) and providing DetNet= flow identification based on typical IP 5-tuple perhaps + dscp. This approach has several benefits beyond s= implification, notably it will work for both ipv4 and IPv6, and doesn't req= uire any modification to encapsulation / formats.

It would be really valuable to get feedback fro= m the whole working group if this simplification is acceptable or has unacc= eptable limitations.

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)&q= uot; <pthubert@cisco.com> w= rote:

Dear all

 

This is about the IPv6 encapsulati= on and more precisely<= /p>

 

   =
            &nb=
sp;        Therefore, if a DetNet-a=
ware end system only
   =
inserted the DetNet Destination Option into the IPv6 but e.g., a=

   =
DetNet Edge node is configured to enforce an explicit route for the
   =
IPv6 packet using a source routing header, then it has no other<=
/span>
   =
possibility than add an outer tunneling IPv6 header with required
   =
extension headers in it.  The processing of IPv6 packets in a DetNet
   =
Edge node is discussed further in Section 6.4.1.

 

 

With the current spec, a source se= nds a DetNet packet as=

 

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    |        &nb= sp;  DetNet Flow         =   |

   = ;            &n= bsp;    |        &nb= sp;    Payload       &nbs= p;     |<= /span>

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    /---------------------------------\

   = ;            &n= bsp;    H   Optional DetNet DstOpt Hdr  =   H

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +---------------------------------+

 

And then the ingress node needs to= re-encapsulate as

 
  &=
nbsp;           &nbs=
p;     +---------------------------------+=

  &=
nbsp;           &nbs=
p;     |        =
;            &n=
bsp;            |
  &=
nbsp;           &nbs=
p;     |        =
;   DetNet Flow        &n=
bsp;  |
  &=
nbsp;           &nbs=
p;     |        =
;     Payload       =
      |
   =
            &nb=
sp;    |        =
;            &n=
bsp;            |
  &=
nbsp;           &nbs=
p;     /---------------------------------\
  &=
nbsp;           &nbs=
p;     H        DetN=
et DstOpt Hdr        H=

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

  &=
nbsp;           &nbs=
p;     |        =
;  Routing header         |
  &=
nbsp;           &nbs=
p;     /---------------------------------\
  &=
nbsp;           &nbs=
p;     H        DetN=
et DstOpt Hdr        H=

  &=
nbsp;           &nbs=
p;     \---------------------------------/
  &=
nbsp;           &nbs=
p;     |        =
;  IPv6 header         &n=
bsp;  |
  &=
nbsp;            &nb=
sp;    |     (with set Flow label)&=
nbsp;      |
  &=
nbsp;           &nbs=
p;     +---------------------------------+=

 

This creates a duplication of the = DetNet Destination Option.

 

There are alternatives

 

a)  wher= eby the packet is tunneled from the source to the detnet ingress, and based= on its state the DetNet ingress accepts the packet, processes it and then = resends it. The tunneled version of this could be:

 

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    |        &nb= sp;  DetNet Flow         =   |

   = ;            &n= bsp;    |        &nb= sp;    Payload       &nbs= p;     |<= /span>

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |   (dest =3D final destination) &nbs= p;  |

   = ;            &n= bsp;    /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\<= /p>

   = ;            &n= bsp;    H   Optional DetNet DstOpt Hdr  =   H

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |   (dest =3D DetNet ingress edge)  |=

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +---------------------------------+

 

Which allows the ingress to tunnel= to the egress as follows:

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    |        &nb= sp;  DetNet Flow         =   |

   = ;            &n= bsp;    |        &nb= sp;    Payload       &nbs= p;     |<= /span>

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |      (to final destinatio= n)     |<= /span>

   = ;            &n= bsp;    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

  &=
nbsp;           &nbs=
p;     |        =
;  Routing header         |
  &=
nbsp;           &nbs=
p;     /---------------------------------\

   = ;            &n= bsp;    H   Optional DetNet DstOpt Hdr  =   H

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |   (dest =3D DetNet egress edge)  &n= bsp;|

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +---------------------------------+

 

 

b)  wher= eby the PREF is done by the end nodes and the tunnel is transport only, mea= ning that there are 2 tunnels A and B and that the source sends twice a pac= ket like this:

 

   = ;            &n= bsp;    +---------------------------------+

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    |        &nb= sp;  DetNet Flow         =   |

   = ;            &n= bsp;    |        &nb= sp;    Payload       &nbs= p;     |<= /span>

   = ;            &n= bsp;    |        &nb= sp;            =             |=

   = ;            &n= bsp;    /---------------------------------\

   = ;            &n= bsp;    H   Optional DetNet DstOpt Hdr  =   H

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |   (dest =3D DetNet ingress edge X)|

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +---------------------------------+

 

And then the ingress node needs to= re-encapsulate as

 
  &=
nbsp;           &nbs=
p;     +---------------------------------+=

  &=
nbsp;           &nbs=
p;     |        =
;            &n=
bsp;            |
  &=
nbsp;           &nbs=
p;     |        =
;   DetNet Flow        &n=
bsp;  |
  &=
nbsp;           &nbs=
p;     |        =
;     Payload       =
      |
   =
            &nb=
sp;    |        =
;            &n=
bsp;            |
  &=
nbsp;           &nbs=
p;     /---------------------------------\
  &=
nbsp;           &nbs=
p;     H        DetN=
et DstOpt Hdr        H=

   = ;            &n= bsp;    \---------------------------------/

   = ;            &n= bsp;    |        &nb= sp; IPv6 header          =   |

   = ;            &n= bsp;    |   (dest =3D final destination) &nbs= p;  |

   = ;            &n= bsp;    |     (with set Flow label) = ;      |

   = ;            &n= bsp;    +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

  &=
nbsp;           &nbs=
p;     |        =
;  Routing header         |
  &=
nbsp;           &nbs=
p;     +---------------------------------+=

  &=
nbsp;           &nbs=
p;     |        =
;  IPv6 header         &n=
bsp;  |
  &=
nbsp;           &nbs=
p;     |   (dest =3D DetNet egress edge X) |<=
o:p>
  &=
nbsp;            &nb=
sp;    |     (with set Flow label)&=
nbsp;      |
  &=
nbsp;           &nbs=
p;     +---------------------------------+=

 

Cheers,

 

Pascal

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

--_000_80c83125729f42beb2c55072ca1e80e3XCHRCD001ciscocom_-- From nobody Thu Feb 8 06:36:31 2018 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 BCE5412DA03 for ; Thu, 8 Feb 2018 06:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 oGwwNmdIOzKc for ; Thu, 8 Feb 2018 06:36:24 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 DDF6C12D957 for ; Thu, 8 Feb 2018 06:36:23 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id x20so4747383lff.6 for ; Thu, 08 Feb 2018 06:36:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :thread-index:content-language; bh=CgFNf9zYVHi6TRqXs5V54p3wA1V7shq2PaukuhjRP2w=; b=nfM0SVZpkKfpvnxJJuKl1o3CJH2vNMbb3bezGcghUNbfiRuq7JGv9AWcZtgnupez01 lvBQpAh15LrjGhLUOWKi+wK3UFS9iALsWONQzxs5zIDjK5+Qm4JAMD9qX8kVxs41gPT+ B3BEygw0NQ5kjQ2PccEfpJDNhRAik7D4I+K04F5+TJ+An+rFPM0Vl6j6KamgK6T/86eV szgbPzNhEh2dLpGm9WI/fcga3VApSrWe3yBttlakvi1mpOPlS7mcogAYKJly8wiHLoWZ +CuQzvE5RsAhgNhivsUh+1Uio84wn1OdBShS4YqrdV/tWU641ZWeUID2XcIgxe5YBWq9 CZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=CgFNf9zYVHi6TRqXs5V54p3wA1V7shq2PaukuhjRP2w=; b=P+IpMbRO+2Fy5ekTkB3Me1TvWoT/AmtAqF9ATVStZ1B/nOJI4BXvbSzPpvjOFAcM2L sLqVXpKb1/EK+rQx7hNYIgxIaU6fjgZ7i2QDHCQGQrnzhMvvnlDWIrN1Wr1fZLgKxdBZ c2YQnArk3ouT6IGcggpZLRl9/Padnd80oiWrd2zVplHZwA8yyexSUZGQMEBpltnKUK26 iKhVGFaD06EUSCXKmBsYbFpDScaC9NpdM5837YOS7yJBo+lFRgIgZo+yhugLfB+pU/Ml hNTfxLUebGtMrc8pM/5AHe7n+sxmfYnLaPd1iyRLpIigb7fLQDnCmT78ZXVrjL9IRWaT gh+A== X-Gm-Message-State: APf1xPBB/l/YNGNpvziRsAqY9EMVNu/hLlQ+LpJVocq1McjrTDHsjbm9 2uOvl1+wIzSD0FvgyHAetfgBJA== X-Google-Smtp-Source: AH8x2262blcoR6M8CwFY4zAg8o/Xs+rKl9nRfBWVMYfA55CtqTD12xW+4ZSUItnw/3LryF8FLZr1cg== X-Received: by 10.25.24.90 with SMTP id o87mr775556lfi.88.1518100581729; Thu, 08 Feb 2018 06:36:21 -0800 (PST) Received: from JOKO ([83.145.195.18]) by smtp.gmail.com with ESMTPSA id h7sm17548ljf.37.2018.02.08.06.36.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Feb 2018 06:36:21 -0800 (PST) From: "Jouni" To: "'Pascal Thubert \(pthubert\)'" , "'Lou Berger'" , References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <80c83125729f42beb2c55072ca1e80e3@XCH-RCD-001.cisco.com> In-Reply-To: <80c83125729f42beb2c55072ca1e80e3@XCH-RCD-001.cisco.com> Date: Thu, 8 Feb 2018 16:36:16 +0200 Message-ID: <000001d3a0ea$2f57c8f0$8e075ad0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01D3A0FA.F2EA35E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQD5O4QjESRxtG/4YhDnUM8lkFE3YADceJ0bAkifB7cCLlvZQaUkqQFg Content-Language: en-us Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 08 Feb 2018 14:36:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0001_01D3A0FA.F2EA35E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, =20 Thanks for good input (again) and I agree in most parts =96 I do have reservations for L4 solution since it would be per L4 protocol. One clarification to my =94first point=94. In my example the not-mentioned assumption was that the edge node is the first node doing duplication & elimination at the subnet/transport layer. If that DetNet = subnet/transport layer can extended all way to end systems (like with current TSN in = 802.1 space) then some of the issues are relaxed. =20 =20 - Jouni =20 From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: Thursday, February 8, 2018 12:46 PM To: Jouni ; 'Lou Berger' ; detnet@ietf.org Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc =20 I fully agree, Jouni ; =20 For your first point: In the case of wireless, PRP (a form of PREF) is a critical feature for industrial deployments; this is shipping and = deployed today. The link that needs protection the most is the first hop (the UNI from/to the device) since it is over Wi-Fi. If the PREF starts at the network edge (say the controller), then most of the benefit is lost. So DetNet must enable E2E Services, in particular over IPv4 which is = dominant in industrial use cases. What DetNet could bring to the art could that a single wireless transmission received by 2 APs end up on 2 parallel end-to-end paths. =20 For your second point: there are a number of potential issues if the sequencing is not done by the source end point. If a packet is received = at one edge and not at another, then the sequences will differ over the 2 = paths and reconciliation will be impossible. Packets received out of order at = the ingress will be delivered out of order at the egress meaning that = whatever support for in-order-delivery (IOD) is defeated. =20 My conclusion is that the end points must contribute to the effort. They must stream the data at a reasonable pace, and if Service Layer = functions are expected from the network, they really should indicate the flow ID = and the sequence number from their perspective. =20 Now what can we expect from current end points?=20 =20 - Existing industrial devices can claim a rough need for a = given rate but were not necessarily designed to provide guarantees for = burstiness in DetNet terms. Failure to comply to DetNet terms may cause loss/reclassification by ingress filtering in the edge router, which = would defeat one purpose of DetNet for reliability. For a close-to-acceptable sources, one can imagine a jitter absorption feature at the DetNet = ingress edge router. But that also mean an additional latency, which may defeat another purpose of DetNet of in-time-delivery. - TCP is adverse to DetNet, and will not maintain the optimal = rate; in any case, the sense of sequence that can be inferred from the offset = can be defeated by retries. In order to support TCP endpoints, one would probably need to devise a L4-proxy function (ala DLSW) that terminates = TCP at the ingress edge and maps it into something more DetNet friendly. - UDP does not provide sequencing information - this is = probably the use case for the DetNet Destination Option in the inner header. - Arguably RTP can signal both flow and sequence, but does not = have network coding, does not expect multipath, and I=92m not sure if the = rate control work has gone beyond the research papers. Then again, packets = may be lost or reclassified at the ingress edge. - This leaves rate control (e.g. adaptive bitrate streaming) to = the application layer (typically over HTTP), meaning that each application = as to cover for the network deficiencies in its own ways. Which is sad because = it adds complexity to each and every application, a complexity that is not = the core business of the app and could be handled in common at a lower = layer.=20 =20 DetNet has the power to simplify the application, remove jitter recovery buffers and the like, by transporting the near-perfect rate in = near-perfect time. It would be better that the end points contribution happens = without impacting each and every time sensitive application, by providing DetNet Service Layer functionality at the L4 transport. =20 Flow identification (by port), IOD and duplicate elimination are = classical L4-transport features (e.g. TCP). MP-TCP already distributes packets = over different paths. It is not a gigantic conceptual step to place DetNet Service Layer features in a L4 transport. If a DetNet friendly transport = -to be designed- adds DetNet Service Layer capabilities like PREF and/or = network coding in the end points, 2 parallel DetNet Transport Layer circuits = based on the discussion at the interim would enable the end-to-end service = without knowing it. So =91d say that the proposal is still useful, but depends = on L4 transport capabilities that would be fully transparent to the DetNet signaling and would not use the Destination Option.=20 =20 Alternatively, say we want DetNet to provide the S-level functions, e.g. PREF. Considering that we expect that an edge router can read the ports, then it can figure what the L4 transport can be recognized and that for = some transports, e.g. RTP and the suggested new transport, the edge router = can derive a sequence from the transport header in a non-ambiguous way.=20 =20 All the best, =20 Pascal =20 From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: jeudi 8 f=E9vrier 2018 10:08 To: 'Lou Berger' >; Pascal Thubert (pthubert) >; detnet@ietf.org =20 Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc =20 Hi, =20 Yes, we discussed this to an extent in the last call. I=92ve been = thinking this a bit more lately (cross country skiing conditions have been great = thus you got a lot of time while on the skiing tracks ;) Few concerns/points = to think I see here are: * End systems cannot participate to DetNet service layer packet = elimination & duplication business. If they still do e.g. using DetNet DstOpt that = is separate from subnet/transport layer provided service. * Different subnet/transport layer segments in the DetNet domain are = likely to use their own sequencing and duplication & elimination solutions. I = am not sure how independent those will be e.g., is the sequence numbering unified across or only per segment. The former is not IMO easy and the latter easily reduces to single points between segments to handle number book keeping properly. =20 =20 Regardless the above I am keen to explore this alternative approach.. =20 - Jouni =20 =20 From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Lou Berger Sent: Wednesday, February 7, 2018 17:00 PM To: Pascal Thubert (pthubert) >; detnet@ietf.org =20 Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc =20 Pascal/all, At the last interim a proposal was made to simplify IP processing, at = least for the initial detnet solution, by leaving PREF to the subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow identification = based on typical IP 5-tuple perhaps + dscp. This approach has several benefits beyond simplification, notably it will work for both ipv4 and IPv6, and doesn't require any modification to encapsulation / formats. It would be really valuable to get feedback from the whole working group = if this simplification is acceptable or has unacceptable limitations. Lou On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" > wrote: Dear all =20 This is about the IPv6 encapsulation and more precisely =20 Therefore, if a DetNet-aware end system only inserted the DetNet Destination Option into the IPv6 but e.g., a DetNet Edge node is configured to enforce an explicit route for the IPv6 packet using a source routing header, then it has no other possibility than add an outer tunneling IPv6 header with required extension headers in it. The processing of IPv6 packets in a DetNet Edge node is discussed further in Section 6.4.1 = . =20 =20 With the current spec, a source sends a DetNet packet as =20 +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ =20 And then the ingress node needs to re-encapsulate as =20 +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (with set Flow label) | +---------------------------------+ =20 This creates a duplication of the DetNet Destination Option. =20 There are alternatives=20 =20 a) whereby the packet is tunneled from the source to the detnet = ingress, and based on its state the DetNet ingress accepts the packet, processes = it and then resends it. The tunneled version of this could be: =20 +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (dest =3D final destination) | = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge) | | (with set Flow label) | +---------------------------------+ =20 Which allows the ingress to tunnel to the egress as follows: +---------------------------------+ | | | DetNet Flow | | Payload | | | +---------------------------------+ | IPv6 header | | (to final destination) | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet egress edge) | | (with set Flow label) | +---------------------------------+ =20 =20 b) whereby the PREF is done by the end nodes and the tunnel is = transport only, meaning that there are 2 tunnels A and B and that the source sends twice a packet like this: =20 +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H Optional DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D DetNet ingress edge X)| | (with set Flow label) | +---------------------------------+ =20 And then the ingress node needs to re-encapsulate as =20 +---------------------------------+ | | | DetNet Flow | | Payload | | | /---------------------------------\ H DetNet DstOpt Hdr H \---------------------------------/ | IPv6 header | | (dest =3D final destination) | | (with set Flow label) | = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+ | Routing header | +---------------------------------+ | IPv6 header | | (dest =3D DetNet egress edge X) | | (with set Flow label) | +---------------------------------+ =20 Cheers, =20 Pascal _______________________________________________ detnet mailing list detnet@ietf.org =20 https://www.ietf.org/mailman/listinfo/detnet ------=_NextPart_000_0001_01D3A0FA.F2EA35E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Pascal,

 

Thanks for good input = (again) and I agree in most parts – I do have reservations for L4 = solution since it would be per L4 protocol. One clarification to my = ”first point”. In my example the not-mentioned assumption = was that the edge node is the first node doing duplication & = elimination at the subnet/transport layer. If that DetNet = subnet/transport layer can extended all way to end systems (like with = current TSN in 802.1 space) then some of the issues are = relaxed.

 

 

-          = Jouni

 

From: = Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Sent: = Thursday, February 8, 2018 12:46 PM
To: Jouni = <jouni.nospam@gmail.com>; 'Lou Berger' <lberger@labn.net>; = detnet@ietf.org
Subject: RE: [Detnet] IPv6 encapsulation in = dataplane doc

 

I fully agree, = Jouni ;

 

For your first point: In = the case of wireless, PRP (a form of PREF) is a critical feature for = industrial deployments; this is shipping and deployed today. The link = that needs protection the most is the first hop (the UNI from/to the = device) since it is over Wi-Fi. If the PREF starts at the network edge = (say the controller), then most of the benefit is lost. So DetNet must = enable E2E Services, in particular over IPv4 which is dominant in = industrial use cases. What DetNet could bring to the art could that a = single wireless transmission received by 2 APs end up on 2 parallel = end-to-end paths.

 

For your second point: = there are a number of potential issues if the sequencing is not done by = the source end point. If a packet is received at one edge and not at = another, then the sequences will differ over the 2 paths and = reconciliation will be impossible. Packets received out of order at the = ingress will be delivered out of order at the egress meaning that = whatever support for in-order-delivery (IOD) is = defeated.

 

My conclusion is that = the end points must contribute to the effort. They must stream the data = at a reasonable pace, and if Service Layer functions are expected from = the network,  they really should indicate the flow ID and the = sequence number from their perspective.

 

Now what can we expect = from current end points?

 

-          = Existing = industrial devices can claim a rough need for a given rate but were not = necessarily designed to provide guarantees for burstiness in DetNet = terms. Failure to comply to DetNet terms may cause loss/reclassification = by ingress filtering in the edge router, which would defeat one purpose = of DetNet for reliability. For a close-to-acceptable sources, one can = imagine a jitter absorption feature at the DetNet ingress edge router. = But that also mean an additional latency, which may defeat another = purpose of DetNet of in-time-delivery.

-          = TCP is = adverse to DetNet, and will not maintain the optimal rate; in any case, = the sense of sequence that can be inferred from the offset can be = defeated by retries.  In order to support TCP endpoints, one would = probably need to devise a L4-proxy function (ala DLSW) that terminates = TCP at the ingress edge and maps it into something more DetNet = friendly.

-          = UDP does = not provide sequencing information - this is probably the use case for = the DetNet Destination Option in the inner = header.

-          = Arguably = RTP can signal both flow and sequence, but does not have network coding, = does not expect multipath, and I’m not sure if the rate control = work has gone beyond the research papers. Then again, packets may be = lost or reclassified at the ingress edge.

-          = This leaves = rate control (e.g. adaptive bitrate streaming) to the application layer = (typically over HTTP), meaning that each application as to cover for the = network deficiencies in its own ways. Which is sad because it adds = complexity to each and every application, a complexity that is not the = core business of the app and could be handled in common at a lower = layer.

 

DetNet has the power to = simplify the application, remove jitter recovery buffers and the like, = by transporting the near-perfect rate in near-perfect time.  It = would be better that the end points contribution happens without = impacting each and every time sensitive application, by providing DetNet = Service Layer functionality at the L4 transport.

 

Flow identification (by = port), IOD and duplicate elimination are classical L4-transport features = (e.g. TCP). MP-TCP already distributes packets over different paths. It = is not a gigantic conceptual step to place DetNet Service Layer features = in a L4 transport. If a DetNet friendly transport -to be designed- adds = DetNet Service Layer capabilities like PREF and/or network coding in the = end points, 2 parallel DetNet Transport Layer circuits based on the = discussion at the interim would enable the end-to-end service without = knowing it. So ‘d say that the proposal is still useful, but = depends on L4 transport capabilities that would be fully transparent to = the DetNet signaling and would not use the Destination Option. =

 

Alternatively, say we = want DetNet to provide the S-level functions, e.g. PREF. Considering = that we expect that an edge router can read the ports, then it can = figure what the L4 transport can be recognized and that for some = transports, e.g. RTP and the suggested new transport, the edge router = can derive a sequence from the transport header in a non-ambiguous way. =

 

All the = best,

 

Pascal

 

From: = Jouni [mailto:jouni.nospam@gmail.com]=
Sent: jeudi 8 f=E9vrier 2018 10:08
To: 'Lou = Berger' <lberger@labn.net>; Pascal = Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
Subject: = RE: [Detnet] IPv6 encapsulation in dataplane = doc

 

Hi,

 

Yes, we = discussed this to an extent in the last call. I’ve been thinking = this a bit more lately (cross country skiing conditions have been great = thus you got a lot of time while on the skiing tracks ;) Few = concerns/points to think I see here are:

* End systems cannot participate to DetNet = service layer packet elimination & duplication business. If they = still do e.g. using DetNet DstOpt that is separate from subnet/transport = layer provided service.

* Different = subnet/transport layer segments in the DetNet domain are likely to use = their own sequencing and duplication & elimination solutions. I am = not sure how independent those will be e.g., is the sequence numbering = unified across or only per segment. The former is not IMO easy and the = latter easily reduces to single points between segments to handle number = book keeping properly.  

 

Regardless the = above I am keen to explore this alternative = approach..

 

-          = Jouni

 

 

 

Pascal/all,

At the last interim a = proposal was made to simplify IP processing, at least for the initial = detnet solution, by leaving PREF to the subnet/transport layers (i.e., = TSN and MPLS) and providing DetNet flow identification based on typical = IP 5-tuple perhaps + dscp. This approach has several benefits beyond = simplification, notably it will work for both ipv4 and IPv6, and doesn't = require any modification to encapsulation / = formats.

It would be really valuable = to get feedback from the whole working group if this simplification is = acceptable or has unacceptable limitations.

Lou

On = February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" <pthubert@cisco.com> = wrote:

Dear all

 

This is about the IPv6 encapsulation and more = precisely

 

   =
            &=
nbsp;        Therefore, if a =
DetNet-aware end system only
   =
inserted the DetNet Destination Option into the IPv6 but e.g., =
a
   DetNet Edge node is configured to =
enforce an explicit route for the
   IPv6 =
packet using a source routing header, then it has no =
other
   possibility than add an outer =
tunneling IPv6 header with required
   =
extension headers in it.  The processing of IPv6 packets in a =
DetNet
   Edge node is discussed further in Section 6.4.1.

 

 

With the current spec, a source sends a DetNet packet = as

 

         &= nbsp;          = +---------------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = /---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

And then the ingress node needs to re-encapsulate = as

 
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|            =
            &=
nbsp;        =
|
        &nb=
sp;           =
|           DetNet =
Flow           =
|
        &nb=
sp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   |
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H
        &nb=
sp;           =
\---------------------------------/
        &nb=
sp;           =
|          IPv6 =
header            =
|
         =
           | =
    (with set Flow =
label)       |
        &nb=
sp;           =
+---------------------------------+

 

This creates a duplication of the DetNet Destination = Option.

 

There are alternatives

 

a)  whereby the packet is = tunneled from the source to the detnet ingress, and based on its state = the DetNet ingress accepts the packet, processes it and then resends it. = The tunneled version of this could be:

 

         &= nbsp;          +-------= --------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = +---------------------------------+

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D final destination)    |

         &= nbsp;          = /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet ingress edge)  |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

Which allows the ingress to tunnel to the egress as = follows:

         &= nbsp;          +-------= --------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = +---------------------------------+

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          = |      (to final = destination)     |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
/---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet egress edge)   |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

 

b)  whereby the PREF is done = by the end nodes and the tunnel is transport only, meaning that there = are 2 tunnels A and B and that the source sends twice a packet like = this:

 

         &= nbsp;          = +---------------------------------+

         &= nbsp;        =   |          =             &= nbsp;          = |

         &= nbsp;          = |           DetNet = Flow           = |

         &= nbsp;          = |            = = Payload           =   |

         &= nbsp;          = |            =             &= nbsp;        |

         &= nbsp;          = /---------------------------------\

         &= nbsp;          = H   Optional DetNet DstOpt Hdr    H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D DetNet ingress edge X)|

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +---------------------------------+

 

And then the ingress node needs to re-encapsulate = as

 
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|            =
            &=
nbsp;        =
|
        &nb=
sp;           =
|           DetNet =
Flow           =
|
        &nb=
sp;           =
|            =
 =
Payload           =
  |
 =
            &=
nbsp;      |     &=
nbsp;           &n=
bsp;           &nb=
sp;   |
        &nb=
sp;           =
/---------------------------------\
        &nb=
sp;           =
H        DetNet DstOpt =
Hdr        =
H

         &= nbsp;          = \---------------------------------/

         &= nbsp;          = |          IPv6 = header            = |

         &= nbsp;          |  =  (dest =3D final destination)    |

         &= nbsp;          = |     (with set Flow = label)       |

         &= nbsp;          = +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D+

        &nb=
sp;           =
|          Routing =
header         =
|
        &nb=
sp;           =
+---------------------------------+
        &nb=
sp;           =
|          IPv6 =
header            =
|
        &nb=
sp;           |  =
 (dest =3D DetNet egress edge X) |
         =
           | =
    (with set Flow =
label)       |
        &nb=
sp;           =
+---------------------------------+

 

Cheers,

 

Pascal

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

------=_NextPart_000_0001_01D3A0FA.F2EA35E0-- From nobody Fri Feb 9 08:24:09 2018 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 9B0DD1200FC for ; Fri, 9 Feb 2018 08:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 ypHgQ4J9a2ld for ; Fri, 9 Feb 2018 08:24:04 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 AA468127698 for ; Fri, 9 Feb 2018 08:24:04 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 6415B21622C for ; Fri, 9 Feb 2018 09:24:01 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id 8gPx1x00R2SSUrH01gQ0bF; Fri, 09 Feb 2018 09:24:01 -0700 X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=tXgZ3comtnjozD6G2RIA:9 a=XFIlFAS8EZXNdVKt:21 a=ItGC48zCHhYOLUnc:21 a=pILNOxqGKmIA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ikfWTxDl2Z7JJ9oX9tgFOKU8sFvZa7N+vXWxubTj67s=; b=LH5LlNVqC8lyJz4iP2q7HQf+oC Fi8bfOw6F3Dh0bCdVPCyW3pXL7tYiO2x9cYaT9YHlHhaJmqDchUWYdxac/A7hct5o9qVdaGp3VdpC 6cN+tVJXku5GwfMsoSCH/ncGe; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60316 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ekBSv-001Gbq-I1; Fri, 09 Feb 2018 09:23:57 -0700 To: Jouni , "'Pascal Thubert (pthubert)'" , detnet@ietf.org References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> From: Lou Berger Message-ID: Date: Fri, 9 Feb 2018 11:23:56 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <22c101d3a0bc$5795b080$06c11180$@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1ekBSv-001Gbq-I1 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:60316 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 09 Feb 2018 16:24:07 -0000 Hi Jouni, On 02/08/2018 04:08 AM, Jouni wrote: > Hi, > >   > > Yes, we discussed this to an extent in the last call. I’ve been thinking > this a bit more lately (cross country skiing conditions have been great > thus you got a lot of time while on the skiing tracks ;) Few > concerns/points to think I see here are: I'm jealous! > > * End systems cannot participate to DetNet service layer packet > elimination & duplication business. If they still do e.g. using DetNet > DstOpt that is separate from subnet/transport layer provided service. True, end station participation in PREF wouldn't be possible in this simplified approach for IP, but the end stations *could* still participate in the equivalent function provided by a sub-net layer such as TSN. So end to end detnet traffic protection is not possible, but it doesn't mean it can't be provided by lower network layers. The gain here is a simplified and unified IP solution and simplified host processing/support, albeit with a loss of one of the three end to end detnet service attributes. > * Different subnet/transport layer segments in the DetNet domain are > likely to use their own sequencing and duplication & elimination > solutions. I am not sure how independent those will be e.g., is the > sequence numbering unified across or only per segment. The former is not > IMO easy and the latter easily reduces to single points between segments > to handle number book keeping properly.   Agreed. The question for the WG is this a reasonable compromise in order to in our *initial* solution defined by the WG. -- Nothing says we can't come back and improve on this in the future, but it will allow us to get *something* useful defined with less complexity.   > > Regardless the above I am keen to explore this alternative approach.. > Great - look forward to hear the results! Lou   > > -          Jouni > >   > >   > > *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou Berger > *Sent:* Wednesday, February 7, 2018 17:00 PM > *To:* Pascal Thubert (pthubert) ; detnet@ietf.org > *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc > >   > > Pascal/all, > > At the last interim a proposal was made to simplify IP processing, at > least for the initial detnet solution, by leaving PREF to the > subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow > identification based on typical IP 5-tuple perhaps + dscp. This approach > has several benefits beyond simplification, notably it will work for > both ipv4 and IPv6, and doesn't require any modification to > encapsulation / formats. > > It would be really valuable to get feedback from the whole working group > if this simplification is acceptable or has unacceptable limitations. > > Lou > > On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" > > wrote: > > Dear all > >   > > This is about the IPv6 encapsulation and more precisely > >   > >                         Therefore, if a DetNet-aware end system only > >    inserted the DetNet Destination Option into the IPv6 but e.g., a > >    DetNet Edge node is configured to enforce an explicit route for the > >    IPv6 packet using a source routing header, then it has no other > >    possibility than add an outer tunneling IPv6 header with required > >    extension headers in it.  The processing of IPv6 packets in a DetNet > >    Edge node is discussed further in Section 6.4.1 > . > >   > >   > > With the current spec, a source sends a DetNet packet as > >   > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                     |                                 | > >                     /---------------------------------\ > >                     H   Optional DetNet DstOpt Hdr    H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > > And then the ingress node needs to re-encapsulate as > >   > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                    |                                 | > >                     /---------------------------------\ > >                     H        DetNet DstOpt Hdr        H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |     (with set Flow label)       | > >                     +=================================+ > >                     |          Routing header         | > >                     /---------------------------------\ > >                     H        DetNet DstOpt Hdr        H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > > This creates a duplication of the DetNet Destination Option. > >   > > There are alternatives > >   > > a)  whereby the packet is tunneled from the source to the detnet > ingress, and based on its state the DetNet ingress accepts the > packet, processes it and then resends it. The tunneled version of > this could be: > >   > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                     |                                 | > >                     +---------------------------------+ > >                     |          IPv6 header            | > >                     |   (dest = final destination)    | > >                     /=================================\ > >                     H   Optional DetNet DstOpt Hdr    H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |   (dest = DetNet ingress edge)  | > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > > Which allows the ingress to tunnel to the egress as follows: > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                     |                                 | > >                     +---------------------------------+ > >                     |          IPv6 header            | > >                     |      (to final destination)     | > >                     +=================================+ > >                     |          Routing header         | > >                     /---------------------------------\ > >                     H   Optional DetNet DstOpt Hdr    H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |   (dest = DetNet egress edge)   | > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > >   > > b)  whereby the PREF is done by the end nodes and the tunnel is > transport only, meaning that there are 2 tunnels A and B and that > the source sends twice a packet like this: > >   > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                     |                                 | > >                     /---------------------------------\ > >                     H   Optional DetNet DstOpt Hdr    H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |   (dest = DetNet ingress edge X)| > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > > And then the ingress node needs to re-encapsulate as > >   > >                     +---------------------------------+ > >                     |                                 | > >                     |           DetNet Flow           | > >                     |             Payload             | > >                    |                                 | > >                     /---------------------------------\ > >                     H        DetNet DstOpt Hdr        H > >                     \---------------------------------/ > >                     |          IPv6 header            | > >                     |   (dest = final destination)    | > >                     |     (with set Flow label)       | > >                     +=================================+ > >                     |          Routing header         | > >                     +---------------------------------+ > >                     |          IPv6 header            | > >                     |   (dest = DetNet egress edge X) | > >                     |     (with set Flow label)       | > >                     +---------------------------------+ > >   > > Cheers, > >   > > Pascal > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > From nobody Sun Feb 11 12:06:18 2018 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 C86B412704A for ; Sun, 11 Feb 2018 12:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 6WpijcV8AaAP for ; Sun, 11 Feb 2018 12:06:15 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 AE50D12700F for ; Sun, 11 Feb 2018 12:06:14 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id q194so17779480lfe.13 for ; Sun, 11 Feb 2018 12:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5wD8aFo06ALLm/L7pChm7YbaZ2Gf9IW8wrvwdIsvCKc=; b=tP9V5qBHga+1MAs2dw0CjoLH90QgI32Q5VWx6xPeWCyzAlaSCGFGRDJpQoINHVzzIu 8cRGGec8kBdUwBQaJhEyErkQztbCrkW7CS6n2aPXsCqz8eQtvkrYVnkjVxI/KTeHDsq3 cGI7bK1KGdUEWlbxsAsSlEMzs1fLv7Vxz9eYAqKteZ+GrSCigLuPnjUrwWAlNE9rVESf WMYf1Ylpx32sh8NG9YNQEnY3EbProJA2uA2wmQj8OoDLcjTlOdtbV9Nm1VjXHBIcDXsS q8qVFjzVSoTtKF3RJ34eHMKx8PSTMkBKl7fHq4F+KXPfOn9zOkDbM8liTsS72yxRrL9Y Hr4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5wD8aFo06ALLm/L7pChm7YbaZ2Gf9IW8wrvwdIsvCKc=; b=rugLHJxlR/C5DqCMJ9oljjdZwsgsBwcpOPRIftyFKg/kmD0zuZKVcchrhXZ0sQytxB Wn8Newhy5zTworvxsdx/5qsSLvKZiDWM6Q9oBViSy4v2p2lMhvmqiZ79WobLgVJGfBRE HCEF9yyT9wF3gwO8vLpGigd2eIj6gZUInhg0oj+LAak5mZGyGqh5h9O7Ep49Jq5k/dcd uM6p5FLk9wTUuU5ucoWtQumVKWxbM6UcOfGmi6SmZ3rTBBYSoD7o2BO8Tthn96UYm6Yj 8vuelLTSP0Yz8M0E2A8gHpHn7okesNc+sjfno+nNizY2K/m/OnGTrktJDhkAHd95mweF bnKw== X-Gm-Message-State: APf1xPADHUKgk+wwHNH3pniafCDpuK5Dhjbx4SMS1qyLPQq1e2/ZRt00 ZILWYjViS8bKVpo1YlY/OK8= X-Google-Smtp-Source: AH8x224PRFxgzly4RwOF7V1pXZfzncqBKloGUkZ5hyHCtCBmPNO18r/GtmRo2bSof1W0Iy3J+Mcs+g== X-Received: by 10.46.114.10 with SMTP id n10mr6159916ljc.74.1518379572859; Sun, 11 Feb 2018 12:06:12 -0800 (PST) Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id r9sm1307787ljc.18.2018.02.11.12.06.08 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Feb 2018 12:06:11 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Sun, 11 Feb 2018 22:06:02 +0200 Cc: "Pascal Thubert (pthubert)" , detnet@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> To: Lou Berger X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 20:06:18 -0000 Hi, Inline.. > On 09 Feb 2018, at 18:23, Lou Berger wrote: >=20 > Hi Jouni, >=20 >=20 > On 02/08/2018 04:08 AM, Jouni wrote: >> Hi, >>=20 >> =20 >>=20 >> Yes, we discussed this to an extent in the last call. I=92ve been = thinking >> this a bit more lately (cross country skiing conditions have been = great >> thus you got a lot of time while on the skiing tracks ;) Few >> concerns/points to think I see here are: >=20 > I'm jealous! >=20 >>=20 >> * End systems cannot participate to DetNet service layer packet >> elimination & duplication business. If they still do e.g. using = DetNet >> DstOpt that is separate from subnet/transport layer provided service. >=20 > True, end station participation in PREF wouldn't be possible in this > simplified approach for IP, but the end stations *could* still > participate in the equivalent function provided by a sub-net layer = such > as TSN. So end to end detnet traffic protection is not possible, but = it > doesn't mean it can't be provided by lower network layers. The gain > here is a simplified and unified IP solution and simplified host > processing/support, albeit with a loss of one of the three end to end > detnet service attributes. Yes, that=92s true (as I already clarified in my latest mail to Pascal). >> * Different subnet/transport layer segments in the DetNet domain are >> likely to use their own sequencing and duplication & elimination >> solutions. I am not sure how independent those will be e.g., is the >> sequence numbering unified across or only per segment. The former is = not >> IMO easy and the latter easily reduces to single points between = segments >> to handle number book keeping properly. =20 >=20 > Agreed. The question for the WG is this a reasonable compromise in > order to in our *initial* solution defined by the WG. -- Nothing says > we can't come back and improve on this in the future, but it will = allow > us to get *something* useful defined with less complexity. I would first specify the required steps that make IP as-is work within = one subnet/transport layer segment. That should be an achievable goal = with a limitation of e.g. a single interconnection point between = subnet/transport layer segments of different types/solutions.=20 After that look into solving multiple interconnection points.. and there = the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine = could be way forward. - Jouni >=20 > =20 >>=20 >> Regardless the above I am keen to explore this alternative approach.. >>=20 >=20 > Great - look forward to hear the results! > Lou > =20 >>=20 >> - Jouni >>=20 >> =20 >>=20 >> =20 >>=20 >> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou = Berger >> *Sent:* Wednesday, February 7, 2018 17:00 PM >> *To:* Pascal Thubert (pthubert) ; detnet@ietf.org >> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>=20 >> =20 >>=20 >> Pascal/all, >>=20 >> At the last interim a proposal was made to simplify IP processing, at >> least for the initial detnet solution, by leaving PREF to the >> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet = flow >> identification based on typical IP 5-tuple perhaps + dscp. This = approach >> has several benefits beyond simplification, notably it will work for >> both ipv4 and IPv6, and doesn't require any modification to >> encapsulation / formats. >>=20 >> It would be really valuable to get feedback from the whole working = group >> if this simplification is acceptable or has unacceptable limitations. >>=20 >> Lou >>=20 >> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >> > wrote: >>=20 >> Dear all >>=20 >> =20 >>=20 >> This is about the IPv6 encapsulation and more precisely >>=20 >> =20 >>=20 >> Therefore, if a DetNet-aware end system = only >>=20 >> inserted the DetNet Destination Option into the IPv6 but e.g., = a >>=20 >> DetNet Edge node is configured to enforce an explicit route for = the >>=20 >> IPv6 packet using a source routing header, then it has no other >>=20 >> possibility than add an outer tunneling IPv6 header with = required >>=20 >> extension headers in it. The processing of IPv6 packets in a = DetNet >>=20 >> Edge node is discussed further in Section 6.4.1 >> = . >>=20 >> =20 >>=20 >> =20 >>=20 >> With the current spec, a source sends a DetNet packet as >>=20 >> =20 >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> /---------------------------------\ >>=20 >> H Optional DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> And then the ingress node needs to re-encapsulate as >>=20 >> =20 >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> /---------------------------------\ >>=20 >> H DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (with set Flow label) | >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>=20 >> | Routing header | >>=20 >> /---------------------------------\ >>=20 >> H DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> This creates a duplication of the DetNet Destination Option. >>=20 >> =20 >>=20 >> There are alternatives >>=20 >> =20 >>=20 >> a) whereby the packet is tunneled from the source to the detnet >> ingress, and based on its state the DetNet ingress accepts the >> packet, processes it and then resends it. The tunneled version of >> this could be: >>=20 >> =20 >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> +---------------------------------+ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D final destination) | >>=20 >> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>=20 >> H Optional DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D DetNet ingress edge) | >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> Which allows the ingress to tunnel to the egress as follows: >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> +---------------------------------+ >>=20 >> | IPv6 header | >>=20 >> | (to final destination) | >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>=20 >> | Routing header | >>=20 >> /---------------------------------\ >>=20 >> H Optional DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D DetNet egress edge) | >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> =20 >>=20 >> b) whereby the PREF is done by the end nodes and the tunnel is >> transport only, meaning that there are 2 tunnels A and B and that >> the source sends twice a packet like this: >>=20 >> =20 >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> /---------------------------------\ >>=20 >> H Optional DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D DetNet ingress edge X)| >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> And then the ingress node needs to re-encapsulate as >>=20 >> =20 >>=20 >> +---------------------------------+ >>=20 >> | | >>=20 >> | DetNet Flow | >>=20 >> | Payload | >>=20 >> | | >>=20 >> /---------------------------------\ >>=20 >> H DetNet DstOpt Hdr H >>=20 >> \---------------------------------/ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D final destination) | >>=20 >> | (with set Flow label) | >>=20 >> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>=20 >> | Routing header | >>=20 >> +---------------------------------+ >>=20 >> | IPv6 header | >>=20 >> | (dest =3D DetNet egress edge X) | >>=20 >> | (with set Flow label) | >>=20 >> +---------------------------------+ >>=20 >> =20 >>=20 >> Cheers, >>=20 >> =20 >>=20 >> Pascal >>=20 >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >>=20 >=20 From nobody Sun Feb 11 13:27:03 2018 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 965201271FD for ; Sun, 11 Feb 2018 13:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 FPgZA1w8jMBG for ; Sun, 11 Feb 2018 13:26:59 -0800 (PST) Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 CF1E61271DF for ; Sun, 11 Feb 2018 13:26:59 -0800 (PST) Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 5B349175AF1 for ; Sun, 11 Feb 2018 14:26:56 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 9ZSs1x00G2SSUrH01ZSv1m; Sun, 11 Feb 2018 14:26:56 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=N659UExz7-8A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=mCmARWXzqXCyBV09k24A:9 a=TGvJlnz36NI0SBLX:21 a=PsnyW0ewK0YaXDbM:21 a=pILNOxqGKmIA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=acXlPe+TkTOdWkxkZZX/GGzQeZYZ3JIv01EoIkpJcgQ=; b=P/Gju1h7/QK0VjmblZeVwEx9eW Gbg1bVbex6LGhJFnrbzImQHWQxrAu/d9Ery7QDZi6tjmhlCjpfPd4goNyvf6DnPgO3QgBJwk/ocmU V+jGJlo1nGeVIHfa9FG+Hec95; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:34056 helo=fs2.dc.labn.net) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1ekz9A-003JLy-AE; Sun, 11 Feb 2018 14:26:52 -0700 To: Jouni Cc: "Pascal Thubert (pthubert)" , detnet@ietf.org References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> From: Lou Berger Message-ID: Date: Sun, 11 Feb 2018 16:26:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1ekz9A-003JLy-AE X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net (fs2.dc.labn.net) [100.15.86.101]:34056 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 21:27:01 -0000 hi, On 02/11/2018 03:06 PM, Jouni wrote: > > Hi, > > Inline.. > >> On 09 Feb 2018, at 18:23, Lou Berger wrote: >> >> Hi Jouni, >> >> >> On 02/08/2018 04:08 AM, Jouni wrote: >>> Hi, >>> >>> >>> >>> Yes, we discussed this to an extent in the last call. I’ve been thinking >>> this a bit more lately (cross country skiing conditions have been great >>> thus you got a lot of time while on the skiing tracks ;) Few >>> concerns/points to think I see here are: >> >> I'm jealous! >> >>> >>> * End systems cannot participate to DetNet service layer packet >>> elimination & duplication business. If they still do e.g. using DetNet >>> DstOpt that is separate from subnet/transport layer provided service. >> >> True, end station participation in PREF wouldn't be possible in this >> simplified approach for IP, but the end stations *could* still >> participate in the equivalent function provided by a sub-net layer such >> as TSN. So end to end detnet traffic protection is not possible, but it >> doesn't mean it can't be provided by lower network layers. The gain >> here is a simplified and unified IP solution and simplified host >> processing/support, albeit with a loss of one of the three end to end >> detnet service attributes. > > Yes, that’s true (as I already clarified in my latest mail to Pascal). > yes. It's good for all to remember that DetNet is just as much (if not more) about supporting explicit routes with congestion protection and latency control.... > >>> * Different subnet/transport layer segments in the DetNet domain are >>> likely to use their own sequencing and duplication & elimination >>> solutions. I am not sure how independent those will be e.g., is the >>> sequence numbering unified across or only per segment. The former is not >>> IMO easy and the latter easily reduces to single points between segments >>> to handle number book keeping properly. >> >> Agreed. The question for the WG is this a reasonable compromise in >> order to in our *initial* solution defined by the WG. -- Nothing says >> we can't come back and improve on this in the future, but it will allow >> us to get *something* useful defined with less complexity. > > I would first specify the required steps that make IP as-is work within one subnet/transport layer segment. That should be an achievable goal with a limitation of e.g. a single interconnection point between subnet/transport layer segments of different types/solutions. > sure. as long as one of the 'attached stations' can be a router. > After that look into solving multiple interconnection points.. and there the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be way forward. > yes, this would be good follow on work... Cheers, Lou > - Jouni > > >> >> >>> >>> Regardless the above I am keen to explore this alternative approach.. >>> >> >> Great - look forward to hear the results! >> Lou >> >>> >>> - Jouni >>> >>> >>> >>> >>> >>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou Berger >>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>> *To:* Pascal Thubert (pthubert) ; detnet@ietf.org >>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>> >>> >>> >>> Pascal/all, >>> >>> At the last interim a proposal was made to simplify IP processing, at >>> least for the initial detnet solution, by leaving PREF to the >>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet flow >>> identification based on typical IP 5-tuple perhaps + dscp. This approach >>> has several benefits beyond simplification, notably it will work for >>> both ipv4 and IPv6, and doesn't require any modification to >>> encapsulation / formats. >>> >>> It would be really valuable to get feedback from the whole working group >>> if this simplification is acceptable or has unacceptable limitations. >>> >>> Lou >>> >>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>> > wrote: >>> >>> Dear all >>> >>> >>> >>> This is about the IPv6 encapsulation and more precisely >>> >>> >>> >>> Therefore, if a DetNet-aware end system only >>> >>> inserted the DetNet Destination Option into the IPv6 but e.g., a >>> >>> DetNet Edge node is configured to enforce an explicit route for the >>> >>> IPv6 packet using a source routing header, then it has no other >>> >>> possibility than add an outer tunneling IPv6 header with required >>> >>> extension headers in it. The processing of IPv6 packets in a DetNet >>> >>> Edge node is discussed further in Section 6.4.1 >>> . >>> >>> >>> >>> >>> >>> With the current spec, a source sends a DetNet packet as >>> >>> >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> /---------------------------------\ >>> >>> H Optional DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> And then the ingress node needs to re-encapsulate as >>> >>> >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> /---------------------------------\ >>> >>> H DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (with set Flow label) | >>> >>> +=================================+ >>> >>> | Routing header | >>> >>> /---------------------------------\ >>> >>> H DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> This creates a duplication of the DetNet Destination Option. >>> >>> >>> >>> There are alternatives >>> >>> >>> >>> a) whereby the packet is tunneled from the source to the detnet >>> ingress, and based on its state the DetNet ingress accepts the >>> packet, processes it and then resends it. The tunneled version of >>> this could be: >>> >>> >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> +---------------------------------+ >>> >>> | IPv6 header | >>> >>> | (dest = final destination) | >>> >>> /=================================\ >>> >>> H Optional DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (dest = DetNet ingress edge) | >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> Which allows the ingress to tunnel to the egress as follows: >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> +---------------------------------+ >>> >>> | IPv6 header | >>> >>> | (to final destination) | >>> >>> +=================================+ >>> >>> | Routing header | >>> >>> /---------------------------------\ >>> >>> H Optional DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (dest = DetNet egress edge) | >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> >>> >>> b) whereby the PREF is done by the end nodes and the tunnel is >>> transport only, meaning that there are 2 tunnels A and B and that >>> the source sends twice a packet like this: >>> >>> >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> /---------------------------------\ >>> >>> H Optional DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (dest = DetNet ingress edge X)| >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> And then the ingress node needs to re-encapsulate as >>> >>> >>> >>> +---------------------------------+ >>> >>> | | >>> >>> | DetNet Flow | >>> >>> | Payload | >>> >>> | | >>> >>> /---------------------------------\ >>> >>> H DetNet DstOpt Hdr H >>> >>> \---------------------------------/ >>> >>> | IPv6 header | >>> >>> | (dest = final destination) | >>> >>> | (with set Flow label) | >>> >>> +=================================+ >>> >>> | Routing header | >>> >>> +---------------------------------+ >>> >>> | IPv6 header | >>> >>> | (dest = DetNet egress edge X) | >>> >>> | (with set Flow label) | >>> >>> +---------------------------------+ >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Pascal >>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> > > From nobody Sun Feb 11 13:43:01 2018 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 77AF21271DF for ; Sun, 11 Feb 2018 13:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 b2MkGHQ6SRHP for ; Sun, 11 Feb 2018 13:42:58 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 B55E21200B9 for ; Sun, 11 Feb 2018 13:42:57 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id t79so17987310lfe.3 for ; Sun, 11 Feb 2018 13:42:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UaR13lNuHQXg+/nhsTyi9T0kQWsR7Pd4w6cr/cOHdW0=; b=Tdibm/6a3WlXKmwaRRTefi7FR+ZHBVeLLKPu/n52qgmjzSs3Cns2P7V18gITKzZIRv wY1QAJqiE/yAfKJX3m/tbLpGx8A8oybgOXsiDpDgR87hlJKCexT2eGlUmTqToJmumAO5 9bsLy2j0vXbf+F4+0XxqXbDuFyiQZGWaq6/t8R6rwFoB13A5dwtoadaLfpA6YnjroMwP fyWqDIUsftckOU6ksODZoYCzfVfLvhMOUSy1+fE89WWmzO39SuLA9MkSTIfvqcJH+kiJ wAleSYGlIO/+jCFUwx2BMum6kXvb0R/Hq0+6CiXOsKkK0LU8/Ct9sI/KU6m25Z+jSvjv rKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=UaR13lNuHQXg+/nhsTyi9T0kQWsR7Pd4w6cr/cOHdW0=; b=k5CRvmUBvF0bJrUMb7t1YS2ck/2HqJV4g3hUfNqAixWHsNARe3KWRIN2BBN16rUJUK 5qe4ZWicQIXgDeo/PHGvX6gGgMO3hV04P5I6/ShUU27r5Q5wHpPCp0TQKX/NHvdblYTx T2g5bZaRGm896LQytdUPhxENpZ8m6hX9jLPNZn5SK8JyStCDpLobeAkwo4mw8dXKM3j8 JRsNGU6uEXBYfd+7HqiZ0q6OV6Wmj4WztKfw57lUK4+uwvbr20X8pRmi88JIjD1jcMSI pLHCtAEEbzsPduPIrS167B3omumVVBfi95K6TTPaDI1h/4iEvu5V0segH/BAJ+U0wbDI MUpw== X-Gm-Message-State: APf1xPBsPw23QCmz57n0QLzHSB2w2imgo9gXM534OJNZp6AyOlO7Lyk0 3Ss11sXGbJ9COslMNcD8HFk= X-Google-Smtp-Source: AH8x224Ol1OQpwZHBJpIwIGmJGKIWLZpNabtzWBhwO419de0hl9sM1tBjMSWPIpCPha+GkmTYi1s/w== X-Received: by 10.46.20.8 with SMTP id u8mr6581831ljd.12.1518385375836; Sun, 11 Feb 2018 13:42:55 -0800 (PST) Received: from jounis-imac.home ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id e11sm1314678ljf.44.2018.02.11.13.42.54 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 11 Feb 2018 13:42:55 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jouni In-Reply-To: Date: Sun, 11 Feb 2018 23:42:53 +0200 Cc: "Pascal Thubert (pthubert)" , detnet@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> To: Lou Berger X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 11 Feb 2018 21:43:00 -0000 >>>> * End systems cannot participate to DetNet service layer packet >>>> elimination & duplication business. If they still do e.g. using = DetNet >>>> DstOpt that is separate from subnet/transport layer provided = service. >>>=20 >>> True, end station participation in PREF wouldn't be possible in this >>> simplified approach for IP, but the end stations *could* still >>> participate in the equivalent function provided by a sub-net layer = such >>> as TSN. So end to end detnet traffic protection is not possible, but = it >>> doesn't mean it can't be provided by lower network layers. The gain >>> here is a simplified and unified IP solution and simplified host >>> processing/support, albeit with a loss of one of the three end to = end >>> detnet service attributes. >>=20 >> Yes, that=92s true (as I already clarified in my latest mail to = Pascal). >>=20 >=20 > yes. It's good for all to remember that DetNet is just as much (if = not > more) about supporting explicit routes with congestion protection and > latency control.... Indeed.. >>>> * Different subnet/transport layer segments in the DetNet domain = are >>>> likely to use their own sequencing and duplication & elimination >>>> solutions. I am not sure how independent those will be e.g., is the >>>> sequence numbering unified across or only per segment. The former = is not >>>> IMO easy and the latter easily reduces to single points between = segments >>>> to handle number book keeping properly. =20 >>>=20 >>> Agreed. The question for the WG is this a reasonable compromise in >>> order to in our *initial* solution defined by the WG. -- Nothing = says >>> we can't come back and improve on this in the future, but it will = allow >>> us to get *something* useful defined with less complexity. >>=20 >> I would first specify the required steps that make IP as-is work = within one subnet/transport layer segment. That should be an achievable = goal with a limitation of e.g. a single interconnection point between = subnet/transport layer segments of different types/solutions.=20 >>=20 >=20 > sure. as long as one of the 'attached stations' can be a router. Yes. That=92s the plan at least from my side. - Juoni >=20 >> After that look into solving multiple interconnection points.. and = there the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of = mine could be way forward. >>=20 >=20 > yes, this would be good follow on work... >=20 > Cheers, > Lou >> - Jouni >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> Regardless the above I am keen to explore this alternative = approach.. >>>>=20 >>>=20 >>> Great - look forward to hear the results! >>> Lou >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou = Berger >>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>> *To:* Pascal Thubert (pthubert) ; = detnet@ietf.org >>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>=20 >>>>=20 >>>>=20 >>>> Pascal/all, >>>>=20 >>>> At the last interim a proposal was made to simplify IP processing, = at >>>> least for the initial detnet solution, by leaving PREF to the >>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet = flow >>>> identification based on typical IP 5-tuple perhaps + dscp. This = approach >>>> has several benefits beyond simplification, notably it will work = for >>>> both ipv4 and IPv6, and doesn't require any modification to >>>> encapsulation / formats. >>>>=20 >>>> It would be really valuable to get feedback from the whole working = group >>>> if this simplification is acceptable or has unacceptable = limitations. >>>>=20 >>>> Lou >>>>=20 >>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>> > wrote: >>>>=20 >>>> Dear all >>>>=20 >>>>=20 >>>>=20 >>>> This is about the IPv6 encapsulation and more precisely >>>>=20 >>>>=20 >>>>=20 >>>> Therefore, if a DetNet-aware end system = only >>>>=20 >>>> inserted the DetNet Destination Option into the IPv6 but e.g., = a >>>>=20 >>>> DetNet Edge node is configured to enforce an explicit route = for the >>>>=20 >>>> IPv6 packet using a source routing header, then it has no = other >>>>=20 >>>> possibility than add an outer tunneling IPv6 header with = required >>>>=20 >>>> extension headers in it. The processing of IPv6 packets in a = DetNet >>>>=20 >>>> Edge node is discussed further in Section 6.4.1 >>>> = . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> With the current spec, a source sends a DetNet packet as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> This creates a duplication of the DetNet Destination Option. >>>>=20 >>>>=20 >>>>=20 >>>> There are alternatives >>>>=20 >>>>=20 >>>>=20 >>>> a) whereby the packet is tunneled from the source to the detnet >>>> ingress, and based on its state the DetNet ingress accepts the >>>> packet, processes it and then resends it. The tunneled version of >>>> this could be: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Which allows the ingress to tunnel to the egress as follows: >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (to final destination) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>> transport only, meaning that there are 2 tunnels A and B and that >>>> the source sends twice a packet like this: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge X)| >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge X) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Mon Feb 12 02:21:17 2018 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 7DBDC1273E2 for ; Mon, 12 Feb 2018 02:21:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 V1soUGFmEkWE for ; Mon, 12 Feb 2018 02:21:14 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 68623127337 for ; Mon, 12 Feb 2018 02:21:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518430872; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=xJ+kPHyvjL84E1R9dOLUb9eZ9TIg6JPK8n34AjY+pOM=; b=hek6rDbjw2+iTjiMVbqt92fVs3P8h5Xy4EQy6JoMFjSE3yND/D7pXkyr2r6k2z+Q QJEVrJ15dlAXeQrKHCtH3Co7EQ3EoGafFM0rH91RfaaBkiMOiUGn0pC09ybvmWg0 D/w0W4fN+luIGFtp/T2kQhkJb1YRyREEp9WOciCx/yQ=; X-AuditID: c1b4fb2d-4b1ff70000005540-1b-5a816a985589 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 5E.03.21824.89A618A5; Mon, 12 Feb 2018 11:21:12 +0100 (CET) Received: from [159.107.143.201] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.352.0; Mon, 12 Feb 2018 11:21:12 +0100 To: References: CC: "detnet-chairs@ietf.org" From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <0372079a-2970-da7f-26c3-78e60ae34fef@ericsson.com> Date: Mon, 12 Feb 2018 11:21:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrDLMWRmVeSWpSXmKPExsUyM2K7iu6MrMYog/fH1Syu9f9gsfj9aTaL A5PHkiU/mQIYo7hsUlJzMstSi/TtErgyrl54yVzwRaCif8o69gbGRr4uRk4OCQETiVWvp7OB 2EIChxkl5nYHdTFyAdlrGSX6zl9gB0kICxhKfDvYwwJiiwiISpyY0skO0WAvcXr3XTCbWcBU 4se7ncwgNhtQ/O6lDWA2L5B9te8KWA2LgKpE+/1DQHEODlGBGIn1fQkQJYISJ2c+ARvPKeAg cXnzWRaQEmag1gdbyyCmy0s0b53NDLFVTeLT24fsExgFZiHpnoXQMQtJxwJG5lWMosWpxcW5 6UbGeqlFmcnFxfl5enmpJZsYgWF4cMtv3R2Mq187HmIU4GBU4uEtD2yMEmJNLCuuzD3EKMHB rCTCOzMKKMSbklhZlVqUH19UmpNafIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoHR 4WDLM869XlfKr0hMS/gb7SKmkH5g0d6pue0y66a+npJWaPPik+XRDR5HHSOXL+6b8N7OWzq6 5On7J8d0+X1mxF9JYN75+bCLxYH7HA9j+fvOH71+N+7FtMcbv67maGH4mnJ+qS6btVPqy3vb Fszzc6yMPutRU73387pP05Jtow2YtTSSee8+VGIpzkg01GIuKk4EAFO9F/M/AgAA Archived-At: Subject: [Detnet] contributions to the 3rd virtual interim X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 10:21:16 -0000 Dear All, Contributions are highly encouraged as we discussed it on the 2nd Interim. Please let the chairs know if you are bringing a contribution to the 3rd interim. Thank you! Janos On 2/7/2018 3:13 PM, János Farkas wrote: > Dear All, > > We are planning to hold our third virtual interim to discuss the > DetNet Data Plane document, > https://tools.ietf.org/html/draft-ietf-detnet-dp-sol [1]. The intent > is to continue working through open issues on the draft based on > revision 01 and where we left off at the previous virtual interims. > Contributions on multiple open items were encouraged at the last > interim [5]. The main focus of this interim is to discuss those > contributions. > > The meeting will be held February 14 at 1500GMT. We are aiming for a > 90 minute meeting, but are scheduling to allow 30 minutes of extra > discussion time if needed. Webex details will be announced when > available. > > The agenda is less formal than our normal meetings and is: > - Administrativa (chairs) > - Draft status update (authors) > - Contributions to address open issues (contributors) > - Next steps, including future meetings > > [1] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 > > [2] IETF 100 open issues: > https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/ > > [3] IETF 100 open issues - PREF: > https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/ > > [4] 1st DetNet Interim: > https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet > > [5] 2nd DetNet Interim: > https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet > > Note that low participation is expected from Asia due to the Chinese > New Year; therefore, this slot has been chosen by the main > contributors for this meeting. > > Thank you, > DetNet WG Chairs > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Feb 12 02:30:18 2018 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 D61CC1273E2 for ; Mon, 12 Feb 2018 02:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_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 pHyFeQECI_lw for ; Mon, 12 Feb 2018 02:30:15 -0800 (PST) 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 EEB3F124BFA for ; Mon, 12 Feb 2018 02:30:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14589; q=dns/txt; s=iport; t=1518431414; x=1519641014; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KhnzOKIbfKpm+iLwifZb4bctMoXBF12Mehkku4HNf3Q=; b=BRP/mb/HfDIE/Gmg1eDy4gxkCyl2L9UfxZiN3CCOW1XwlDiRstqprxvC KQB2qNUz3XVucbU+HMJ0Y7eeC9Gwgr2l7dANKq4w+NxogH5+XbRoeQlMT 6KS0AFz/GQsTVAyIvoBnyAjM2B9lNqOC6gaBsVQ/GTQx8UvWpxjs+xfLq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DBAAAlbIFa/4oNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNSZnAoCo1/jiOCAoEXh3+OQhWCAwoYC4RJTwKCSFQYAQIBAQE?= =?us-ascii?q?BAQECayiFIwEBAQMBAQFqAggDDAQCAQgRBAEBAScHIQYLFAkIAgQBDQUIE4oCA?= =?us-ascii?q?w0IELBLhzYNgTGCDQEBAQEBAQEBAQEBAQEBAQEBAQEBAR2EfIIVgVeBaIMugmt?= =?us-ascii?q?EAQECAYE2GAEBhXogBYpriC+QXzUJAogehAiEUoUBgw+RPo4CSIkhAhEZAYE7A?= =?us-ascii?q?R85gVBwFT2CRgmEbQF4AYpAgSWBFwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,501,1511827200"; d="scan'208";a="69611921" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 10:30:14 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id w1CAUDdM002075 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Feb 2018 10:30:13 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 12 Feb 2018 04:30:13 -0600 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.1320.000; Mon, 12 Feb 2018 04:30:13 -0600 From: "Pascal Thubert (pthubert)" To: Jouni , Lou Berger CC: "detnet@ietf.org" Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQAP298AACYDgIAAQYLPAABsVvAAAALSj4AAAI9ZgAAMJTaw Date: Mon, 12 Feb 2018 10:30:00 +0000 Deferred-Delivery: Mon, 12 Feb 2018 10:29:08 +0000 Message-ID: References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> In-Reply-To: <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> 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.228.216.16] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 10:30:18 -0000 Hello Jouni and Lou: Just to make sure we are on the same line: - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP. - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge. - The ingress edge may be a NIC card in the originating node. It would be = operating below IPvX and possibly equipped with 2 Ethernet ports and capabl= e of PREF. - Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it. A snooping edge device doing DPI may dig in the packet and find inf= ormation for packet identification and ordering, for a particular applicati= on, and that is beyond the interests of the WG. - A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's ble= ssing. Do we agree? Pascal -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: dimanche 11 f=E9vrier 2018 22:43 To: Lou Berger Cc: Pascal Thubert (pthubert) ; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>>> * End systems cannot participate to DetNet service layer packet=20 >>>> elimination & duplication business. If they still do e.g. using=20 >>>> DetNet DstOpt that is separate from subnet/transport layer provided se= rvice. >>>=20 >>> True, end station participation in PREF wouldn't be possible in this=20 >>> simplified approach for IP, but the end stations *could* still=20 >>> participate in the equivalent function provided by a sub-net layer=20 >>> such as TSN. So end to end detnet traffic protection is not=20 >>> possible, but it doesn't mean it can't be provided by lower network=20 >>> layers. The gain here is a simplified and unified IP solution and=20 >>> simplified host processing/support, albeit with a loss of one of the=20 >>> three end to end detnet service attributes. >>=20 >> Yes, that's true (as I already clarified in my latest mail to Pascal). >>=20 >=20 > yes. It's good for all to remember that DetNet is just as much (if=20 > not > more) about supporting explicit routes with congestion protection and=20 > latency control.... Indeed.. >>>> * Different subnet/transport layer segments in the DetNet domain=20 >>>> are likely to use their own sequencing and duplication &=20 >>>> elimination solutions. I am not sure how independent those will be=20 >>>> e.g., is the sequence numbering unified across or only per segment.=20 >>>> The former is not IMO easy and the latter easily reduces to single=20 >>>> points between segments to handle number book keeping properly. >>>=20 >>> Agreed. The question for the WG is this a reasonable compromise in=20 >>> order to in our *initial* solution defined by the WG. -- Nothing=20 >>> says we can't come back and improve on this in the future, but it=20 >>> will allow us to get *something* useful defined with less complexity. >>=20 >> I would first specify the required steps that make IP as-is work within = one subnet/transport layer segment. That should be an achievable goal with = a limitation of e.g. a single interconnection point between subnet/transpor= t layer segments of different types/solutions.=20 >>=20 >=20 > sure. as long as one of the 'attached stations' can be a router. Yes. That's the plan at least from my side. - Juoni >=20 >> After that look into solving multiple interconnection points.. and there= the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could= be way forward. >>=20 >=20 > yes, this would be good follow on work... >=20 > Cheers, > Lou >> - Jouni >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> Regardless the above I am keen to explore this alternative approach.. >>>>=20 >>>=20 >>> Great - look forward to hear the results! >>> Lou >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou=20 >>>> Berger >>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>> *To:* Pascal Thubert (pthubert) ;=20 >>>> detnet@ietf.org >>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>=20 >>>>=20 >>>>=20 >>>> Pascal/all, >>>>=20 >>>> At the last interim a proposal was made to simplify IP processing,=20 >>>> at least for the initial detnet solution, by leaving PREF to the=20 >>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet=20 >>>> flow identification based on typical IP 5-tuple perhaps + dscp.=20 >>>> This approach has several benefits beyond simplification, notably=20 >>>> it will work for both ipv4 and IPv6, and doesn't require any=20 >>>> modification to encapsulation / formats. >>>>=20 >>>> It would be really valuable to get feedback from the whole working=20 >>>> group if this simplification is acceptable or has unacceptable limitat= ions. >>>>=20 >>>> Lou >>>>=20 >>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>> > wrote: >>>>=20 >>>> Dear all >>>>=20 >>>>=20 >>>>=20 >>>> This is about the IPv6 encapsulation and more precisely >>>>=20 >>>>=20 >>>>=20 >>>> Therefore, if a DetNet-aware end system=20 >>>> only >>>>=20 >>>> inserted the DetNet Destination Option into the IPv6 but e.g.,=20 >>>> a >>>>=20 >>>> DetNet Edge node is configured to enforce an explicit route=20 >>>> for the >>>>=20 >>>> IPv6 packet using a source routing header, then it has no=20 >>>> other >>>>=20 >>>> possibility than add an outer tunneling IPv6 header with=20 >>>> required >>>>=20 >>>> extension headers in it. The processing of IPv6 packets in a=20 >>>> DetNet >>>>=20 >>>> Edge node is discussed further in Section 6.4.1 >>>> . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> With the current spec, a source sends a DetNet packet as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> This creates a duplication of the DetNet Destination Option. >>>>=20 >>>>=20 >>>>=20 >>>> There are alternatives >>>>=20 >>>>=20 >>>>=20 >>>> a) whereby the packet is tunneled from the source to the detnet >>>> ingress, and based on its state the DetNet ingress accepts the >>>> packet, processes it and then resends it. The tunneled version of >>>> this could be: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Which allows the ingress to tunnel to the egress as follows: >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (to final destination) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>> transport only, meaning that there are 2 tunnels A and B and that >>>> the source sends twice a packet like this: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge X)| >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge X) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>>=20 >>>=20 >>=20 >>=20 >=20 From nobody Mon Feb 12 08:26:20 2018 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 3572912D87A for ; Mon, 12 Feb 2018 08:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 uTS4ER6baA34 for ; Mon, 12 Feb 2018 08:26:12 -0800 (PST) Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 8DCFE12D871 for ; Mon, 12 Feb 2018 08:26:05 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id 3DB1014066A for ; Mon, 12 Feb 2018 09:26:05 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 9sS11x00h2SSUrH01sS4Rn; Mon, 12 Feb 2018 09:26:05 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=WoyKnZPoRoBK_IFIJB0A:9 a=a1A0PJfE6Gz4_CRx:21 a=ZML0q4dVDCeec3hR:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=dWfy8lFw1YaR8Z72YFQm35qj34SMk96uvTocS6krCA8=; b=Zg1BzXbj2krrmxYS9hlNIylREw jDzEqIFbH8p/RIOpa0hWlDPrCimom2Ucjz6CsrwJhzDRFTQowyXaOwoZhMg91Udwjcq0vZCZgcxuI 3bAnPhg4ZVqKC4wb1cqxHkq7x; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:36414 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1elGvZ-001XhD-8p; Mon, 12 Feb 2018 09:26:01 -0700 To: "Pascal Thubert (pthubert)" , Jouni Cc: "detnet@ietf.org" References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> From: Lou Berger Message-ID: <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net> Date: Mon, 12 Feb 2018 11:25:57 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1elGvZ-001XhD-8p X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:36414 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 16:26:19 -0000 Hi Pascal, On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote: > Hello Jouni and Lou: > > Just to make sure we are on the same line: > > - IPvX (==v4/v6) would signal the flow implicitly - derived from the tuples- but not the source sequencing. No need to change IP. if you substitute "encode" with "signal", I agree. > - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide its own sequencing based on reception order at ingress edge. I'm not sure edge ingress is right here.  an IP host may still be a DetNet edge, but PREF may on start at the DetNet/MPLS ingress. > - The ingress edge may be a NIC card in the originating node. It would be operating below IPvX and possibly equipped with 2 Ethernet ports and capable of PREF. are you talking 802.1cb or detnet PREF? if the former, yes, if the latter this is FFS for IP only detnet. > - Anything above IP is beyond charter. A upper layer sequence may be visible in the L4-transport or at the application layer but DetNet will not look for it. Yes (from my personal view) > A snooping edge device doing DPI may dig in the packet and find information for packet identification and ordering, for a particular application, and that is beyond the interests of the WG. I don't think there has any proposal for this discussed in the WG either way. > - A L4 transport may be designed to provide PREF, IOD, FEC (network coding) and whatever else needed. This would be done in TSV Area with DetNet's blessing. agreed, as would be any changes in TCP congestion control modes to take advantage of DetNet allocations. > Do we agree? I hope so! > Pascal > > -----Original Message----- > From: Jouni [mailto:jouni.nospam@gmail.com] > Sent: dimanche 11 février 2018 22:43 > To: Lou Berger > Cc: Pascal Thubert (pthubert) ; detnet@ietf.org > Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc > > > >>>>> * End systems cannot participate to DetNet service layer packet >>>>> elimination & duplication business. If they still do e.g. using >>>>> DetNet DstOpt that is separate from subnet/transport layer provided service. >>>> True, end station participation in PREF wouldn't be possible in this >>>> simplified approach for IP, but the end stations *could* still >>>> participate in the equivalent function provided by a sub-net layer >>>> such as TSN. So end to end detnet traffic protection is not >>>> possible, but it doesn't mean it can't be provided by lower network >>>> layers. The gain here is a simplified and unified IP solution and >>>> simplified host processing/support, albeit with a loss of one of the >>>> three end to end detnet service attributes. >>> Yes, that's true (as I already clarified in my latest mail to Pascal). >>> >> yes. It's good for all to remember that DetNet is just as much (if >> not >> more) about supporting explicit routes with congestion protection and >> latency control.... > Indeed.. > >>>>> * Different subnet/transport layer segments in the DetNet domain >>>>> are likely to use their own sequencing and duplication & >>>>> elimination solutions. I am not sure how independent those will be >>>>> e.g., is the sequence numbering unified across or only per segment. >>>>> The former is not IMO easy and the latter easily reduces to single >>>>> points between segments to handle number book keeping properly. >>>> Agreed. The question for the WG is this a reasonable compromise in >>>> order to in our *initial* solution defined by the WG. -- Nothing >>>> says we can't come back and improve on this in the future, but it >>>> will allow us to get *something* useful defined with less complexity. >>> I would first specify the required steps that make IP as-is work within one subnet/transport layer segment. That should be an achievable goal with a limitation of e.g. a single interconnection point between subnet/transport layer segments of different types/solutions. >>> >> sure. as long as one of the 'attached stations' can be a router. > Yes. That's the plan at least from my side. > > - Juoni > > >>> After that look into solving multiple interconnection points.. and there the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be way forward. >>> >> yes, this would be good follow on work... >> >> Cheers, >> Lou >>> - Jouni >>> >>> >>>> >>>>> Regardless the above I am keen to explore this alternative approach.. >>>>> >>>> Great - look forward to hear the results! >>>> Lou >>>> >>>>> - Jouni >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou >>>>> Berger >>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>>> *To:* Pascal Thubert (pthubert) ; >>>>> detnet@ietf.org >>>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>> >>>>> >>>>> >>>>> Pascal/all, >>>>> >>>>> At the last interim a proposal was made to simplify IP processing, >>>>> at least for the initial detnet solution, by leaving PREF to the >>>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet >>>>> flow identification based on typical IP 5-tuple perhaps + dscp. >>>>> This approach has several benefits beyond simplification, notably >>>>> it will work for both ipv4 and IPv6, and doesn't require any >>>>> modification to encapsulation / formats. >>>>> >>>>> It would be really valuable to get feedback from the whole working >>>>> group if this simplification is acceptable or has unacceptable limitations. >>>>> >>>>> Lou >>>>> >>>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>>> > wrote: >>>>> >>>>> Dear all >>>>> >>>>> >>>>> >>>>> This is about the IPv6 encapsulation and more precisely >>>>> >>>>> >>>>> >>>>> Therefore, if a DetNet-aware end system >>>>> only >>>>> >>>>> inserted the DetNet Destination Option into the IPv6 but e.g., >>>>> a >>>>> >>>>> DetNet Edge node is configured to enforce an explicit route >>>>> for the >>>>> >>>>> IPv6 packet using a source routing header, then it has no >>>>> other >>>>> >>>>> possibility than add an outer tunneling IPv6 header with >>>>> required >>>>> >>>>> extension headers in it. The processing of IPv6 packets in a >>>>> DetNet >>>>> >>>>> Edge node is discussed further in Section 6.4.1 >>>>> . >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> With the current spec, a source sends a DetNet packet as >>>>> >>>>> >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H Optional DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> And then the ingress node needs to re-encapsulate as >>>>> >>>>> >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +=================================+ >>>>> >>>>> | Routing header | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> This creates a duplication of the DetNet Destination Option. >>>>> >>>>> >>>>> >>>>> There are alternatives >>>>> >>>>> >>>>> >>>>> a) whereby the packet is tunneled from the source to the detnet >>>>> ingress, and based on its state the DetNet ingress accepts the >>>>> packet, processes it and then resends it. The tunneled version of >>>>> this could be: >>>>> >>>>> >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = final destination) | >>>>> >>>>> /=================================\ >>>>> >>>>> H Optional DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = DetNet ingress edge) | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> Which allows the ingress to tunnel to the egress as follows: >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (to final destination) | >>>>> >>>>> +=================================+ >>>>> >>>>> | Routing header | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H Optional DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = DetNet egress edge) | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>>> transport only, meaning that there are 2 tunnels A and B and that >>>>> the source sends twice a packet like this: >>>>> >>>>> >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H Optional DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = DetNet ingress edge X)| >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> And then the ingress node needs to re-encapsulate as >>>>> >>>>> >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | | >>>>> >>>>> | DetNet Flow | >>>>> >>>>> | Payload | >>>>> >>>>> | | >>>>> >>>>> /---------------------------------\ >>>>> >>>>> H DetNet DstOpt Hdr H >>>>> >>>>> \---------------------------------/ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = final destination) | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +=================================+ >>>>> >>>>> | Routing header | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> | IPv6 header | >>>>> >>>>> | (dest = DetNet egress edge X) | >>>>> >>>>> | (with set Flow label) | >>>>> >>>>> +---------------------------------+ >>>>> >>>>> >>>>> >>>>> Cheers, >>>>> >>>>> >>>>> >>>>> Pascal >>>>> >>>>> _______________________________________________ >>>>> 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 > From nobody Mon Feb 12 08:36:47 2018 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 30A9E126DD9 for ; Mon, 12 Feb 2018 08:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SYVPBnTm; dkim=pass (1024-bit key) header.d=ericsson.com header.b=gwlioHH1 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 r5Zg67iOSu30 for ; Mon, 12 Feb 2018 08:36:42 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 7BFE112421A for ; Mon, 12 Feb 2018 08:36:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518453399; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ETG4x7w+xGmFCN3XQAyfBW4agxKLLlHWJuBHUtqXUMU=; b=SYVPBnTmqvT4IY0X3lM7czXurkafikn6c1WWoWlGQvB7EUP5LpefIKVdkWfkhrcH zZFg5R1+8ADPH/90/lhzH3YBqN7Ow3muq410LvGE7wafLz0rhJ21oRQ8qHsGy/b2 CpwdePyPIUXW3eCGpPI3xvbRVwDkktcTlZ/U1WelAWA=; X-AuditID: c1b4fb25-48bff7000000341b-5a-5a81c296d1be Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 08.38.13339.692C18A5; Mon, 12 Feb 2018 17:36:39 +0100 (CET) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 17:36:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/1VKIPL4iHlPKrnabhgzbr4H9R8jj6cf5ydap2MdpBc=; b=gwlioHH1buWTbExbk368UdSTkddUS/lFDa+SgR9J5Uzv5n/SVCV1GyHk7EdXAmUqJPc7vAAkM0WiZp5qXr5sBbdazQcja6L4BA4ZEsjythaGYoozXHRwATrtKVNxzdJNcm/aeZtWosII+8dNwmNYVEG99xy0q0P1jDpqXHr/CpI= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1374.eurprd07.prod.outlook.com (10.164.92.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 16:36:37 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd%17]) with mapi id 15.20.0506.007; Mon, 12 Feb 2018 16:36:36 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Pascal Thubert (pthubert)" , Jouni , Lou Berger CC: "detnet@ietf.org" Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQADSTgAACYDgYAAQYLPAABsVu8AAALSj4AAAI9ZgAAayo8AAAu86TA= Date: Mon, 12 Feb 2018 16:36:36 +0000 Message-ID: References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [78.131.21.94] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1374; 7:ALuv8yeLiv46qOUUASYMs6/Ev8VOTIqyHLqj4UHew2y2XlZ59Kjl32vWVFt1lnEZNZ+ZjeSGEacZJwO56LzhX8GmyjUEkiwZc7aU2Dv2d3HYzXmkU7WwrUYyyck6UYLHtRouXtil8kb0I46WAC5wDpenYYOc2qT8u0uElBmjlLMCSyGifVQGByylhejYOSkClEjosSG4jK8X64+jfrdpwm/Z4CgNUzPSu9M9hKq35yL/U2RIwWaWRAV1OPkxN5uw x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c3de9b3e-8342-44df-532e-08d57236c901 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:VI1PR07MB1374; x-ms-traffictypediagnostic: VI1PR07MB1374: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(85827821059158)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(93006095)(93001095)(10201501046)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB1374; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1374; x-forefront-prvs: 0581B5AB35 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39380400002)(346002)(39860400002)(376002)(366004)(396003)(189003)(199004)(13464003)(86362001)(305945005)(6436002)(2906002)(7736002)(6306002)(9686003)(5890100001)(14454004)(3280700002)(68736007)(5250100002)(26005)(53946003)(110136005)(5660300001)(316002)(6116002)(3846002)(186003)(39060400002)(2950100002)(105586002)(102836004)(4326008)(53936002)(93886005)(7696005)(478600001)(74316002)(2900100001)(6246003)(53546011)(97736004)(8936002)(33656002)(59450400001)(55016002)(3660700001)(66066001)(25786009)(81166006)(81156014)(8676002)(229853002)(76176011)(561944003)(6506007)(966005)(99286004)(106356001); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1374; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: M3ZwIZEEjW+Jb2xSsE00buMqadN5QbFffcsi4c9XZ8ztxs55OcfI1qht0+ZJ0mPHDktkcUtY0SYKK0lsX0A+pA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c3de9b3e-8342-44df-532e-08d57236c901 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 16:36:36.7025 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1374 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee69W1dx8bQ0D6ZoA4ssp72QK8uyqFYkmB/EpLItLyrqtDu1 DATHSJZ90Gip8wXNRkE4S3GpoFgzSUmx0sCXUtcsXW4i2os2iXa9Bn37nf/5c/7nPDw0KS4X +NFpqhyGVSkyJEJPypDQCqHlFk1i+KrBS+ZarKJkXY2FhEyndVKyCv08OkbJ9a4mgby98tMG udG4QsgXmrXCWCrR83Ayk5GWx7BhUVc8U4e1QdmOghtvG16QhehVXDHyoAHvB535A1mMPGkx 7kbwecVA8UUvgtcTX4RcQeFFAkxlz4R8p4yAcd2UgC+sCLSGEsQNE+KTsKSzul007Y1zoX9e zMkk3gGjdSaS4834IHQOtBIce+NDMG77RvKshCLz2JpO4WBodNaQ3BgRvggG63U+6jkJ/VNP 1/we7qiq/p4NnAfhALCaZHyUL4xN1xL8aRiMHYMkzz5gt/0RcIzwZXB1Fa7rQfCwy4x4DoD3 tXcQlwW4hYDqIsf6ICmY7zrXTTEwY6sieJP7iW4vt68tATgEND1JvCcdyseNAp7PQv3HeQHv LyHB3l+/nuwPE99voVIUVvnf4jxLYeS+XsjzLnj0YI7kWIQ3QZ9hmqpD1BPko2bUysyUvfuk DJt2Va3OUklVTE4zcn+Xly2u4DY05Ii2IEwjiZdI3qJJFAsUeer8TAsCmpR4i1a1bkmUrMi/ ybBZSWxuBqO2oK00JfEV9Z0RJYpxiiKHSWeYbIb91yVoD79CtH2hRUfP6kcUk7mjEXFhzhhp mY0uUP4MHwzNNXWftyeLh9vk9l+PA4+UzcV/DXRAQgU7MHQ6PoJc+XFAX+MQ7pwcO3GN3RI1 EjlTVF9Z3bRt2hhxfDbaKMaR0kunNP5KU+liU4M1tnH5d+fShY6NvebqN+fexey+d9RLax+M lVDqVMWeEJJVK/4Cc3Fz5yoDAAA= Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 16:36:45 -0000 Hi Pascal, I have a lot of sympathy on your view. - OK: "DetNet would provide its own sequencing based on reception order at = ingress edge." - OK: "ingress edge may be a NIC card" - OK: "avoid DPI" However I have some questions for clarification on your final conclusions: - Why no seq.num in IP? That would mean no PREF, no IOD function within the= DetNet domain Which is an IP PSN. - What would be the gain from a "L4 transport designed to provide PREF, IOD= , FEC, ... "? I mean that would be a duplicate, as in the DetNet network You would have t= he same function. Checking L4 within the DetNet domain would require DPI, what I guess we do = not want. - I am also somewhat confused by your WiFi example. I mean in TSN/DetNet sc= enarios=20 end-systems are always assumed to be in sync with their controller(s). So I= do not agree with this statement: "Existing industrial devices can claim a rough need for a g= iven rate but were=20 not necessarily designed to provide guarantees for burstiness in DetNet ter= ms."=20 Thanks & Cheers Bala'zs -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: 2018. febru=E1r 12. 11:30 To: Jouni ; Lou Berger Cc: detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Hello Jouni and Lou: Just to make sure we are on the same line: - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP. - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge. - The ingress edge may be a NIC card in the originating node. It would be = operating below IPvX and possibly equipped with 2 Ethernet ports and capabl= e of PREF. - Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it. A snooping edge device doing DPI may dig in the packet and find inf= ormation for packet identification and ordering, for a particular applicati= on, and that is beyond the interests of the WG. - A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's ble= ssing. Do we agree? Pascal -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com]=20 Sent: dimanche 11 f=E9vrier 2018 22:43 To: Lou Berger Cc: Pascal Thubert (pthubert) ; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>>> * End systems cannot participate to DetNet service layer packet=20 >>>> elimination & duplication business. If they still do e.g. using=20 >>>> DetNet DstOpt that is separate from subnet/transport layer provided se= rvice. >>>=20 >>> True, end station participation in PREF wouldn't be possible in this=20 >>> simplified approach for IP, but the end stations *could* still=20 >>> participate in the equivalent function provided by a sub-net layer=20 >>> such as TSN. So end to end detnet traffic protection is not=20 >>> possible, but it doesn't mean it can't be provided by lower network=20 >>> layers. The gain here is a simplified and unified IP solution and=20 >>> simplified host processing/support, albeit with a loss of one of the=20 >>> three end to end detnet service attributes. >>=20 >> Yes, that's true (as I already clarified in my latest mail to Pascal). >>=20 >=20 > yes. It's good for all to remember that DetNet is just as much (if=20 > not > more) about supporting explicit routes with congestion protection and=20 > latency control.... Indeed.. >>>> * Different subnet/transport layer segments in the DetNet domain=20 >>>> are likely to use their own sequencing and duplication &=20 >>>> elimination solutions. I am not sure how independent those will be=20 >>>> e.g., is the sequence numbering unified across or only per segment.=20 >>>> The former is not IMO easy and the latter easily reduces to single=20 >>>> points between segments to handle number book keeping properly. >>>=20 >>> Agreed. The question for the WG is this a reasonable compromise in=20 >>> order to in our *initial* solution defined by the WG. -- Nothing=20 >>> says we can't come back and improve on this in the future, but it=20 >>> will allow us to get *something* useful defined with less complexity. >>=20 >> I would first specify the required steps that make IP as-is work within = one subnet/transport layer segment. That should be an achievable goal with = a limitation of e.g. a single interconnection point between subnet/transpor= t layer segments of different types/solutions.=20 >>=20 >=20 > sure. as long as one of the 'attached stations' can be a router. Yes. That's the plan at least from my side. - Juoni >=20 >> After that look into solving multiple interconnection points.. and there= the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could= be way forward. >>=20 >=20 > yes, this would be good follow on work... >=20 > Cheers, > Lou >> - Jouni >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> Regardless the above I am keen to explore this alternative approach.. >>>>=20 >>>=20 >>> Great - look forward to hear the results! >>> Lou >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou=20 >>>> Berger >>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>> *To:* Pascal Thubert (pthubert) ;=20 >>>> detnet@ietf.org >>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>=20 >>>>=20 >>>>=20 >>>> Pascal/all, >>>>=20 >>>> At the last interim a proposal was made to simplify IP processing,=20 >>>> at least for the initial detnet solution, by leaving PREF to the=20 >>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet=20 >>>> flow identification based on typical IP 5-tuple perhaps + dscp.=20 >>>> This approach has several benefits beyond simplification, notably=20 >>>> it will work for both ipv4 and IPv6, and doesn't require any=20 >>>> modification to encapsulation / formats. >>>>=20 >>>> It would be really valuable to get feedback from the whole working=20 >>>> group if this simplification is acceptable or has unacceptable limitat= ions. >>>>=20 >>>> Lou >>>>=20 >>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>> > wrote: >>>>=20 >>>> Dear all >>>>=20 >>>>=20 >>>>=20 >>>> This is about the IPv6 encapsulation and more precisely >>>>=20 >>>>=20 >>>>=20 >>>> Therefore, if a DetNet-aware end system=20 >>>> only >>>>=20 >>>> inserted the DetNet Destination Option into the IPv6 but e.g.,=20 >>>> a >>>>=20 >>>> DetNet Edge node is configured to enforce an explicit route=20 >>>> for the >>>>=20 >>>> IPv6 packet using a source routing header, then it has no=20 >>>> other >>>>=20 >>>> possibility than add an outer tunneling IPv6 header with=20 >>>> required >>>>=20 >>>> extension headers in it. The processing of IPv6 packets in a=20 >>>> DetNet >>>>=20 >>>> Edge node is discussed further in Section 6.4.1 >>>> . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> With the current spec, a source sends a DetNet packet as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> This creates a duplication of the DetNet Destination Option. >>>>=20 >>>>=20 >>>>=20 >>>> There are alternatives >>>>=20 >>>>=20 >>>>=20 >>>> a) whereby the packet is tunneled from the source to the detnet >>>> ingress, and based on its state the DetNet ingress accepts the >>>> packet, processes it and then resends it. The tunneled version of >>>> this could be: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Which allows the ingress to tunnel to the egress as follows: >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (to final destination) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>> transport only, meaning that there are 2 tunnels A and B and that >>>> the source sends twice a packet like this: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge X)| >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge X) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>>=20 >>>=20 >>=20 >>=20 >=20 _______________________________________________ detnet mailing list detnet@ietf.org https://www.ietf.org/mailman/listinfo/detnet From nobody Mon Feb 12 11:14:58 2018 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 0E5DD12D885 for ; Mon, 12 Feb 2018 11:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 zoinzuHyKa73 for ; Mon, 12 Feb 2018 11:14:52 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003: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 DC265126C0F for ; Mon, 12 Feb 2018 11:14:51 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 24so12007187oij.3 for ; Mon, 12 Feb 2018 11:14:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=830A+UMtwY6EtIFNiJdKp590WvEt9CzGV+IX8krRl7Q=; b=aF+enYO1pnpCMW+h7jk64lDfsRrm9hDYjKneNwMzJ1aGjfHHDc/KqcDjlN4YpTWsFb XoP8b2qUt6Tyyz8dN+gwwkdQq+PIw9MHaQSSanyidU8FDV0iiwtqsCq/QPvZ3maQGb1/ AzolvXLG+XSVRvPy4vnHApQIoGyQJVSiagkQFeJ3JwQl9RPIOgbnfoKbSkQly6AquxF8 28kR97tkQfhVP3C1MkRDaWjY/qp+6l6/g8+iX1Ep1YX467pRz9Vas9QbnWA9f8ZGKefh 5ouKnCzL8Tylv27h3uXDicKN0lm7GY/4BcoCrOP4xgQdr9lkQn0bb11gkZuKRyDPp5GY xuOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=830A+UMtwY6EtIFNiJdKp590WvEt9CzGV+IX8krRl7Q=; b=d/8PFEHNPZjRXBvbvuM4tf98tg8uZzMrb5BN2tLKqP+RjSktphfx/tvwF9YbSlKH7w u1W2/v3g8RpA95WPpy0y8l5u153rn3hFzGvfFBE0fpbIEH6wTdkR6je7MdgRT1qctR6z 27RmoTLAMo/zM4WHC47DWC0P0po7EaXBdHs7iO4shD3qshofTHvyyOXOjDmB01y9O3n9 oz2I1NnPfIZquK98BvpVp9j5Pf1tCmyaPCfYc5U6lIrCmkmTfXFflq6jFQa+rdYEAnTZ vi8Wyr3DtTszv5gNiL98bR5ZsEZ9hFlu+XDT7m0C9NeOgam0GK8JbGfrDm6BOGFa4qnm 01Qw== X-Gm-Message-State: APf1xPDQx6wv1A2lYW8EioI8/49jf/sc9aK+BA6ytV6gIPiFkBBLAAPF ZO+8JokhbMDhuvaSw5RQ1dEOKK9s8oEcH8kgoK4= X-Google-Smtp-Source: AH8x227gqU6fLk736rxpR8uhbP+Iw4TmkWu5dXAZ+zxqxNz4uGGnhEbYeSNE6zEbFD8jSYdud+diaf1oFYgAp6a9cL4= X-Received: by 10.202.80.200 with SMTP id e191mr8877611oib.333.1518462891087; Mon, 12 Feb 2018 11:14:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.72 with HTTP; Mon, 12 Feb 2018 11:14:30 -0800 (PST) In-Reply-To: <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net> References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net> From: "Andrew G. Malis" Date: Mon, 12 Feb 2018 14:14:30 -0500 Message-ID: To: Lou Berger Cc: "Pascal Thubert (pthubert)" , Jouni , "detnet@ietf.org" Content-Type: multipart/alternative; boundary="001a113b02b43a5aa6056508b166" Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 19:14:56 -0000 --001a113b02b43a5aa6056508b166 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lou and Pascal, On the most recent interim call, we discussed an encapsulation for IPv4 and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC 7520). This works for both v4 and v6, obviously. Or at least that=E2=80=99= s how I interpreted the conversation at the time and the following notes from the Etherpad: Jouni: Good point. Prob with IP is have been narrow focused on carrying DetNet info. But if can assume that in a DetNet domain for routed traffic, transport below is TSN or equivalent, e.g. MPLS, then what we do at IP layer is just routing or mapping flows into MPLS tunnels. An underlay and then just do routing. Lou: Is that assuming that PREF always done by e.g. TSN layer? Jouni: Yes. Jouni: Then starts looking like over PWs as we discussed earlier. Lou: Others find this approach acceptable? This proposal fits within our charter and process, and is more like what some hoped to see from our process. Do we, the people building the solution, like this approach or find it objectionable? Jouni: Starting to like this idea. Lou: So next rev of draft will propose largely common approach on v4 and v6, i.e. 5-tuple, depends on TSN and MPLS to provide transport and PREF functions? So is this still the case, and what we should expect to see in the next revision of the draft? Thanks, Andy On Mon, Feb 12, 2018 at 11:25 AM, Lou Berger wrote: > Hi Pascal, > > On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote: > >> Hello Jouni and Lou: >> >> Just to make sure we are on the same line: >> >> - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the >> tuples- but not the source sequencing. No need to change IP. >> > if you substitute "encode" with "signal", I agree. > > - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide >> its own sequencing based on reception order at ingress edge. >> > I'm not sure edge ingress is right here. an IP host may still be a DetNe= t > edge, but PREF may on start at the DetNet/MPLS ingress. > > - The ingress edge may be a NIC card in the originating node. It would b= e >> operating below IPvX and possibly equipped with 2 Ethernet ports and >> capable of PREF. >> > are you talking 802.1cb or detnet PREF? if the former, yes, if the latter > this is FFS for IP only detnet. > > - Anything above IP is beyond charter. A upper layer sequence may be >> visible in the L4-transport or at the application layer but DetNet will = not >> look for it. >> > Yes (from my personal view) > >> A snooping edge device doing DPI may dig in the packet and find >> information for packet identification and ordering, for a particular >> application, and that is beyond the interests of the WG. >> > I don't think there has any proposal for this discussed in the WG either > way. > > - A L4 transport may be designed to provide PREF, IOD, FEC (network >> coding) and whatever else needed. This would be done in TSV Area with >> DetNet's blessing. >> > agreed, as would be any changes in TCP congestion control modes to take > advantage of DetNet allocations. > > > Do we agree? >> > I hope so! > > > Pascal >> >> -----Original Message----- >> From: Jouni [mailto:jouni.nospam@gmail.com] >> Sent: dimanche 11 f=C3=A9vrier 2018 22:43 >> To: Lou Berger >> Cc: Pascal Thubert (pthubert) ; detnet@ietf.org >> Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >> >> >> >> * End systems cannot participate to DetNet service layer packet >>>>>> elimination & duplication business. If they still do e.g. using >>>>>> DetNet DstOpt that is separate from subnet/transport layer provided >>>>>> service. >>>>>> >>>>> True, end station participation in PREF wouldn't be possible in this >>>>> simplified approach for IP, but the end stations *could* still >>>>> participate in the equivalent function provided by a sub-net layer >>>>> such as TSN. So end to end detnet traffic protection is not >>>>> possible, but it doesn't mean it can't be provided by lower network >>>>> layers. The gain here is a simplified and unified IP solution and >>>>> simplified host processing/support, albeit with a loss of one of the >>>>> three end to end detnet service attributes. >>>>> >>>> Yes, that's true (as I already clarified in my latest mail to Pascal). >>>> >>>> yes. It's good for all to remember that DetNet is just as much (if >>> not >>> more) about supporting explicit routes with congestion protection and >>> latency control.... >>> >> Indeed.. >> >> * Different subnet/transport layer segments in the DetNet domain >>>>>> are likely to use their own sequencing and duplication & >>>>>> elimination solutions. I am not sure how independent those will be >>>>>> e.g., is the sequence numbering unified across or only per segment. >>>>>> The former is not IMO easy and the latter easily reduces to single >>>>>> points between segments to handle number book keeping properly. >>>>>> >>>>> Agreed. The question for the WG is this a reasonable compromise in >>>>> order to in our *initial* solution defined by the WG. -- Nothing >>>>> says we can't come back and improve on this in the future, but it >>>>> will allow us to get *something* useful defined with less complexity. >>>>> >>>> I would first specify the required steps that make IP as-is work withi= n >>>> one subnet/transport layer segment. That should be an achievable goal = with >>>> a limitation of e.g. a single interconnection point between >>>> subnet/transport layer segments of different types/solutions. >>>> >>>> sure. as long as one of the 'attached stations' can be a router. >>> >> Yes. That's the plan at least from my side. >> >> - Juoni >> >> >> After that look into solving multiple interconnection points.. and there >>>> the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine c= ould >>>> be way forward. >>>> >>>> yes, this would be good follow on work... >>> >>> Cheers, >>> Lou >>> >>>> - Jouni >>>> >>>> >>>> >>>>> Regardless the above I am keen to explore this alternative approach.. >>>>>> >>>>>> Great - look forward to hear the results! >>>>> Lou >>>>> >>>>> - Jouni >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou >>>>>> Berger >>>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>>>> *To:* Pascal Thubert (pthubert) ; >>>>>> detnet@ietf.org >>>>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>>> >>>>>> >>>>>> >>>>>> Pascal/all, >>>>>> >>>>>> At the last interim a proposal was made to simplify IP processing, >>>>>> at least for the initial detnet solution, by leaving PREF to the >>>>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet >>>>>> flow identification based on typical IP 5-tuple perhaps + dscp. >>>>>> This approach has several benefits beyond simplification, notably >>>>>> it will work for both ipv4 and IPv6, and doesn't require any >>>>>> modification to encapsulation / formats. >>>>>> >>>>>> It would be really valuable to get feedback from the whole working >>>>>> group if this simplification is acceptable or has unacceptable >>>>>> limitations. >>>>>> >>>>>> Lou >>>>>> >>>>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>>>> > wrote: >>>>>> >>>>>> Dear all >>>>>> >>>>>> >>>>>> >>>>>> This is about the IPv6 encapsulation and more precisely >>>>>> >>>>>> >>>>>> >>>>>> Therefore, if a DetNet-aware end system >>>>>> only >>>>>> >>>>>> inserted the DetNet Destination Option into the IPv6 but e.g., >>>>>> a >>>>>> >>>>>> DetNet Edge node is configured to enforce an explicit route >>>>>> for the >>>>>> >>>>>> IPv6 packet using a source routing header, then it has no >>>>>> other >>>>>> >>>>>> possibility than add an outer tunneling IPv6 header with >>>>>> required >>>>>> >>>>>> extension headers in it. The processing of IPv6 packets in a >>>>>> DetNet >>>>>> >>>>>> Edge node is discussed further in Section 6.4.1 >>>>>> >>>>> ction-6.4.1>. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> With the current spec, a source sends a DetNet packet as >>>>>> >>>>>> >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H Optional DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> And then the ingress node needs to re-encapsulate as >>>>>> >>>>>> >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>> >>>>>> | Routing header | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> This creates a duplication of the DetNet Destination Option. >>>>>> >>>>>> >>>>>> >>>>>> There are alternatives >>>>>> >>>>>> >>>>>> >>>>>> a) whereby the packet is tunneled from the source to the detnet >>>>>> ingress, and based on its state the DetNet ingress accepts the >>>>>> packet, processes it and then resends it. The tunneled version of >>>>>> this could be: >>>>>> >>>>>> >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D final destination) | >>>>>> >>>>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>>> >>>>>> H Optional DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D DetNet ingress edge) | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> Which allows the ingress to tunnel to the egress as follows: >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (to final destination) | >>>>>> >>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>> >>>>>> | Routing header | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H Optional DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D DetNet egress edge) | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>>>> transport only, meaning that there are 2 tunnels A and B and that >>>>>> the source sends twice a packet like this: >>>>>> >>>>>> >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H Optional DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D DetNet ingress edge X)| >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> And then the ingress node needs to re-encapsulate as >>>>>> >>>>>> >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | | >>>>>> >>>>>> | DetNet Flow | >>>>>> >>>>>> | Payload | >>>>>> >>>>>> | | >>>>>> >>>>>> /---------------------------------\ >>>>>> >>>>>> H DetNet DstOpt Hdr H >>>>>> >>>>>> \---------------------------------/ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D final destination) | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>> >>>>>> | Routing header | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> | IPv6 header | >>>>>> >>>>>> | (dest =3D DetNet egress edge X) | >>>>>> >>>>>> | (with set Flow label) | >>>>>> >>>>>> +---------------------------------+ >>>>>> >>>>>> >>>>>> >>>>>> Cheers, >>>>>> >>>>>> >>>>>> >>>>>> Pascal >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> >> > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a113b02b43a5aa6056508b166 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou and Pascal,

On the most recent= interim call, we discussed an encapsulation for IPv4 and IPv6 that reused = the MPLS encapsulation inside UDP inside IP (ala RFC 7520). This works for = both v4 and v6, obviously.=C2=A0 Or at least that=E2=80=99s how I interpret= ed the conversation at the time and the following notes from the Etherpad:<= /div>

Jouni: Good point. Prob with IP is hav= e been narrow focused on carrying DetNet info. But if can assume that in a = DetNet domain for routed traffic, transport below is TSN or equivalent, e.g= . MPLS, then what we do at IP layer is just routing or mapping flows into M= PLS tunnels. An underlay and then just do routing.=C2=A0
Lou: Is that assuming that PREF always done by e.g. TSN layer?=C2=A0<= /span>
Jouni: Yes.=C2=A0
Jouni: Th= en starts looking like over PWs as we discussed earlier.=C2=A0
=
Lou: Others find this approach acceptable? This proposal fits w= ithin our charter and process, and is more like what some hoped to see from= our process. Do we, the people building the solution, like this approach o= r find it objectionable?=C2=A0
Jouni: Starting to= like this idea.=C2=A0
Lou: So next rev of draft wi= ll propose largely common approach on v4 and v6, i.e. ?= =C2=A0

So is this still the case, and= what we should expect to see in the next revision of the draft?

Thanks,
Andy


On Mon, Feb 12, 2018 a= t 11:25 AM, Lou Berger <lberger@labn.net> wrote:
Hi Pascal,

On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote:
Hello Jouni and Lou:

Just to make sure we are on the same line:

- IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP.
 if you substitute "encode" with "signal", I agree.

- DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge.
I'm not sure edge ingress is right here.=C2=A0 an IP host may still be = a DetNet edge, but PREF may on start at the DetNet/MPLS ingress.

- The=C2=A0 ingress edge may be a NIC card in the originating node. It woul= d be operating below IPvX and possibly equipped with 2 Ethernet ports and c= apable of PREF.
 are you talking 802.1cb or detnet PREF? if the former, yes, if the latter t= his is FFS for IP only detnet.

- Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it.
 Yes (from my personal view)
A snooping edge device doing DPI may dig in the packet and find information= for packet identification and ordering, for a particular application, and = that is beyond the interests of the WG.
 I don't think there has any proposal for this discussed in the WG eithe= r way.

- A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's= blessing.
 agreed, as would be any changes in TCP congestion control modes to take adv= antage of DetNet allocations.


Do we agree?
I hope so!


Pascal

-----Original Message-----
From: Jouni [mailto:jouni.nospam@gmail.com]
Sent: dimanche 11 f=C3=A9vrier 2018 22:43
To: Lou Berger <lb= erger@labn.net>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc



* End systems cannot participate to DetNet service layer packet
elimination & duplication business. If they still do e.g. using
DetNet DstOpt that is separate from subnet/transport layer provided service= .
True, end station participation in PREF wouldn't be possible in this simplified approach for IP, but the end stations *could* still
participate in the equivalent function provided by a sub-net layer
such as TSN. So end to end detnet traffic protection is not
possible, but it doesn't mean it can't be provided by lower network=
layers.=C2=A0 The gain here is a simplified and unified IP solution and
simplified host processing/support, albeit with a loss of one of the
three end to end detnet service attributes.
Yes, that's true (as I already clarified in my latest mail to Pascal).<= br>
yes.=C2=A0 It's good for all to remember that DetNet is just as much (i= f
not
more) about supporting explicit routes with congestion protection and
latency control....
Indeed..

* Different subnet/transport layer segments in the DetNet domain
are likely to use their own sequencing and duplication &
elimination solutions. I am not sure how independent those will be
e.g., is the sequence numbering unified across or only per segment.
The former is not IMO easy and the latter easily reduces to single
points between segments to handle number book keeping properly.
Agreed.=C2=A0 The question for the WG is this a reasonable compromise in order to in our *initial* solution defined by the WG.=C2=A0 -- Nothing
says we can't come back and improve on this in the future, but it
will allow us to get *something* useful defined with less complexity.
I would first specify the required steps that make IP as-is work within one= subnet/transport layer segment. That should be an achievable goal with a l= imitation of e.g. a single interconnection point between subnet/transport l= ayer segments of different types/solutions.

sure. as long as one of the 'attached stations' can be a router.
Yes. That's the plan at least from my side.

- Juoni


After that look into solving multiple interconnection points.. and there th= e L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be= way forward.

yes, this would be good follow on work...

Cheers,
Lou
- Jouni



Regardless the above I am keen to explore this alternative approach..

Great - look forward to hear the results!
Lou

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jouni





*From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou
Berger
*Sent:* Wednesday, February 7, 2018 17:00 PM
*To:* Pascal Thubert (pthubert) <pthubert@cisco.com>;
detnet@ietf.org *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc



Pascal/all,

At the last interim a proposal was made to simplify IP processing,
at least for the initial detnet solution, by leaving PREF to the
subnet/transport layers (i.e., TSN and MPLS) and providing DetNet
flow identification based on typical IP 5-tuple perhaps + dscp.
This approach has several benefits beyond simplification, notably
it will work for both ipv4 and IPv6, and doesn't require any
modification to encapsulation / formats.

It would be really valuable to get feedback from the whole working
group if this simplification is acceptable or has unacceptable limitations.=

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
<pthubert@cisco.= com <mailto:= pthubert@cisco.com>> wrote:

=C2=A0 =C2=A0Dear all



=C2=A0 =C2=A0This is about the IPv6 encapsulation and more precisely



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Therefore, if a DetNet-aware end system
only

=C2=A0 =C2=A0 =C2=A0 inserted the DetNet Destination Option into the IPv6 b= ut e.g.,
a

=C2=A0 =C2=A0 =C2=A0 DetNet Edge node is configured to enforce an explicit = route
for the

=C2=A0 =C2=A0 =C2=A0 IPv6 packet using a source routing header, then it has= no
other

=C2=A0 =C2=A0 =C2=A0 possibility than add an outer tunneling IPv6 header wi= th
required

=C2=A0 =C2=A0 =C2=A0 extension headers in it.=C2=A0 The processing of IPv6 = packets in a
DetNet

=C2=A0 =C2=A0 =C2=A0 Edge node is discussed further in Section 6.4.1
=C2=A0 =C2=A0<https://tools.= ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.<= br>




=C2=A0 =C2=A0With the current spec, a source sends a DetNet packet as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0This creates a duplication of the DetNet Destination Option.


=C2=A0 =C2=A0There are alternatives



=C2=A0 =C2=A0a)=C2=A0 whereby the packet is tunneled from the source to the= detnet
=C2=A0 =C2=A0ingress, and based on its state the DetNet ingress accepts the=
=C2=A0 =C2=A0packet, processes it and then resends it. The tunneled version= of
=C2=A0 =C2=A0this could be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge)=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Which allows the ingress to tunnel to the egress as follows:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 (to final destination)=C2=A0 =C2=A0 =C2=A0|=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge)=C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+





=C2=A0 =C2=A0b)=C2=A0 whereby the PREF is done by the end nodes and the tun= nel is
=C2=A0 =C2=A0transport only, meaning that there are 2 tunnels A and B and t= hat
=C2=A0 =C2=A0the source sends twice a packet like this:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge X)|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge X) |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Cheers,



=C2=A0 =C2=A0Pascal

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0detnet mailing list
=C2=A0 =C2=A0detnet@ie= tf.org <mailto:detnet%40ietf.org>
=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/detnet


_______________________________________________
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

--001a113b02b43a5aa6056508b166-- From nobody Mon Feb 12 11:15:45 2018 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 70227126C0F for ; Mon, 12 Feb 2018 11:15:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 4VX6i7qCphU1 for ; Mon, 12 Feb 2018 11:15:38 -0800 (PST) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 E310B12D883 for ; Mon, 12 Feb 2018 11:15:37 -0800 (PST) Received: by mail-oi0-x235.google.com with SMTP id 24so12009345oij.3 for ; Mon, 12 Feb 2018 11:15:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cArpG7zWADp9K8q2k5JtXcQDz0gxbV6MO16h5g9vnxg=; b=lFtnXS8TPTD2kJgw9YiEl/5tibY0dcuWODoI//h1rRibFVu6brzeEfE9MKAywpxj2R SZLMy4vqbCyw6MVsQl9FMVEPIYpNdZCriLaewrqXVxES/y3BtiHUgcHOqHwPMpzyADUc T9ugHBD5x3ORkOMu21anN0apewZoOSH+aAFw7kaKj1hJyJejgqcgGs8Nu2FSoLV7XfWx ssEQOR8sII/k4DDO5oc+exBRiajwvMyV2SHhac52WaJ/89ksxSVmU+krj1lEl9EYVsU9 jGJbggG/tovdHftMN7k4PHoiFelFC46N8jPIEsPahCKvO89tCHGZNnyUUL8sQYB+o+yR ICZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cArpG7zWADp9K8q2k5JtXcQDz0gxbV6MO16h5g9vnxg=; b=G1tdcZ1mQKqEgfNE9aiPaZXk1jc4hZIv6XzZ7AibjvpvwEBvdPHrivrlCl4+GdwftT mL/tPfpLX8TAWH2WVGSnkiDziCzW5n0S0f1cUMPVqlziO/NIEfhpbdBrRO03SbVnHb6l TwvA7Ty5U3b39Tw4S3SWD+6hHxPfGC1rrMnMcrKEF5yBMzFawQ420jbA8c5VeXlGeWHQ Ftm8kRpjqWmG668EoxShN2kmaeGoj3j+AlGEDNUM+Be10qg8czswSMj/1Dx2b9vVsm00 uB9wjMPFgHt3AN6WK9G5jQ7nRepErJR3DTPkSmYqargcHLXm+JI79lRo0nI+sv4U9Dha lsEQ== X-Gm-Message-State: APf1xPCIJxxhXS56K8pWYrFG1+fHPfvS1cTPAyBwz50Q53l+t+Sv89WA KCo2EpzpuvfZjsm1s2m1cOexzVOeST44v/raKeE= X-Google-Smtp-Source: AH8x225uftzPU+n9DA+cqEpWcMWWkbfi69slK/Uu0ukDiUk7NG+f+mRPQ2JbhIAs0cLYcetP6zFCz8CsBzn6aV7cChM= X-Received: by 10.202.85.5 with SMTP id j5mr8752885oib.1.1518462937239; Mon, 12 Feb 2018 11:15:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.72 with HTTP; Mon, 12 Feb 2018 11:15:16 -0800 (PST) In-Reply-To: References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net> From: "Andrew G. Malis" Date: Mon, 12 Feb 2018 14:15:16 -0500 Message-ID: To: Lou Berger Cc: "Pascal Thubert (pthubert)" , Jouni , "detnet@ietf.org" Content-Type: multipart/alternative; boundary="001a113d37d4fa96c6056508b3bb" Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 19:15:42 -0000 --001a113d37d4fa96c6056508b3bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Whoops, that was a typo, should be RFC 7510, not 7520. Cheers, Andy On Mon, Feb 12, 2018 at 2:14 PM, Andrew G. Malis wrote: > Lou and Pascal, > > On the most recent interim call, we discussed an encapsulation for IPv4 > and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC > 7520). This works for both v4 and v6, obviously. Or at least that=E2=80= =99s how I > interpreted the conversation at the time and the following notes from the > Etherpad: > > Jouni: Good point. Prob with IP is have been narrow focused on carrying > DetNet info. But if can assume that in a DetNet domain for routed traffic= , > transport below is TSN or equivalent, e.g. MPLS, then what we do at IP > layer is just routing or mapping flows into MPLS tunnels. An underlay and > then just do routing. > Lou: Is that assuming that PREF always done by e.g. TSN layer? > Jouni: Yes. > Jouni: Then starts looking like over PWs as we discussed earlier. > Lou: Others find this approach acceptable? This proposal fits within our > charter and process, and is more like what some hoped to see from our > process. Do we, the people building the solution, like this approach or > find it objectionable? > Jouni: Starting to like this idea. > Lou: So next rev of draft will propose largely common approach on v4 and > v6, i.e. 5-tuple, depends on TSN and MPLS to provide transport and PREF > functions? > > So is this still the case, and what we should expect to see in the next > revision of the draft? > > Thanks, > Andy > > > On Mon, Feb 12, 2018 at 11:25 AM, Lou Berger wrote: > >> Hi Pascal, >> >> On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote: >> >>> Hello Jouni and Lou: >>> >>> Just to make sure we are on the same line: >>> >>> - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from th= e >>> tuples- but not the source sequencing. No need to change IP. >>> >> if you substitute "encode" with "signal", I agree. >> >> - DetNet may provide PREF/IOD from the edge ingress. DetNet would provid= e >>> its own sequencing based on reception order at ingress edge. >>> >> I'm not sure edge ingress is right here. an IP host may still be a >> DetNet edge, but PREF may on start at the DetNet/MPLS ingress. >> >> - The ingress edge may be a NIC card in the originating node. It would >>> be operating below IPvX and possibly equipped with 2 Ethernet ports and >>> capable of PREF. >>> >> are you talking 802.1cb or detnet PREF? if the former, yes, if the latte= r >> this is FFS for IP only detnet. >> >> - Anything above IP is beyond charter. A upper layer sequence may be >>> visible in the L4-transport or at the application layer but DetNet will= not >>> look for it. >>> >> Yes (from my personal view) >> >>> A snooping edge device doing DPI may dig in the packet and find >>> information for packet identification and ordering, for a particular >>> application, and that is beyond the interests of the WG. >>> >> I don't think there has any proposal for this discussed in the WG either >> way. >> >> - A L4 transport may be designed to provide PREF, IOD, FEC (network >>> coding) and whatever else needed. This would be done in TSV Area with >>> DetNet's blessing. >>> >> agreed, as would be any changes in TCP congestion control modes to take >> advantage of DetNet allocations. >> >> >> Do we agree? >>> >> I hope so! >> >> >> Pascal >>> >>> -----Original Message----- >>> From: Jouni [mailto:jouni.nospam@gmail.com] >>> Sent: dimanche 11 f=C3=A9vrier 2018 22:43 >>> To: Lou Berger >>> Cc: Pascal Thubert (pthubert) ; detnet@ietf.org >>> Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>> >>> >>> >>> * End systems cannot participate to DetNet service layer packet >>>>>>> elimination & duplication business. If they still do e.g. using >>>>>>> DetNet DstOpt that is separate from subnet/transport layer provided >>>>>>> service. >>>>>>> >>>>>> True, end station participation in PREF wouldn't be possible in this >>>>>> simplified approach for IP, but the end stations *could* still >>>>>> participate in the equivalent function provided by a sub-net layer >>>>>> such as TSN. So end to end detnet traffic protection is not >>>>>> possible, but it doesn't mean it can't be provided by lower network >>>>>> layers. The gain here is a simplified and unified IP solution and >>>>>> simplified host processing/support, albeit with a loss of one of the >>>>>> three end to end detnet service attributes. >>>>>> >>>>> Yes, that's true (as I already clarified in my latest mail to Pascal)= . >>>>> >>>>> yes. It's good for all to remember that DetNet is just as much (if >>>> not >>>> more) about supporting explicit routes with congestion protection and >>>> latency control.... >>>> >>> Indeed.. >>> >>> * Different subnet/transport layer segments in the DetNet domain >>>>>>> are likely to use their own sequencing and duplication & >>>>>>> elimination solutions. I am not sure how independent those will be >>>>>>> e.g., is the sequence numbering unified across or only per segment. >>>>>>> The former is not IMO easy and the latter easily reduces to single >>>>>>> points between segments to handle number book keeping properly. >>>>>>> >>>>>> Agreed. The question for the WG is this a reasonable compromise in >>>>>> order to in our *initial* solution defined by the WG. -- Nothing >>>>>> says we can't come back and improve on this in the future, but it >>>>>> will allow us to get *something* useful defined with less complexity= . >>>>>> >>>>> I would first specify the required steps that make IP as-is work >>>>> within one subnet/transport layer segment. That should be an achievab= le >>>>> goal with a limitation of e.g. a single interconnection point between >>>>> subnet/transport layer segments of different types/solutions. >>>>> >>>>> sure. as long as one of the 'attached stations' can be a router. >>>> >>> Yes. That's the plan at least from my side. >>> >>> - Juoni >>> >>> >>> After that look into solving multiple interconnection points.. and ther= e >>>>> the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine = could >>>>> be way forward. >>>>> >>>>> yes, this would be good follow on work... >>>> >>>> Cheers, >>>> Lou >>>> >>>>> - Jouni >>>>> >>>>> >>>>> >>>>>> Regardless the above I am keen to explore this alternative approach.= . >>>>>>> >>>>>>> Great - look forward to hear the results! >>>>>> Lou >>>>>> >>>>>> - Jouni >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou >>>>>>> Berger >>>>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>>>>> *To:* Pascal Thubert (pthubert) ; >>>>>>> detnet@ietf.org >>>>>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>>>> >>>>>>> >>>>>>> >>>>>>> Pascal/all, >>>>>>> >>>>>>> At the last interim a proposal was made to simplify IP processing, >>>>>>> at least for the initial detnet solution, by leaving PREF to the >>>>>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet >>>>>>> flow identification based on typical IP 5-tuple perhaps + dscp. >>>>>>> This approach has several benefits beyond simplification, notably >>>>>>> it will work for both ipv4 and IPv6, and doesn't require any >>>>>>> modification to encapsulation / formats. >>>>>>> >>>>>>> It would be really valuable to get feedback from the whole working >>>>>>> group if this simplification is acceptable or has unacceptable >>>>>>> limitations. >>>>>>> >>>>>>> Lou >>>>>>> >>>>>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>>>>> > wrote: >>>>>>> >>>>>>> Dear all >>>>>>> >>>>>>> >>>>>>> >>>>>>> This is about the IPv6 encapsulation and more precisely >>>>>>> >>>>>>> >>>>>>> >>>>>>> Therefore, if a DetNet-aware end system >>>>>>> only >>>>>>> >>>>>>> inserted the DetNet Destination Option into the IPv6 but e.g.= , >>>>>>> a >>>>>>> >>>>>>> DetNet Edge node is configured to enforce an explicit route >>>>>>> for the >>>>>>> >>>>>>> IPv6 packet using a source routing header, then it has no >>>>>>> other >>>>>>> >>>>>>> possibility than add an outer tunneling IPv6 header with >>>>>>> required >>>>>>> >>>>>>> extension headers in it. The processing of IPv6 packets in a >>>>>>> DetNet >>>>>>> >>>>>>> Edge node is discussed further in Section 6.4.1 >>>>>>> >>>>>> ction-6.4.1>. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> With the current spec, a source sends a DetNet packet as >>>>>>> >>>>>>> >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> And then the ingress node needs to re-encapsulate as >>>>>>> >>>>>>> >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>>> >>>>>>> | Routing header | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> This creates a duplication of the DetNet Destination Option. >>>>>>> >>>>>>> >>>>>>> >>>>>>> There are alternatives >>>>>>> >>>>>>> >>>>>>> >>>>>>> a) whereby the packet is tunneled from the source to the detnet >>>>>>> ingress, and based on its state the DetNet ingress accepts the >>>>>>> packet, processes it and then resends it. The tunneled version o= f >>>>>>> this could be: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D final destination) | >>>>>>> >>>>>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>>>> >>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D DetNet ingress edge) | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Which allows the ingress to tunnel to the egress as follows: >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (to final destination) | >>>>>>> >>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>>> >>>>>>> | Routing header | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D DetNet egress edge) | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>>>>> transport only, meaning that there are 2 tunnels A and B and tha= t >>>>>>> the source sends twice a packet like this: >>>>>>> >>>>>>> >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D DetNet ingress edge X)| >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> And then the ingress node needs to re-encapsulate as >>>>>>> >>>>>>> >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> | DetNet Flow | >>>>>>> >>>>>>> | Payload | >>>>>>> >>>>>>> | | >>>>>>> >>>>>>> /---------------------------------\ >>>>>>> >>>>>>> H DetNet DstOpt Hdr H >>>>>>> >>>>>>> \---------------------------------/ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D final destination) | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>>>> >>>>>>> | Routing header | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> | IPv6 header | >>>>>>> >>>>>>> | (dest =3D DetNet egress edge X) | >>>>>>> >>>>>>> | (with set Flow label) | >>>>>>> >>>>>>> +---------------------------------+ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> >> _______________________________________________ >> detnet mailing list >> detnet@ietf.org >> https://www.ietf.org/mailman/listinfo/detnet >> > > --001a113d37d4fa96c6056508b3bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Whoops, that was a typo, should be RFC 7510, not 7520.
Cheers,
Andy


On Mon, Feb 12, 2018 at 2:1= 4 PM, Andrew G. Malis <agmalis@gmail.com> wrote:
Lou and Pascal,

=
On the most recent interim call, we discussed an encapsulation for IPv= 4 and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC= 7520). This works for both v4 and v6, obviously.=C2=A0 Or at least that=E2= =80=99s how I interpreted the conversation at the time and the following no= tes from the Etherpad:

Jouni: Good point. Prob wit= h IP is have been narrow focused on carrying DetNet info. But if can assume= that in a DetNet domain for routed traffic, transport below is TSN or equi= valent, e.g. MPLS, then what we do at IP layer is just routing or mapping f= lows into MPLS tunnels. An underlay and then just do routing.=C2=A0<= /div>
Lou: Is that assuming that PREF always done by e.g. TSN layer?=C2=A0
Jouni: Yes.=C2=A0
Jouni: Then starts looking like ov= er PWs as we discussed earlier.=C2=A0
Lou: Others find this app= roach acceptable? This proposal fits within our charter and process, and is= more like what some hoped to see from our process. Do we, the people build= ing the solution, like this approach or find it objectionable?=C2=A0=
Jouni: Starting to like this idea.=C2=A0
Lou: So next rev= of draft will propose largely common approach on v4 and v6, i.e. 5-tuple, depends on TSN and MPLS to prov= ide transport and PREF functions?=C2=A0

So is this still the case, and what we should expec= t to see in the next revision of the draft?

= Thanks,
Andy


On = Mon, Feb 12, 2018 at 11:25 AM, Lou Berger <lberger@labn.net> = wrote:
Hi Pascal,

On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote:
Hello Jouni and Lou:

Just to make sure we are on the same line:

- IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP.
 if you substitute "encode" with "signal", I agree.

- DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge.
I'm not sure edge ingress is right here.=C2=A0 an IP host may still be = a DetNet edge, but PREF may on start at the DetNet/MPLS ingress.

- The=C2=A0 ingress edge may be a NIC card in the originating node. It woul= d be operating below IPvX and possibly equipped with 2 Ethernet ports and c= apable of PREF.
 are you talking 802.1cb or detnet PREF? if the former, yes, if the latter t= his is FFS for IP only detnet.

- Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it.
 Yes (from my personal view)
A snooping edge device doing DPI may dig in the packet and find information= for packet identification and ordering, for a particular application, and = that is beyond the interests of the WG.
 I don't think there has any proposal for this discussed in the WG eithe= r way.

- A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's= blessing.
 agreed, as would be any changes in TCP congestion control modes to take adv= antage of DetNet allocations.


Do we agree?
I hope so!


Pascal

-----Original Message-----
From: Jouni [mailto:jouni.nospam@gmail.com]
Sent: dimanche 11 f=C3=A9vrier 2018 22:43
To: Lou Berger <lb= erger@labn.net>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc



* End systems cannot participate to DetNet service layer packet
elimination & duplication business. If they still do e.g. using
DetNet DstOpt that is separate from subnet/transport layer provided service= .
True, end station participation in PREF wouldn't be possible in this simplified approach for IP, but the end stations *could* still
participate in the equivalent function provided by a sub-net layer
such as TSN. So end to end detnet traffic protection is not
possible, but it doesn't mean it can't be provided by lower network=
layers.=C2=A0 The gain here is a simplified and unified IP solution and
simplified host processing/support, albeit with a loss of one of the
three end to end detnet service attributes.
Yes, that's true (as I already clarified in my latest mail to Pascal).<= br>
yes.=C2=A0 It's good for all to remember that DetNet is just as much (i= f
not
more) about supporting explicit routes with congestion protection and
latency control....
Indeed..

* Different subnet/transport layer segments in the DetNet domain
are likely to use their own sequencing and duplication &
elimination solutions. I am not sure how independent those will be
e.g., is the sequence numbering unified across or only per segment.
The former is not IMO easy and the latter easily reduces to single
points between segments to handle number book keeping properly.
Agreed.=C2=A0 The question for the WG is this a reasonable compromise in order to in our *initial* solution defined by the WG.=C2=A0 -- Nothing
says we can't come back and improve on this in the future, but it
will allow us to get *something* useful defined with less complexity.
I would first specify the required steps that make IP as-is work within one= subnet/transport layer segment. That should be an achievable goal with a l= imitation of e.g. a single interconnection point between subnet/transport l= ayer segments of different types/solutions.

sure. as long as one of the 'attached stations' can be a router.
Yes. That's the plan at least from my side.

- Juoni


After that look into solving multiple interconnection points.. and there th= e L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be= way forward.

yes, this would be good follow on work...

Cheers,
Lou
- Jouni



Regardless the above I am keen to explore this alternative approach..

Great - look forward to hear the results!
Lou

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jouni





*From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou
Berger
*Sent:* Wednesday, February 7, 2018 17:00 PM
*To:* Pascal Thubert (pthubert) <pthubert@cisco.com>;
detnet@ietf.org *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc



Pascal/all,

At the last interim a proposal was made to simplify IP processing,
at least for the initial detnet solution, by leaving PREF to the
subnet/transport layers (i.e., TSN and MPLS) and providing DetNet
flow identification based on typical IP 5-tuple perhaps + dscp.
This approach has several benefits beyond simplification, notably
it will work for both ipv4 and IPv6, and doesn't require any
modification to encapsulation / formats.

It would be really valuable to get feedback from the whole working
group if this simplification is acceptable or has unacceptable limitations.=

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
<pthubert@cisco.= com <mailto:= pthubert@cisco.com>> wrote:

=C2=A0 =C2=A0Dear all



=C2=A0 =C2=A0This is about the IPv6 encapsulation and more precisely



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Therefore, if a DetNet-aware end system
only

=C2=A0 =C2=A0 =C2=A0 inserted the DetNet Destination Option into the IPv6 b= ut e.g.,
a

=C2=A0 =C2=A0 =C2=A0 DetNet Edge node is configured to enforce an explicit = route
for the

=C2=A0 =C2=A0 =C2=A0 IPv6 packet using a source routing header, then it has= no
other

=C2=A0 =C2=A0 =C2=A0 possibility than add an outer tunneling IPv6 header wi= th
required

=C2=A0 =C2=A0 =C2=A0 extension headers in it.=C2=A0 The processing of IPv6 = packets in a
DetNet

=C2=A0 =C2=A0 =C2=A0 Edge node is discussed further in Section 6.4.1
=C2=A0 =C2=A0<https://tools.= ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.<= br>




=C2=A0 =C2=A0With the current spec, a source sends a DetNet packet as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0This creates a duplication of the DetNet Destination Option.


=C2=A0 =C2=A0There are alternatives



=C2=A0 =C2=A0a)=C2=A0 whereby the packet is tunneled from the source to the= detnet
=C2=A0 =C2=A0ingress, and based on its state the DetNet ingress accepts the=
=C2=A0 =C2=A0packet, processes it and then resends it. The tunneled version= of
=C2=A0 =C2=A0this could be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge)=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Which allows the ingress to tunnel to the egress as follows:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 (to final destination)=C2=A0 =C2=A0 =C2=A0|=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge)=C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+





=C2=A0 =C2=A0b)=C2=A0 whereby the PREF is done by the end nodes and the tun= nel is
=C2=A0 =C2=A0transport only, meaning that there are 2 tunnels A and B and t= hat
=C2=A0 =C2=A0the source sends twice a packet like this:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge X)|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge X) |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Cheers,



=C2=A0 =C2=A0Pascal

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0detnet mailing list
=C2=A0 =C2=A0detnet@ie= tf.org <mailto:detnet%40ietf.org>
=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/detnet


_______________________________________________
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


--001a113d37d4fa96c6056508b3bb-- From nobody Mon Feb 12 11:31:54 2018 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 005D812D872 for ; Mon, 12 Feb 2018 11:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 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_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 Nld8QYmlrXpF for ; Mon, 12 Feb 2018 11:31:51 -0800 (PST) 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 2821D1274D2 for ; Mon, 12 Feb 2018 11:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20323; q=dns/txt; s=iport; t=1518463911; x=1519673511; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z/HYww/jfnaY5QG4WYwK+gMc0eoT5zwDRsp8QftKbFI=; b=cIAD4VZIeIvHKymqxtxeRJPrISBMadO8WFAPe3/PKaJxLVsw4S80SwYb q167q5lVNjWmTAq2nKv59JWER1kwp7unKY1Uocd4IxRGpYqvuuX/0sEus epDdCcvhmHpMzEZClKL9nHX8j34qA+Cb07ZnZXHc06UAmC/kAYfO3oDeF A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DKAACX6oFa/5ldJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMhMWZwKAqNf44mggKBF4d/jkIVggMKGAuESU8Cgk1UGAECAQE?= =?us-ascii?q?BAQEBAmsohSMBAQEDAQEBagIIAwUHBAIBCBEEAQEBJwchBgsUCQgCBAENBQgTi?= =?us-ascii?q?gIDDQgQr2OHPQ2BMYIDAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYR8ghWBV4Fogy6?= =?us-ascii?q?Ca0QBAQIBgTYYAQGFeiAFimuIL5BfNQkCiB6ECIRShQGDD5E+jgJIiSECERkBg?= =?us-ascii?q?TsBHzmBUHAVPYJGCYJJH4IFAXgBiXeBJYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,503,1511827200"; d="scan'208";a="69269003" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Feb 2018 19:31:50 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1CJVoJJ023856 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 12 Feb 2018 19:31:50 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 12 Feb 2018 13:31:49 -0600 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.1320.000; Mon, 12 Feb 2018 13:31:49 -0600 From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= , Jouni , Lou Berger CC: "detnet@ietf.org" Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQAP298AACYDgIAAQYLPAABsVvAAAALSj4AAAI9ZgAAMJTawABtzAQAACDIKQA== Date: Mon, 12 Feb 2018 19:31:22 +0000 Deferred-Delivery: Mon, 12 Feb 2018 19:30:52 +0000 Message-ID: <9c47e882b66d4f95ad540c36c4e3e883@XCH-RCD-001.cisco.com> References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> In-Reply-To: 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.61.241.85] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 19:31:54 -0000 Hello Bal=E1zs - Why no seq.num in IP? That would mean no PREF, no IOD function within Det= Net domain Which is an IP PSN. > Sorry, I was unclear and I agree with you. There would not be one provide= d the source, but then the ingress edge would need to encapsulate the packe= t. In which case it would set the next as destination and insert a DestOpt= before the routing header if any.=20 > Note that if have not (Yet? Should we???) looked at a way to express the = ladder as a routing header. Till then, the most sensible thing is to send t= he packet unicast to the next Relay node (next relays if this node is a rep= licator). We still may indicate intermediate transit nodes as a routing hea= der though. The DestOpt would then be after the routing header, not before. -------------------- - What would be the gain from a "L4 transport designed to provide PREF, IOD= , FEC, ... "? I mean that would be a duplicate, as in the DetNet network You would have t= he same function. > I would say that these functions are closely related to traditional capab= ilities of a L4 transport. TCP reorders the bytes in the stream and provide= s ARQ which is an alternate to FEC. MP TCP distributes packets over differe= nt paths. Doing those functions at L4 allows real end to end service even i= f there is no specialized NIC. It keeps the IP layer intact which seemed to= be a goal in that discussion. It allows features like Network Coding which= are certainly easier to do high in the stack of a host system than in a li= ne card or a fast path in a router. - Checking L4 within the DetNet domain would require DPI, what I guess we d= o not want. > Architecturally speaking, the L4 transport implements a detnet service la= yer though it would not be done at DetNet WG. When that L4 transport is ena= bled, some service layer functions provided by the network would not be use= d, or would rely on their own sequencing. I'm not excluding that vendors co= uld propose some DPI for very specific applications, e.g. recognizing a par= ticular industrial protocol and routing it differently, say over a DetNet p= ath. But this is an implementation game and I do not see what's there for u= s to standardize. ------------------------ - I am also somewhat confused by your WiFi example. I mean in TSN/DetNet sc= enarios end-systems are always assumed to be in sync with their controller(= s). So I do not agree with this statement: "Existing industrial devices can= claim a rough need for a given rate but were not necessarily designed to p= rovide guarantees for burstiness in DetNet terms."=20 > I mean that an application on a device that was designed before TSN and t= hat does not connect to the controller and that may not participate to PTP = may still benefit from DetNet. But even if the application needs are roughl= y known, the granularity of the TSPEC may not be the one TSN expects. There= is a need for an adaptation to absorb the burst that a strict ingress filt= ering may treat too violently. Reference here is to CIR in frame relay netw= orks serving TCP and SNA flows. Disserving would be a more proper term, I h= ave a long history on implementing that, and I would like to avoid going th= rough that pain again. What I meant with Wi-Fi is different; I showed that in some cases we really= need the PREF from the source node if it is a wireless node. Because the l= osses mostly happen on the radio hop. I had in mind that with a form of mul= ticast, the source STA could send a single packet to 2 or more Ingress Rout= ers connected to different APs, and then all the received copies would foll= ow their own DetNet path. Take care, Pascal -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A Sent: lundi 12 f=E9vrier 2018 17:37 To: Pascal Thubert (pthubert) ; Jouni ; Lou Berger Cc: detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Hi Pascal, I have a lot of sympathy on your view. - OK: "DetNet would provide its own sequencing based on reception order at = ingress edge." - OK: "ingress edge may be a NIC card" - OK: "avoid DPI" However I have some questions for clarification on your final conclusions: - Why no seq.num in IP? That would mean no PREF, no IOD function within the= DetNet domain Which is an IP PSN. - What would be the gain from a "L4 transport designed to provide PREF, IOD= , FEC, ... "? I mean that would be a duplicate, as in the DetNet network You would have t= he same function. Checking L4 within the DetNet domain would require DPI, what I guess we do = not want. - I am also somewhat confused by your WiFi example. I mean in TSN/DetNet sc= enarios end-systems are always assumed to be in sync with their controller(= s). So I do not agree with this statement: "Existing industrial devices can= claim a rough need for a given rate but were not necessarily designed to p= rovide guarantees for burstiness in DetNet terms."=20 Thanks & Cheers Bala'zs -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: 2018. febru=E1r 12. 11:30 To: Jouni ; Lou Berger Cc: detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Hello Jouni and Lou: Just to make sure we are on the same line: - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP. - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge. - The ingress edge may be a NIC card in the originating node. It would be = operating below IPvX and possibly equipped with 2 Ethernet ports and capabl= e of PREF. - Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it. A snooping edge device doing DPI may dig in the packet and find inf= ormation for packet identification and ordering, for a particular applicati= on, and that is beyond the interests of the WG. - A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's ble= ssing. Do we agree? Pascal -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: dimanche 11 f=E9vrier 2018 22:43 To: Lou Berger Cc: Pascal Thubert (pthubert) ; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>>> * End systems cannot participate to DetNet service layer packet=20 >>>> elimination & duplication business. If they still do e.g. using=20 >>>> DetNet DstOpt that is separate from subnet/transport layer provided se= rvice. >>>=20 >>> True, end station participation in PREF wouldn't be possible in this=20 >>> simplified approach for IP, but the end stations *could* still=20 >>> participate in the equivalent function provided by a sub-net layer=20 >>> such as TSN. So end to end detnet traffic protection is not=20 >>> possible, but it doesn't mean it can't be provided by lower network=20 >>> layers. The gain here is a simplified and unified IP solution and=20 >>> simplified host processing/support, albeit with a loss of one of the=20 >>> three end to end detnet service attributes. >>=20 >> Yes, that's true (as I already clarified in my latest mail to Pascal). >>=20 >=20 > yes. It's good for all to remember that DetNet is just as much (if=20 > not > more) about supporting explicit routes with congestion protection and=20 > latency control.... Indeed.. >>>> * Different subnet/transport layer segments in the DetNet domain=20 >>>> are likely to use their own sequencing and duplication &=20 >>>> elimination solutions. I am not sure how independent those will be=20 >>>> e.g., is the sequence numbering unified across or only per segment.=20 >>>> The former is not IMO easy and the latter easily reduces to single=20 >>>> points between segments to handle number book keeping properly. >>>=20 >>> Agreed. The question for the WG is this a reasonable compromise in=20 >>> order to in our *initial* solution defined by the WG. -- Nothing=20 >>> says we can't come back and improve on this in the future, but it=20 >>> will allow us to get *something* useful defined with less complexity. >>=20 >> I would first specify the required steps that make IP as-is work within = one subnet/transport layer segment. That should be an achievable goal with = a limitation of e.g. a single interconnection point between subnet/transpor= t layer segments of different types/solutions.=20 >>=20 >=20 > sure. as long as one of the 'attached stations' can be a router. Yes. That's the plan at least from my side. - Juoni >=20 >> After that look into solving multiple interconnection points.. and there= the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could= be way forward. >>=20 >=20 > yes, this would be good follow on work... >=20 > Cheers, > Lou >> - Jouni >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> Regardless the above I am keen to explore this alternative approach.. >>>>=20 >>>=20 >>> Great - look forward to hear the results! >>> Lou >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou=20 >>>> Berger >>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>> *To:* Pascal Thubert (pthubert) ;=20 >>>> detnet@ietf.org >>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>=20 >>>>=20 >>>>=20 >>>> Pascal/all, >>>>=20 >>>> At the last interim a proposal was made to simplify IP processing,=20 >>>> at least for the initial detnet solution, by leaving PREF to the=20 >>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet=20 >>>> flow identification based on typical IP 5-tuple perhaps + dscp.=20 >>>> This approach has several benefits beyond simplification, notably=20 >>>> it will work for both ipv4 and IPv6, and doesn't require any=20 >>>> modification to encapsulation / formats. >>>>=20 >>>> It would be really valuable to get feedback from the whole working=20 >>>> group if this simplification is acceptable or has unacceptable limitat= ions. >>>>=20 >>>> Lou >>>>=20 >>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>> > wrote: >>>>=20 >>>> Dear all >>>>=20 >>>>=20 >>>>=20 >>>> This is about the IPv6 encapsulation and more precisely >>>>=20 >>>>=20 >>>>=20 >>>> Therefore, if a DetNet-aware end system=20 >>>> only >>>>=20 >>>> inserted the DetNet Destination Option into the IPv6 but e.g.,=20 >>>> a >>>>=20 >>>> DetNet Edge node is configured to enforce an explicit route=20 >>>> for the >>>>=20 >>>> IPv6 packet using a source routing header, then it has no=20 >>>> other >>>>=20 >>>> possibility than add an outer tunneling IPv6 header with=20 >>>> required >>>>=20 >>>> extension headers in it. The processing of IPv6 packets in a=20 >>>> DetNet >>>>=20 >>>> Edge node is discussed further in Section 6.4.1 >>>> . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> With the current spec, a source sends a DetNet packet as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> This creates a duplication of the DetNet Destination Option. >>>>=20 >>>>=20 >>>>=20 >>>> There are alternatives >>>>=20 >>>>=20 >>>>=20 >>>> a) whereby the packet is tunneled from the source to the detnet >>>> ingress, and based on its state the DetNet ingress accepts the >>>> packet, processes it and then resends it. The tunneled version of >>>> this could be: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Which allows the ingress to tunnel to the egress as follows: >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (to final destination) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>> transport only, meaning that there are 2 tunnels A and B and that >>>> the source sends twice a packet like this: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge X)| >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge X) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>>=20 >>>=20 >>=20 >>=20 >=20 _______________________________________________ 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 From nobody Mon Feb 12 12:46:06 2018 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 38BD6127010 for ; Mon, 12 Feb 2018 12:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 HgDhnNm3qNlz for ; Mon, 12 Feb 2018 12:46:00 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 53C63126FDC for ; Mon, 12 Feb 2018 12:46:00 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id C5B9C1E0B80 for ; Mon, 12 Feb 2018 13:45:59 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id 9wlw1x0092SSUrH01wlz7P; Mon, 12 Feb 2018 13:45:59 -0700 X-Authority-Analysis: v=2.2 cv=TIA1cxta c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=pGLkceISAAAA:8 a=wU2YTnxGAAAA:8 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=wld5ZzBma5Q97v1U5I4A:9 a=mmbURYpjFNgws_GB:21 a=DELfdGRLsoxJTCqo:21 a=QEXdDO2ut3YA:10 a=WP0VnmNyAAAA:8 a=rrKNdljagIRSFoFf32cA:9 a=EbN3sSXJiRvKkX-j:21 a=-XpjyNt1bGG9-3eG:21 a=cx6ir3Cv7ypSt4u-:21 a=_W_S_7VecoQA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22 a=GAxSCXi1NP3-_krMBJ48:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:CC:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=YpqfpTHOZUwpjSghymiHXWxKBZrenK7GFzmIizeq2HA=; b=iCqX9t1+1CUaQBEVqAKHt9jU0y eL+t/ldbnR7XAua8/MQTkxPsbo0bI9MS1Ldt9kqj8I58WDhmAbtIWPXHyEFMhfeAIp2vretfFwKyS yYxnlmIbqildN7NDTC4JCtzfa; Received: from [172.58.233.69] (port=39313 helo=[IPV6:2607:fb90:711f:b11f:0:45:1769:9301]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1elKz5-003KUp-Gj; Mon, 12 Feb 2018 13:45:55 -0700 From: Lou Berger To: "Andrew G. Malis" CC: "Pascal Thubert (pthubert)" , Jouni , Date: Mon, 12 Feb 2018 15:45:52 -0500 Message-ID: <1618bc44418.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> <1ecb9fc9-de35-c543-f53a-6640fddf2079@labn.net> User-Agent: AquaMail/1.13.2-730 (build: 101300200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------1618bc448e048be27d3cdf1470" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.58.233.69 X-Exim-ID: 1elKz5-003KUp-Gj X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:711f:b11f:0:45:1769:9301]) [172.58.233.69]:39313 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 12 Feb 2018 20:46:04 -0000 This is a multi-part message in MIME format. ------------1618bc448e048be27d3cdf1470 Content-Type: text/plain; format=flowed; charset="UTF-8" Content-Transfer-Encoding: 8bit I thought I heard IP over mpls not mpls over IP, although this is certainly possible but my bet is that this a third document or at least a new section. I expect that this will come up on Wednesdays interim... Lou On February 12, 2018 2:16:05 PM "Andrew G. Malis" wrote: > Whoops, that was a typo, should be RFC 7510, not 7520. > > Cheers, > Andy > > > On Mon, Feb 12, 2018 at 2:14 PM, Andrew G. Malis wrote: > >> Lou and Pascal, >> >> On the most recent interim call, we discussed an encapsulation for IPv4 >> and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC >> 7520). This works for both v4 and v6, obviously. Or at least that’s how I >> interpreted the conversation at the time and the following notes from the >> Etherpad: >> >> Jouni: Good point. Prob with IP is have been narrow focused on carrying >> DetNet info. But if can assume that in a DetNet domain for routed traffic, >> transport below is TSN or equivalent, e.g. MPLS, then what we do at IP >> layer is just routing or mapping flows into MPLS tunnels. An underlay and >> then just do routing. >> Lou: Is that assuming that PREF always done by e.g. TSN layer? >> Jouni: Yes. >> Jouni: Then starts looking like over PWs as we discussed earlier. >> Lou: Others find this approach acceptable? This proposal fits within our >> charter and process, and is more like what some hoped to see from our >> process. Do we, the people building the solution, like this approach or >> find it objectionable? >> Jouni: Starting to like this idea. >> Lou: So next rev of draft will propose largely common approach on v4 and >> v6, i.e. 5-tuple, depends on TSN and MPLS to provide transport and PREF >> functions? >> >> So is this still the case, and what we should expect to see in the next >> revision of the draft? >> >> Thanks, >> Andy >> >> >> On Mon, Feb 12, 2018 at 11:25 AM, Lou Berger wrote: >> >>> Hi Pascal, >>> >>> On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote: >>> >>>> Hello Jouni and Lou: >>>> >>>> Just to make sure we are on the same line: >>>> >>>> - IPvX (==v4/v6) would signal the flow implicitly - derived from the >>>> tuples- but not the source sequencing. No need to change IP. >>>> >>> if you substitute "encode" with "signal", I agree. >>> >>> - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide >>>> its own sequencing based on reception order at ingress edge. >>>> >>> I'm not sure edge ingress is right here. an IP host may still be a >>> DetNet edge, but PREF may on start at the DetNet/MPLS ingress. >>> >>> - The ingress edge may be a NIC card in the originating node. It would >>>> be operating below IPvX and possibly equipped with 2 Ethernet ports and >>>> capable of PREF. >>>> >>> are you talking 802.1cb or detnet PREF? if the former, yes, if the latter >>> this is FFS for IP only detnet. >>> >>> - Anything above IP is beyond charter. A upper layer sequence may be >>>> visible in the L4-transport or at the application layer but DetNet will not >>>> look for it. >>>> >>> Yes (from my personal view) >>> >>>> A snooping edge device doing DPI may dig in the packet and find >>>> information for packet identification and ordering, for a particular >>>> application, and that is beyond the interests of the WG. >>>> >>> I don't think there has any proposal for this discussed in the WG either >>> way. >>> >>> - A L4 transport may be designed to provide PREF, IOD, FEC (network >>>> coding) and whatever else needed. This would be done in TSV Area with >>>> DetNet's blessing. >>>> >>> agreed, as would be any changes in TCP congestion control modes to take >>> advantage of DetNet allocations. >>> >>> >>> Do we agree? >>>> >>> I hope so! >>> >>> >>> Pascal >>>> >>>> -----Original Message----- >>>> From: Jouni [mailto:jouni.nospam@gmail.com] >>>> Sent: dimanche 11 février 2018 22:43 >>>> To: Lou Berger >>>> Cc: Pascal Thubert (pthubert) ; detnet@ietf.org >>>> Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>>> >>>> >>>> >>>> * End systems cannot participate to DetNet service layer packet >>>>>>>> elimination & duplication business. If they still do e.g. using >>>>>>>> DetNet DstOpt that is separate from subnet/transport layer provided >>>>>>>> service. >>>>>>>> >>>>>>> True, end station participation in PREF wouldn't be possible in this >>>>>>> simplified approach for IP, but the end stations *could* still >>>>>>> participate in the equivalent function provided by a sub-net layer >>>>>>> such as TSN. So end to end detnet traffic protection is not >>>>>>> possible, but it doesn't mean it can't be provided by lower network >>>>>>> layers. The gain here is a simplified and unified IP solution and >>>>>>> simplified host processing/support, albeit with a loss of one of the >>>>>>> three end to end detnet service attributes. >>>>>>> >>>>>> Yes, that's true (as I already clarified in my latest mail to Pascal). >>>>>> >>>>>> yes. It's good for all to remember that DetNet is just as much (if >>>>> not >>>>> more) about supporting explicit routes with congestion protection and >>>>> latency control.... >>>>> >>>> Indeed.. >>>> >>>> * Different subnet/transport layer segments in the DetNet domain >>>>>>>> are likely to use their own sequencing and duplication & >>>>>>>> elimination solutions. I am not sure how independent those will be >>>>>>>> e.g., is the sequence numbering unified across or only per segment. >>>>>>>> The former is not IMO easy and the latter easily reduces to single >>>>>>>> points between segments to handle number book keeping properly. >>>>>>>> >>>>>>> Agreed. The question for the WG is this a reasonable compromise in >>>>>>> order to in our *initial* solution defined by the WG. -- Nothing >>>>>>> says we can't come back and improve on this in the future, but it >>>>>>> will allow us to get *something* useful defined with less complexity. >>>>>>> >>>>>> I would first specify the required steps that make IP as-is work >>>>>> within one subnet/transport layer segment. That should be an achievable >>>>>> goal with a limitation of e.g. a single interconnection point between >>>>>> subnet/transport layer segments of different types/solutions. >>>>>> >>>>>> sure. as long as one of the 'attached stations' can be a router. >>>>> >>>> Yes. That's the plan at least from my side. >>>> >>>> - Juoni >>>> >>>> >>>> After that look into solving multiple interconnection points.. and there >>>>>> the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could >>>>>> be way forward. >>>>>> >>>>>> yes, this would be good follow on work... >>>>> >>>>> Cheers, >>>>> Lou >>>>> >>>>>> - Jouni >>>>>> >>>>>> >>>>>> >>>>>>> Regardless the above I am keen to explore this alternative approach.. >>>>>>>> >>>>>>>> Great - look forward to hear the results! >>>>>>> Lou >>>>>>> >>>>>>> - Jouni >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou >>>>>>>> Berger >>>>>>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>>>>>> *To:* Pascal Thubert (pthubert) ; >>>>>>>> detnet@ietf.org >>>>>>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Pascal/all, >>>>>>>> >>>>>>>> At the last interim a proposal was made to simplify IP processing, >>>>>>>> at least for the initial detnet solution, by leaving PREF to the >>>>>>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet >>>>>>>> flow identification based on typical IP 5-tuple perhaps + dscp. >>>>>>>> This approach has several benefits beyond simplification, notably >>>>>>>> it will work for both ipv4 and IPv6, and doesn't require any >>>>>>>> modification to encapsulation / formats. >>>>>>>> >>>>>>>> It would be really valuable to get feedback from the whole working >>>>>>>> group if this simplification is acceptable or has unacceptable >>>>>>>> limitations. >>>>>>>> >>>>>>>> Lou >>>>>>>> >>>>>>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>>>>>> > wrote: >>>>>>>> >>>>>>>> Dear all >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This is about the IPv6 encapsulation and more precisely >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Therefore, if a DetNet-aware end system >>>>>>>> only >>>>>>>> >>>>>>>> inserted the DetNet Destination Option into the IPv6 but e.g., >>>>>>>> a >>>>>>>> >>>>>>>> DetNet Edge node is configured to enforce an explicit route >>>>>>>> for the >>>>>>>> >>>>>>>> IPv6 packet using a source routing header, then it has no >>>>>>>> other >>>>>>>> >>>>>>>> possibility than add an outer tunneling IPv6 header with >>>>>>>> required >>>>>>>> >>>>>>>> extension headers in it. The processing of IPv6 packets in a >>>>>>>> DetNet >>>>>>>> >>>>>>>> Edge node is discussed further in Section 6.4.1 >>>>>>>> >>>>>>> ction-6.4.1>. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> With the current spec, a source sends a DetNet packet as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> And then the ingress node needs to re-encapsulate as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +=================================+ >>>>>>>> >>>>>>>> | Routing header | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This creates a duplication of the DetNet Destination Option. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> There are alternatives >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> a) whereby the packet is tunneled from the source to the detnet >>>>>>>> ingress, and based on its state the DetNet ingress accepts the >>>>>>>> packet, processes it and then resends it. The tunneled version of >>>>>>>> this could be: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = final destination) | >>>>>>>> >>>>>>>> /=================================\ >>>>>>>> >>>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = DetNet ingress edge) | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Which allows the ingress to tunnel to the egress as follows: >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (to final destination) | >>>>>>>> >>>>>>>> +=================================+ >>>>>>>> >>>>>>>> | Routing header | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = DetNet egress edge) | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>>>>>> transport only, meaning that there are 2 tunnels A and B and that >>>>>>>> the source sends twice a packet like this: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H Optional DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = DetNet ingress edge X)| >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> And then the ingress node needs to re-encapsulate as >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> | DetNet Flow | >>>>>>>> >>>>>>>> | Payload | >>>>>>>> >>>>>>>> | | >>>>>>>> >>>>>>>> /---------------------------------\ >>>>>>>> >>>>>>>> H DetNet DstOpt Hdr H >>>>>>>> >>>>>>>> \---------------------------------/ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = final destination) | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +=================================+ >>>>>>>> >>>>>>>> | Routing header | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> | IPv6 header | >>>>>>>> >>>>>>>> | (dest = DetNet egress edge X) | >>>>>>>> >>>>>>>> | (with set Flow label) | >>>>>>>> >>>>>>>> +---------------------------------+ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> 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 >>>> >>>> >>> _______________________________________________ >>> detnet mailing list >>> detnet@ietf.org >>> https://www.ietf.org/mailman/listinfo/detnet >>> >> >> ------------1618bc448e048be27d3cdf1470 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I thought I heard IP over mpl= s not mpls over IP, although this is certainly possible but my bet is that = this a third document or at least a new section.

I expect that this will come = up on Wednesdays interim...

Lou

On February 12, 2018 2:16:05 PM "Andrew G. Malis"= ; <agmalis@gmail.com> wrote:

Whoops, that was a typo, should be RFC 7510, not 7520.
Cheers,
Andy


On Mon, Feb 12, 2018 at 2:1= 4 PM, Andrew G. Malis <agmalis@gmail.com> wrote:
Lou and Pascal,

=
On the most recent interim call, we discussed an encapsulation for IPv= 4 and IPv6 that reused the MPLS encapsulation inside UDP inside IP (ala RFC= 7520). This works for both v4 and v6, obviously.=C2=A0 Or at least that=E2= =80=99s how I interpreted the conversation at the time and the following no= tes from the Etherpad:

Jouni: Good point. Prob wit= h IP is have been narrow focused on carrying DetNet info. But if can assume= that in a DetNet domain for routed traffic, transport below is TSN or equi= valent, e.g. MPLS, then what we do at IP layer is just routing or mapping f= lows into MPLS tunnels. An underlay and then just do routing.=C2=A0<= /div>
Lou: Is that assuming that PREF always done by e.g. TSN layer?=C2=A0
Jouni: Yes.=C2=A0
Jouni: Then starts looking like ov= er PWs as we discussed earlier.=C2=A0
Lou: Others find this app= roach acceptable? This proposal fits within our charter and process, and is= more like what some hoped to see from our process. Do we, the people build= ing the solution, like this approach or find it objectionable?=C2=A0=
Jouni: Starting to like this idea.=C2=A0
Lou: So next rev= of draft will propose largely common approach on v4 and v6, i.e. 5-tuple, depends on TSN and MPLS to prov= ide transport and PREF functions?=C2=A0

So is this still the case, and what we should expec= t to see in the next revision of the draft?

= Thanks,
Andy


On = Mon, Feb 12, 2018 at 11:25 AM, Lou Berger <lberger@labn.net> = wrote:
Hi Pascal,

On 2/12/2018 5:30 AM, Pascal Thubert (pthubert) wrote:
Hello Jouni and Lou:

Just to make sure we are on the same line:

- IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP.
 if you substitute "encode" with "signal", I agree.

- DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge.
I'm not sure edge ingress is right here.=C2=A0 an IP host may still be = a DetNet edge, but PREF may on start at the DetNet/MPLS ingress.

- The=C2=A0 ingress edge may be a NIC card in the originating node. It woul= d be operating below IPvX and possibly equipped with 2 Ethernet ports and c= apable of PREF.
 are you talking 802.1cb or detnet PREF? if the former, yes, if the latter t= his is FFS for IP only detnet.

- Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it.
 Yes (from my personal view)
A snooping edge device doing DPI may dig in the packet and find information= for packet identification and ordering, for a particular application, and = that is beyond the interests of the WG.
 I don't think there has any proposal for this discussed in the WG eithe= r way.

- A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's= blessing.
 agreed, as would be any changes in TCP congestion control modes to take adv= antage of DetNet allocations.


Do we agree?
I hope so!


Pascal

-----Original Message-----
From: Jouni [mailto:jouni.nospam@gmail.com]
Sent: dimanche 11 f=C3=A9vrier 2018 22:43
To: Lou Berger <lb= erger@labn.net>
Cc: Pascal Thubert (pthubert) <pthubert@cisco.com>; detnet@ietf.org
Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc



* End systems cannot participate to DetNet service layer packet
elimination & duplication business. If they still do e.g. using
DetNet DstOpt that is separate from subnet/transport layer provided service=
True, end station participation in PREF wouldn't be possible in this simplified approach for IP, but the end stations *could* still
participate in the equivalent function provided by a sub-net layer
such as TSN. So end to end detnet traffic protection is not
possible, but it doesn't mean it can't be provided by lower network=
layers.=C2=A0 The gain here is a simplified and unified IP solution and
simplified host processing/support, albeit with a loss of one of the
three end to end detnet service attributes.
Yes, that's true (as I already clarified in my latest mail to Pascal).<= br>
yes.=C2=A0 It's good for all to remember that DetNet is just as much (i= f
not
more) about supporting explicit routes with congestion protection and
latency control....
Indeed..

* Different subnet/transport layer segments in the DetNet domain
are likely to use their own sequencing and duplication &
elimination solutions. I am not sure how independent those will be
e.g., is the sequence numbering unified across or only per segment.
The former is not IMO easy and the latter easily reduces to single
points between segments to handle number book keeping properly.
Agreed.=C2=A0 The question for the WG is this a reasonable compromise in order to in our *initial* solution defined by the WG.=C2=A0 -- Nothing
says we can't come back and improve on this in the future, but it
will allow us to get *something* useful defined with less complexity.
I would first specify the required steps that make IP as-is work within one= subnet/transport layer segment. That should be an achievable goal with a l= imitation of e.g. a single interconnection point between subnet/transport l= ayer segments of different types/solutions.

sure. as long as one of the 'attached stations' can be a router.
Yes. That's the plan at least from my side.

- Juoni


After that look into solving multiple interconnection points.. and there th= e L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could be= way forward.

yes, this would be good follow on work...

Cheers,
Lou
- Jouni



Regardless the above I am keen to explore this alternative approach..

Great - look forward to hear the results!
Lou

-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Jouni





*From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou
Berger
*Sent:* Wednesday, February 7, 2018 17:00 PM
*To:* Pascal Thubert (pthubert) <pthubert@cisco.com>;
detnet@ietf.org *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc



Pascal/all,

At the last interim a proposal was made to simplify IP processing,
at least for the initial detnet solution, by leaving PREF to the
subnet/transport layers (i.e., TSN and MPLS) and providing DetNet
flow identification based on typical IP 5-tuple perhaps + dscp.
This approach has several benefits beyond simplification, notably
it will work for both ipv4 and IPv6, and doesn't require any
modification to encapsulation / formats.

It would be really valuable to get feedback from the whole working
group if this simplification is acceptable or has unacceptable limitations.=

Lou

On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)"
<pthubert@cisco.= com <mailto:= pthubert@cisco.com>> wrote:

=C2=A0 =C2=A0Dear all



=C2=A0 =C2=A0This is about the IPv6 encapsulation and more precisely



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Therefore, if a DetNet-aware end system
only

=C2=A0 =C2=A0 =C2=A0 inserted the DetNet Destination Option into the IPv6 b= ut e.g.,
a

=C2=A0 =C2=A0 =C2=A0 DetNet Edge node is configured to enforce an explicit = route
for the

=C2=A0 =C2=A0 =C2=A0 IPv6 packet using a source routing header, then it has= no
other

=C2=A0 =C2=A0 =C2=A0 possibility than add an outer tunneling IPv6 header wi= th
required

=C2=A0 =C2=A0 =C2=A0 extension headers in it.=C2=A0 The processing of IPv6 = packets in a
DetNet

=C2=A0 =C2=A0 =C2=A0 Edge node is discussed further in Section 6.4.1
=C2=A0 =C2=A0<https://tools.= ietf.org/html/draft-ietf-detnet-dp-sol-01#section-6.4.1>.<= br>




=C2=A0 =C2=A0With the current spec, a source sends a DetNet packet as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0This creates a duplication of the DetNet Destination Option.


=C2=A0 =C2=A0There are alternatives



=C2=A0 =C2=A0a)=C2=A0 whereby the packet is tunneled from the source to the= detnet
=C2=A0 =C2=A0ingress, and based on its state the DetNet ingress accepts the=
=C2=A0 =C2=A0packet, processes it and then resends it. The tunneled version= of
=C2=A0 =C2=A0this could be:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge)=C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Which allows the ingress to tunnel to the egress as follows:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 (to final destination)=C2=A0 =C2=A0 =C2=A0|=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge)=C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+





=C2=A0 =C2=A0b)=C2=A0 whereby the PREF is done by the end nodes and the tun= nel is
=C2=A0 =C2=A0transport only, meaning that there are 2 tunnels A and B and t= hat
=C2=A0 =C2=A0the source sends twice a packet like this:



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0Optional DetNet DstOpt Hdr=C2=A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet ingress edge X)|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0And then the ingress node needs to re-encapsulate as



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DetNet Flow=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0/---------------------------------\

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0H=C2=A0 =C2=A0 =C2=A0 =C2=A0 DetNet DstOpt Hdr=C2=A0 =C2=A0 =C2= =A0 =C2=A0 H

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0\---------------------------------/

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D final destination)=C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Routing header=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 IPv6 header=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0(dest =3D DetNet egress edge X) |

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0(with set Flow label)=C2=A0 =C2=A0 =C2=A0 = =C2=A0|

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0+---------------------------------+



=C2=A0 =C2=A0Cheers,



=C2=A0 =C2=A0Pascal

=C2=A0 =C2=A0_______________________________________________
=C2=A0 =C2=A0detnet mailing list
=C2=A0 =C2=A0detnet@ie= tf.org <mailto:detnet%40ietf.org>
=C2=A0 =C2=A0https://www.ietf.org/mailman/listinf= o/detnet


_______________________________________________
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


------------1618bc448e048be27d3cdf1470-- From nobody Mon Feb 12 17:02:34 2018 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 2282112DA3D for ; Mon, 12 Feb 2018 17:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=unavailable 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 irrGUdJlnVpf for ; Mon, 12 Feb 2018 17:02:30 -0800 (PST) Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 C37E812DA06 for ; Mon, 12 Feb 2018 17:02:30 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 8D9711E075B for ; Mon, 12 Feb 2018 18:02:29 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id A12R1x00n2SSUrH0112UZ1; Mon, 12 Feb 2018 18:02:29 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=XFJT3RvOXPcA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=r77TgQKjGQsHNAKrUKIA:9 a=NojvYFcnAAAA:8 a=48vgC7mUAAAA:8 a=lBLFefQnlpF-fU1lBasA:9 a=iWD8m_gGr-1SeC-e:21 a=4aaNfbatqQAbKWsv:21 a=QEXdDO2ut3YA:10 a=9uUzcS5Nrb8A:10 a=gUXmQ8eWAGYA:10 a=az1hR9EdOPTt0ByFx1IA:9 a=pt9G7I5XmLUTiVRDx3fboKQV4P0=:19 a=2wSGZ2gvs7oA:10 a=w1C3t2QeGrPiZgrLijVG:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=ei3kU6SxeByGjl735n6t0Qmnht1+c9ZMZy0oqD0Hxik=; b=JPjhyefGrCnCZIXY5Uf+r771Ul CFNmxI5fsoOY1wSooineJikrbiazkttfBrwxCny+RIJzvIsZzGdTmkR31yDGt4UwbXONsVbppS1YS Vgwf6QESNSQlCV8tiaenn/DJU; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:40860 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1elOzJ-000bE7-EY; Mon, 12 Feb 2018 18:02:25 -0700 To: detnet@ietf.org Cc: DetNet Chairs References: From: Lou Berger Message-ID: <50395a08-0fb0-99b6-6ca5-188e2a51ab55@labn.net> Date: Mon, 12 Feb 2018 20:02:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------BC62060F59CE4721EDBCF1A8" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1elOzJ-000bE7-EY X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:40860 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Detnet] Virtual interim on DetNet Data Plane - February 14, 1500-1700GMT X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 01:02:33 -0000 This is a multi-part message in MIME format. --------------BC62060F59CE4721EDBCF1A8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit The session information is as follows: > Webex: > https://ietf.webex.com/ietf/j.php?MTID=mca0b929db5297a5867bc7585429ad35b > Etherpad: > http://etherpad.tools.ietf.org:9000/p/notes-ietf-interim-2018-detnet-03 > Online Agenda and Slides at: > https://datatracker.ietf.org/meeting/interim-2018-detnet-03/session/detnet > Lou On 2/7/2018 9:13 AM, János Farkas wrote: > Dear All, > > We are planning to hold our third virtual interim to discuss the DetNet > Data Plane document, > https://tools.ietf.org/html/draft-ietf-detnet-dp-sol [1]. The intent is > to continue working through open issues on the draft based on revision > 01 and where we left off at the previous virtual interims. Contributions > on multiple open items were encouraged at the last interim [5]. The main > focus of this interim is to discuss those contributions. > > The meeting will be held February 14 at 1500GMT. We are aiming for a 90 > minute meeting, but are scheduling to allow 30 minutes of extra > discussion time if needed. Webex details will be announced when available. > > The agenda is less formal than our normal meetings and is: > - Administrativa (chairs) > - Draft status update (authors) > - Contributions to address open issues (contributors) > - Next steps, including future meetings > > [1] https://tools.ietf.org/html/draft-ietf-detnet-dp-sol-01 > > [2] IETF 100 open issues: > https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3-detnet-data-plane-encapsulation-resolving-open-issues/ > > [3] IETF 100 open issues - PREF: > https://datatracker.ietf.org/meeting/100/materials/slides-100-detnet-3a-detnet-data-plane-encapsulation-resolving-open-issues-pref/ > > [4] 1st DetNet Interim: > https://datatracker.ietf.org/meeting/interim-2018-detnet-01/session/detnet > > [5] 2nd DetNet Interim: > https://datatracker.ietf.org/meeting/interim-2018-detnet-02/session/detnet > > Note that low participation is expected from Asia due to the Chinese New > Year; therefore, this slot has been chosen by the main contributors for > this meeting. > > Thank you, > DetNet WG Chairs > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --------------BC62060F59CE4721EDBCF1A8 Content-Type: text/calendar; name="WebEx_Meeting-DP-Sol3.ics" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="WebEx_Meeting-DP-Sol3.ics" BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 10.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST BEGIN:VTIMEZONE TZID:Western European Time BEGIN:STANDARD DTSTART:20161001T030000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D10 TZOFFSETFROM:+0100 TZOFFSETTO:+0000 TZNAME:Standard Time END:STANDARD BEGIN:DAYLIGHT DTSTART:20160301T020000 RRULE:FREQ=3DYEARLY;INTERVAL=3D1;BYDAY=3D-1SU;BYMONTH=3D3 TZOFFSETFROM:+0000 TZOFFSETTO:+0100 TZNAME:Daylight Savings Time END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ATTENDEE;CN=3D"DetNet Working Group";ROLE=3DREQ-PARTICIPANT;RSVP=3DFALSE:= MAILTO:detnet-chairs@ietf.org ORGANIZER;CN=3D"webex":MAILTO:messenger@webex.com DTSTART;TZID=3D"Western European Time":20180214T150000 DTEND;TZID=3D"Western European Time":20180214T170000 LOCATION:https://ietf.webex.com/ietf TRANSP:OPAQUE SEQUENCE:1518453827 UID:ac961f55-d6ed-4c8d-8baa-4fb19d8cf634 DTSTAMP:20180214T150000Z DESCRIPTION:\n\nJOIN WEBEX MEETING\nhttps://ietf.webex.com/ietf/j.php?MTI= D=3Dmbfe1d3c03cf6b6bc991be1a45ad04836\nMeeting number (access code): 640 = 062 990\nMeeting password: dp-sol\n\n\n\nJOIN BY PHONE\n1-877-668-4493 Ca= ll-in toll free number (US/Canada) \n1-650-479-3208 Call-in toll number (= US/Canada)\n\nToll-free dialing restrictions: \nhttps://www.webex.com/pdf= /tollfree_restrictions.pdf\n\n\n\nCan't join the meeting? Contact support= here:\nhttps://ietf.webex.com/ietf/mc\n\n\nIMPORTANT NOTICE: Please note= that this WebEx service allows audio and other information sent during t= he session to be recorded, which may be discoverable in a legal matter. Y= ou should inform all meeting attendees prior to recording if you intend t= o record the meeting.\n X-ALT-DESC;FMTTYPE=3Dtext/html: Join WebEx meeting
= Meeting number (ac= cess code): 640 062 990
=
Hos= t key: 770111
Meeting password:dp-sol


=  
 
Join = by phone 
1-877-668-4493 Call-in toll free number (US/Cana= da) 
1-650-479-3208 Call-in toll number (US/Canada)=  
Toll-free calling res= trictions  


 
Can't join the meeting? Contact support.  
 
IMPORTANT NOTICE: Please note= that this WebEx service allows audio and other information sent during t= he session to be recorded, which may be discoverable in a legal matter. Y= ou should inform all meeting attendees prior to recording if you intend t= o record the meeting. SUMMARY:Interim: DetNet Data Plane #3 PRIORITY:5 CLASS:PUBLIC BEGIN:VALARM TRIGGER:-PT10M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR --------------BC62060F59CE4721EDBCF1A8-- From nobody Tue Feb 13 01:01:54 2018 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 24E9D12E897 for ; Tue, 13 Feb 2018 01:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=WfqviNG6; dkim=pass (1024-bit key) header.d=ericsson.com header.b=VkXt/xzn 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 0gldNIBXqcrk for ; Tue, 13 Feb 2018 01:01:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 6F45A124BE8 for ; Tue, 13 Feb 2018 01:01:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518512506; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8w89/HbCJdhLkZdRZtO4aQyRpSmjLg5tV8auOma7tN0=; b=WfqviNG6tbaeWDlkaITxHfOpDbsawt+NprFjHcvuOmR3fm5gVhLPIP1CJU0GRolB 65To6lV2qRfCebm0WsUzo6U1Hnz4aTrT5rgSw0UE1LZcHWnyYn+0ZbpIYbKTBGql 0wVekBEQLUKijgDEe4iJQ8o3uaVgZBivirYSCyaF0sU=; X-AuditID: c1b4fb25-859119c00000341b-54-5a82a979c36c Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id F7.12.13339.979A28A5; Tue, 13 Feb 2018 10:01:46 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 13 Feb 2018 10:01:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vF2OJi+GUXB0wdQZo/blEe/q2knaQaSySj2yLMEChcE=; b=VkXt/xznPtQbH8zNqEP6EeLnaranLnXwVv6L6fOfLZKIoeq21v30nWn63amQKlfkJfxkBdxoEaJG45G2Zp662xiO7SuQkLHQnOzPdNjVWHLrBrkD9LzPAP0fGtL5eTfAzGB+GUVEGudOejtFVuRFnVkX6W/SXf14ZeEMw9BnuVM= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1358.eurprd07.prod.outlook.com (10.164.92.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Tue, 13 Feb 2018 09:01:41 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd%17]) with mapi id 15.20.0506.013; Tue, 13 Feb 2018 09:01:41 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "Pascal Thubert (pthubert)" , Jouni , Lou Berger CC: "detnet@ietf.org" Thread-Topic: [Detnet] IPv6 encapsulation in dataplane doc Thread-Index: AdOgFyOl9vKMd7+3Skyj/a0jCzTraQADSTgAACYDgYAAQYLPAABsVu8AAALSj4AAAI9ZgAAayo8AAAu86TAABytJAAAcPs4Q Date: Tue, 13 Feb 2018 09:01:41 +0000 Message-ID: References: <16170c78f30.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <22c101d3a0bc$5795b080$06c11180$@gmail.com> <00A9AB24-830A-46C7-B3DB-5C17D2AC91EC@gmail.com> <7CF3359D-204E-46E9-B7C6-B6134120502E@gmail.com> <9c47e882b66d4f95ad540c36c4e3e883@XCH-RCD-001.cisco.com> In-Reply-To: <9c47e882b66d4f95ad540c36c4e3e883@XCH-RCD-001.cisco.com> Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [89.135.192.225] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1358; 7:xbyz3FQXa3117icL+bxx33/KyPHn4K8jCv5MfymrUDNw++o0cD9EeEXAMq2YS5eYEF0L3qiRNZpfdEwOb/ZKAD39qclVTA95mKTQl7elWcrTgAw0QJpQuW2rWs4bBxTa/+hVbr00Lh4LXOgpi2QRhRwpfWX6X+XgrHmvQOqAwhWu6SOQDFsXytZkJjZfCPYNZFSA3WYykhmJTT5TSOoio1k7gMYmBkXitJt5/F2NxCIDgh45f6D0nn0zkdJKAGLG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 629154ad-7035-4d4c-198e-08d572c065f5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1PR07MB1358; x-ms-traffictypediagnostic: VI1PR07MB1358: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(278428928389397)(85827821059158)(95692535739014)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR07MB1358; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1358; x-forefront-prvs: 0582641F53 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(396003)(366004)(39860400002)(39380400002)(13464003)(189003)(199004)(43544003)(33656002)(3846002)(102836004)(3660700001)(6346003)(2906002)(6306002)(7736002)(316002)(106356001)(8936002)(6116002)(53946003)(66066001)(6506007)(53936002)(8676002)(93886005)(76176011)(561944003)(81156014)(478600001)(14454004)(68736007)(5660300001)(26005)(305945005)(55016002)(59450400001)(9686003)(7696005)(3280700002)(53546011)(74316002)(99286004)(229853002)(966005)(81166006)(186003)(86362001)(39060400002)(105586002)(6246003)(5250100002)(6436002)(2900100001)(25786009)(2950100002)(5890100001)(4326008)(110136005)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1358; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-microsoft-antispam-message-info: hy+s4tVU3pbV8fJWzDH2z1hu49Av2idhfqYLbtmzpl98vvSyZkPQWe4NQ9bW/u9ohseIiQAsKzFT2mJyv6quNQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 629154ad-7035-4d4c-198e-08d572c065f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2018 09:01:41.0923 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1358 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGO/fezetodFpO3yyNRiJYTc2KKVFGhAuKCgrKIp15U5tO2aap gYmFqUFYWk2bXzEzLS3F8Ds/EnJkGBb5mamTQFMLV6assl2PQf/93ud5OO8Hh6UlBoErG6XR c1qNKlomFDF5p+p8tieXpwX7zPUhhW3uPqNorUqlFBlXZxiFIXcWBTLKXFu1QNmQ/9FBaTIt UspvNVeFx5hg0Z5wLjoqgdN67w0VRVpuG+m4/AcoceGRlUpFU7FZyJEFvBOGzIUoC4lYCX6J wDhfICRFF4LJ4TSGLxg8R0Fxd+aKc5eCvOv1DCnGEExU36P4x4T4IFgzxuwplnXC8dA9K+Fl GnvCQHElzfM67A8tb+qW4044AIYsUzSJa8BousTLDPaAgrZWIc9ifBZms1+stOpkIKfgrYDP O9pbdT07xyPCbjBWqSCdXGBwoogim2EwNffQhKUwafkjICwDw9TgCrtBb9GN5e0B11LQNPCZ IYYcnt+aQYSPQLmpRUhC9qsUlRU6EMMLyix1y/MDVkOlRU3ky9BknnYgeQMNM0t9DiSzEUYW A4heKoSK1gYmG3nn/zc4YTn038kVEt4KD0u+0PnLt1gL5rwJphgxFUiq43RhMRE7/OScNuq8 TherkWs4fQ2y/5f2WptHPXo3vb8DYRbJVotHnNOCJQJVgi4ppgMBS8ucxGyJXRKHq5KSOW1s iDY+mtN1oA0sI3MRmw+JgyU4QqXn1BwXx2n/uRTr6JqKAle1fA/IGBd4VqhfJ1wx7+ssrJIJ rvWkNIVuCUH92TYXd7/JZIT9PUvSl5IOSL8GlbY1b1s/Fpfyoerm09TNbkdTes807s6xWp+4 Pw5q9ND/FJ12Xhj9lHny4ry7W1iE68Cm9lfDxlHT8Srz+K5f0vTD2h8nqmnvmPfi3xfWuCT6 yhhdpMrXi9bqVH8BK5Xy4SsDAAA= Archived-At: Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 13 Feb 2018 09:01:53 -0000 Hello Pascal, Thanks, that was great clarification and now I see your valid points much b= etter. Cheers Bala'zs -----Original Message----- From: Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Sent: 2018. febru=E1r 12. 20:31 To: Bal=E1zs Varga A ; Jouni ; Lou Berger Cc: detnet@ietf.org Subject: RE: [Detnet] IPv6 encapsulation in dataplane doc Hello Bal=E1zs - Why no seq.num in IP? That would mean no PREF, no IOD function within Det= Net domain Which is an IP PSN. > Sorry, I was unclear and I agree with you. There would not be one provide= d the source, but then the ingress edge would need to encapsulate the packe= t. In which case it would set the next as destination and insert a DestOpt= before the routing header if any.=20 > Note that if have not (Yet? Should we???) looked at a way to express the = ladder as a routing header. Till then, the most sensible thing is to send t= he packet unicast to the next Relay node (next relays if this node is a rep= licator). We still may indicate intermediate transit nodes as a routing hea= der though. The DestOpt would then be after the routing header, not before. -------------------- - What would be the gain from a "L4 transport designed to provide PREF, IOD= , FEC, ... "? I mean that would be a duplicate, as in the DetNet network You would have t= he same function. > I would say that these functions are closely related to traditional capab= ilities of a L4 transport. TCP reorders the bytes in the stream and provide= s ARQ which is an alternate to FEC. MP TCP distributes packets over differe= nt paths. Doing those functions at L4 allows real end to end service even i= f there is no specialized NIC. It keeps the IP layer intact which seemed to= be a goal in that discussion. It allows features like Network Coding which= are certainly easier to do high in the stack of a host system than in a li= ne card or a fast path in a router. - Checking L4 within the DetNet domain would require DPI, what I guess we d= o not want. > Architecturally speaking, the L4 transport implements a detnet service la= yer though it would not be done at DetNet WG. When that L4 transport is ena= bled, some service layer functions provided by the network would not be use= d, or would rely on their own sequencing. I'm not excluding that vendors co= uld propose some DPI for very specific applications, e.g. recognizing a par= ticular industrial protocol and routing it differently, say over a DetNet p= ath. But this is an implementation game and I do not see what's there for u= s to standardize. ------------------------ - I am also somewhat confused by your WiFi example. I mean in TSN/DetNet sc= enarios end-systems are always assumed to be in sync with their controller(= s). So I do not agree with this statement: "Existing industrial devices can= claim a rough need for a given rate but were not necessarily designed to p= rovide guarantees for burstiness in DetNet terms."=20 > I mean that an application on a device that was designed before TSN and t= hat does not connect to the controller and that may not participate to PTP = may still benefit from DetNet. But even if the application needs are roughl= y known, the granularity of the TSPEC may not be the one TSN expects. There= is a need for an adaptation to absorb the burst that a strict ingress filt= ering may treat too violently. Reference here is to CIR in frame relay netw= orks serving TCP and SNA flows. Disserving would be a more proper term, I h= ave a long history on implementing that, and I would like to avoid going th= rough that pain again. What I meant with Wi-Fi is different; I showed that in some cases we really= need the PREF from the source node if it is a wireless node. Because the l= osses mostly happen on the radio hop. I had in mind that with a form of mul= ticast, the source STA could send a single packet to 2 or more Ingress Rout= ers connected to different APs, and then all the received copies would foll= ow their own DetNet path. Take care, Pascal -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Bal=E1zs Varga A Sent: lundi 12 f=E9vrier 2018 17:37 To: Pascal Thubert (pthubert) ; Jouni ; Lou Berger Cc: detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Hi Pascal, I have a lot of sympathy on your view. - OK: "DetNet would provide its own sequencing based on reception order at = ingress edge." - OK: "ingress edge may be a NIC card" - OK: "avoid DPI" However I have some questions for clarification on your final conclusions: - Why no seq.num in IP? That would mean no PREF, no IOD function within the= DetNet domain Which is an IP PSN. - What would be the gain from a "L4 transport designed to provide PREF, IOD= , FEC, ... "? I mean that would be a duplicate, as in the DetNet network You would have t= he same function. Checking L4 within the DetNet domain would require DPI, what I guess we do = not want. - I am also somewhat confused by your WiFi example. I mean in TSN/DetNet sc= enarios end-systems are always assumed to be in sync with their controller(= s). So I do not agree with this statement: "Existing industrial devices can= claim a rough need for a given rate but were not necessarily designed to p= rovide guarantees for burstiness in DetNet terms."=20 Thanks & Cheers Bala'zs -----Original Message----- From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of Pascal Thubert (= pthubert) Sent: 2018. febru=E1r 12. 11:30 To: Jouni ; Lou Berger Cc: detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc Hello Jouni and Lou: Just to make sure we are on the same line: - IPvX (=3D=3Dv4/v6) would signal the flow implicitly - derived from the tu= ples- but not the source sequencing. No need to change IP. - DetNet may provide PREF/IOD from the edge ingress. DetNet would provide i= ts own sequencing based on reception order at ingress edge. - The ingress edge may be a NIC card in the originating node. It would be = operating below IPvX and possibly equipped with 2 Ethernet ports and capabl= e of PREF. - Anything above IP is beyond charter. A upper layer sequence may be visibl= e in the L4-transport or at the application layer but DetNet will not look = for it. A snooping edge device doing DPI may dig in the packet and find inf= ormation for packet identification and ordering, for a particular applicati= on, and that is beyond the interests of the WG. - A L4 transport may be designed to provide PREF, IOD, FEC (network coding)= and whatever else needed. This would be done in TSV Area with DetNet's ble= ssing. Do we agree? Pascal -----Original Message----- From: Jouni [mailto:jouni.nospam@gmail.com] Sent: dimanche 11 f=E9vrier 2018 22:43 To: Lou Berger Cc: Pascal Thubert (pthubert) ; detnet@ietf.org Subject: Re: [Detnet] IPv6 encapsulation in dataplane doc >>>> * End systems cannot participate to DetNet service layer packet=20 >>>> elimination & duplication business. If they still do e.g. using=20 >>>> DetNet DstOpt that is separate from subnet/transport layer provided se= rvice. >>>=20 >>> True, end station participation in PREF wouldn't be possible in this=20 >>> simplified approach for IP, but the end stations *could* still=20 >>> participate in the equivalent function provided by a sub-net layer=20 >>> such as TSN. So end to end detnet traffic protection is not=20 >>> possible, but it doesn't mean it can't be provided by lower network=20 >>> layers. The gain here is a simplified and unified IP solution and=20 >>> simplified host processing/support, albeit with a loss of one of the=20 >>> three end to end detnet service attributes. >>=20 >> Yes, that's true (as I already clarified in my latest mail to Pascal). >>=20 >=20 > yes. It's good for all to remember that DetNet is just as much (if=20 > not > more) about supporting explicit routes with congestion protection and=20 > latency control.... Indeed.. >>>> * Different subnet/transport layer segments in the DetNet domain=20 >>>> are likely to use their own sequencing and duplication &=20 >>>> elimination solutions. I am not sure how independent those will be=20 >>>> e.g., is the sequence numbering unified across or only per segment. >>>> The former is not IMO easy and the latter easily reduces to single=20 >>>> points between segments to handle number book keeping properly. >>>=20 >>> Agreed. The question for the WG is this a reasonable compromise in=20 >>> order to in our *initial* solution defined by the WG. -- Nothing=20 >>> says we can't come back and improve on this in the future, but it=20 >>> will allow us to get *something* useful defined with less complexity. >>=20 >> I would first specify the required steps that make IP as-is work within = one subnet/transport layer segment. That should be an achievable goal with = a limitation of e.g. a single interconnection point between subnet/transpor= t layer segments of different types/solutions.=20 >>=20 >=20 > sure. as long as one of the 'attached stations' can be a router. Yes. That's the plan at least from my side. - Juoni >=20 >> After that look into solving multiple interconnection points.. and there= the L4 path that Pascal mentioned or that IPv6 DetNet DstOpt of mine could= be way forward. >>=20 >=20 > yes, this would be good follow on work... >=20 > Cheers, > Lou >> - Jouni >>=20 >>=20 >>>=20 >>>=20 >>>>=20 >>>> Regardless the above I am keen to explore this alternative approach.. >>>>=20 >>>=20 >>> Great - look forward to hear the results! >>> Lou >>>=20 >>>>=20 >>>> - Jouni >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> *From:* detnet [mailto:detnet-bounces@ietf.org] *On Behalf Of *Lou=20 >>>> Berger >>>> *Sent:* Wednesday, February 7, 2018 17:00 PM >>>> *To:* Pascal Thubert (pthubert) ;=20 >>>> detnet@ietf.org >>>> *Subject:* Re: [Detnet] IPv6 encapsulation in dataplane doc >>>>=20 >>>>=20 >>>>=20 >>>> Pascal/all, >>>>=20 >>>> At the last interim a proposal was made to simplify IP processing,=20 >>>> at least for the initial detnet solution, by leaving PREF to the=20 >>>> subnet/transport layers (i.e., TSN and MPLS) and providing DetNet=20 >>>> flow identification based on typical IP 5-tuple perhaps + dscp. >>>> This approach has several benefits beyond simplification, notably=20 >>>> it will work for both ipv4 and IPv6, and doesn't require any=20 >>>> modification to encapsulation / formats. >>>>=20 >>>> It would be really valuable to get feedback from the whole working=20 >>>> group if this simplification is acceptable or has unacceptable limitat= ions. >>>>=20 >>>> Lou >>>>=20 >>>> On February 7, 2018 8:28:02 AM "Pascal Thubert (pthubert)" >>>> > wrote: >>>>=20 >>>> Dear all >>>>=20 >>>>=20 >>>>=20 >>>> This is about the IPv6 encapsulation and more precisely >>>>=20 >>>>=20 >>>>=20 >>>> Therefore, if a DetNet-aware end system=20 >>>> only >>>>=20 >>>> inserted the DetNet Destination Option into the IPv6 but e.g.,=20 >>>> a >>>>=20 >>>> DetNet Edge node is configured to enforce an explicit route=20 >>>> for the >>>>=20 >>>> IPv6 packet using a source routing header, then it has no=20 >>>> other >>>>=20 >>>> possibility than add an outer tunneling IPv6 header with=20 >>>> required >>>>=20 >>>> extension headers in it. The processing of IPv6 packets in a=20 >>>> DetNet >>>>=20 >>>> Edge node is discussed further in Section 6.4.1 >>>> . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> With the current spec, a source sends a DetNet packet as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> This creates a duplication of the DetNet Destination Option. >>>>=20 >>>>=20 >>>>=20 >>>> There are alternatives >>>>=20 >>>>=20 >>>>=20 >>>> a) whereby the packet is tunneled from the source to the detnet >>>> ingress, and based on its state the DetNet ingress accepts the >>>> packet, processes it and then resends it. The tunneled version of >>>> this could be: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> /=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Which allows the ingress to tunnel to the egress as follows: >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (to final destination) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> b) whereby the PREF is done by the end nodes and the tunnel is >>>> transport only, meaning that there are 2 tunnels A and B and that >>>> the source sends twice a packet like this: >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H Optional DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet ingress edge X)| >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> And then the ingress node needs to re-encapsulate as >>>>=20 >>>>=20 >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | | >>>>=20 >>>> | DetNet Flow | >>>>=20 >>>> | Payload | >>>>=20 >>>> | | >>>>=20 >>>> /---------------------------------\ >>>>=20 >>>> H DetNet DstOpt Hdr H >>>>=20 >>>> \---------------------------------/ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D final destination) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ >>>>=20 >>>> | Routing header | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>> | IPv6 header | >>>>=20 >>>> | (dest =3D DetNet egress edge X) | >>>>=20 >>>> | (with set Flow label) | >>>>=20 >>>> +---------------------------------+ >>>>=20 >>>>=20 >>>>=20 >>>> Cheers, >>>>=20 >>>>=20 >>>>=20 >>>> Pascal >>>>=20 >>>> _______________________________________________ >>>> detnet mailing list >>>> detnet@ietf.org >>>> https://www.ietf.org/mailman/listinfo/detnet >>>>=20 >>>=20 >>=20 >>=20 >=20 _______________________________________________ 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 From nobody Wed Feb 14 09:28:33 2018 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 2301212D7F1 for ; Wed, 14 Feb 2018 09:28:32 -0800 (PST) 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, 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_RP_MATCHES_RCVD=-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 wlTuVPXZGOPd for ; Wed, 14 Feb 2018 09:28:30 -0800 (PST) Received: from dggwg11-dlp.huawei.com (lhrrg12-dlp.huawei.com [194.213.3.62]) (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 6454A12D7F0 for ; Wed, 14 Feb 2018 09:28:30 -0800 (PST) Received: from DFWPML706-CHM.exmail.huawei.com (unknown [172.18.7.65]) by Forcepoint Email with ESMTP id 1994156A38ACC for ; Wed, 14 Feb 2018 17:28:05 +0000 (GMT) Received: from DFWPML704-CHM.exmail.huawei.com ([169.254.1.24]) by DFWPML706-CHM.exmail.huawei.com ([169.254.3.74]) with mapi id 14.03.0361.001; Wed, 14 Feb 2018 09:28:05 -0800 From: Norman Finn To: "detnet@ietf.org" Thread-Topic: DetNet interim possibilities Thread-Index: AdOluSNudGjH4qM+RgmCWftHauNUDQ== Date: Wed, 14 Feb 2018 17:28:02 +0000 Message-ID: <3DF0466E9510274382F5B74499ACD6F8D03175@DFWPML704-CHM.exmail.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.18.4.33] Content-Type: multipart/alternative; boundary="_000_3DF0466E9510274382F5B74499ACD6F8D03175DFWPML704CHMexmai_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Detnet] DetNet interim possibilities X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 17:28:32 -0000 --_000_3DF0466E9510274382F5B74499ACD6F8D03175DFWPML704CHMexmai_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The IEEE 802.1 and 802.3 people be meeting in Pittsburgh Pennsylvania the w= eek of May 21, 2018 for a full 5-day meeting. This may provide a starting = point for arranging a DetNet interim. http://1.ieee802.org/meetings/ -- Norm --_000_3DF0466E9510274382F5B74499ACD6F8D03175DFWPML704CHMexmai_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
The IEEE 802.1 and 802.3 people be meeting in Pittsburgh Pennsylvani= a the week of May 21, 2018 for a full 5-day meeting.  This may provide= a starting point for arranging a DetNet interim.

http://1.ieee802.org/meetings/

-- Norm
--_000_3DF0466E9510274382F5B74499ACD6F8D03175DFWPML704CHMexmai_-- From nobody Wed Feb 14 09:43:12 2018 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 C9FEF12D77E for ; Wed, 14 Feb 2018 09:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.209 X-Spam-Level: X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-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 hYZ16oU6xtGv for ; Wed, 14 Feb 2018 09:43:09 -0800 (PST) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AD5126D85 for ; Wed, 14 Feb 2018 09:43:08 -0800 (PST) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 0812758C5DD; Wed, 14 Feb 2018 18:43:05 +0100 (CET) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id DEEB9B0DA66; Wed, 14 Feb 2018 18:43:04 +0100 (CET) Date: Wed, 14 Feb 2018 18:43:04 +0100 From: Toerless Eckert To: Norman Finn Cc: "detnet@ietf.org" Message-ID: <20180214174304.GU19760@faui40p.informatik.uni-erlangen.de> References: <3DF0466E9510274382F5B74499ACD6F8D03175@DFWPML704-CHM.exmail.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DF0466E9510274382F5B74499ACD6F8D03175@DFWPML704-CHM.exmail.huawei.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [Detnet] DetNet interim possibilities X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 17:43:11 -0000 Would be good to collect names of WG participants interested to go to the interim and have them express their preferences and constraints wrt. time and location. That way its a lot easier to figure out what would be a good location and time. I remember when we had IETF in Orlando folks stayed over to IEEE, but then again, it was Orlando. Not sure how attractive it is even for IEEE participants to extend an already gruelsome IEEE week with a detnet meeting In Pittsburgh. On Wed, Feb 14, 2018 at 05:28:02PM +0000, Norman Finn wrote: > The IEEE 802.1 and 802.3 people be meeting in Pittsburgh Pennsylvania the week of May 21, 2018 for a full 5-day meeting. This may provide a starting point for arranging a DetNet interim. > > http://1.ieee802.org/meetings/ > > -- Norm > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Wed Feb 14 10:07:06 2018 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 BEDF812D810 for ; Wed, 14 Feb 2018 10:07:04 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151863162477.19238.14898414258900511430.idtracker@ietfa.amsl.com> Date: Wed, 14 Feb 2018 10:07:04 -0800 From: IETF Secretariat Archived-At: Subject: [Detnet] Milestones changed for detnet WG X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 18:07:05 -0000 Deleted milestone "WG adoption of use cases". Deleted milestone "WG adoption of problem statement (with supported deployments)". Deleted milestone "WG adoption of architecture document". Deleted milestone "WG adoption of data plane specification". Deleted milestone "WG adoption of data flow information model". Changed milestone "Finalize use cases (informational)", set due date to March 2018 from September 2016, added draft-ietf-detnet-use-cases to milestone. Changed milestone "Submit architecture (Standards Track)", set due date to April 2018 from November 2016. Changed milestone "WG adoption of YANG model", set due date to September 2018 from August 2016. Changed milestone "Finalize problem statement (informational)", set due date to November 2018 from September 2016. Changed milestone "Submit data plane specification (Standards Track)", set due date to November 2018 from January 2017. Changed milestone "Submit data flow information model (informational)", set due date to December 2018 from February 2017. Changed milestone "Submit YANG model (Standards Track)", set due date to April 2019 from April 2017. Changed milestone "Re-charter or close", set due date to July 2019 from April 2017. URL: https://datatracker.ietf.org/wg/detnet/about/ From nobody Wed Feb 14 10:33:46 2018 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 E868412D80E for ; Wed, 14 Feb 2018 10:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 9R8snTl0lJci for ; Wed, 14 Feb 2018 10:28:32 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 5E8F1126D45 for ; Wed, 14 Feb 2018 10:28:32 -0800 (PST) Received: from cmgw3 (unknown [10.0.90.84]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 12F751AB2A3 for ; Wed, 14 Feb 2018 11:28:32 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id AiUU1x00K2SSUrH01iUXvK; Wed, 14 Feb 2018 11:28:32 -0700 X-Authority-Analysis: v=2.2 cv=XM9AcUpE c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=-tsAPJKn6S7ax0J5AdsA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 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:Cc:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=uj105Eb1XrjV9XziYkLx2bjk7Kl8D9ewD2Miko095ac=; b=FPfU8WKnGHhS64OpX9B2gUGiLw j/vNj6uzQa2YPc5fUlfqtPYkaDiw9Tp8cKucM9tY4A3tWciSuG2nKrpOD2j0k6LWABxBWEjtgC1KF yhKTXUxESrvY3KdtYauzrlZp7; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:35530 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1em1nA-000rfD-4B; Wed, 14 Feb 2018 11:28:28 -0700 To: ethan.grossman@dolby.com, craig.gunther@harman.com, pthubert@cisco.com, pwetterw@cisco.com, raymond.jean@hydro.qc.ca, jouni.nospam@gmail.com, yu1.kaneko@toshiba.co.jp, sdas@appcomsci.com, zhayiyong@huawei.com, balazs.a.varga@ericsson.com, janos.farkas@ericsson.com, franz-josef.goetz@siemens.com, juergen.jues.schmitt@siemens.com, xvilajosana@worldsensing.com, toktam.mahmoodi@kcl.ac.uk, spis@intracom-telecom.com, petra.vizarreta@lkn.ei.tum.de, huang.guangping@zte.com.cn, gengxuesong@huawei.com, diego.dujovne@mail.udp.cl, maseewal@cisco.com Cc: DetNet Chairs , DetNet WG From: Lou Berger Message-ID: Date: Wed, 14 Feb 2018 13:28:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1em1nA-000rfD-4B X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:35530 X-Source-Auth: lberger@labn.net X-Email-Count: 26 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: X-Mailman-Approved-At: Wed, 14 Feb 2018 10:33:45 -0800 Subject: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 18:28:34 -0000 Authors, Contributors, WG, As part of the preparation for WG LC: Are you aware of any IPR that applies to drafts identified above? Please state either: "No, I'm not aware of any IPR that applies to this draft" or "Yes, I'm aware of IPR that applies to this draft" If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3669, 5378 and 8179 for more details)? If yes to the above, please state either: "Yes, the IPR has been disclosed in compliance with IETF IPR rules" or "No, the IPR has not been disclosed" If you answer no, please provide any additional details you think appropriate. If you are listed as a document author or contributor please answer the above by responding to this email regardless of whether or not you are aware of any relevant IPR. This document will not advance to the next stage until a response has been received from each author and listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. If you are on the WG email list or attend WG meetings but are not listed as an author or contributor, we remind you of your obligations under the IETF IPR rules which encourages you to notify the IETF if you are aware of IPR of others on an IETF contribution, or to refrain from participating in any contribution or discussion related to your undisclosed IPR. For more information, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. Thank you, DetNet WG Chairs PS Please include all listed in the headers of this message in your response. From nobody Wed Feb 14 11:43:59 2018 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 4098F12D837; Wed, 14 Feb 2018 10:53:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.9 X-Spam-Level: X-Spam-Status: No, score=-2.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dolby.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 DW_Ejr0njD92; Wed, 14 Feb 2018 10:53:29 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0125.outbound.protection.outlook.com [104.47.32.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508E412D85F; Wed, 14 Feb 2018 10:53:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Dolby.onmicrosoft.com; s=selector1-dolby-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RgEitG2fu/rAwlfriSFlolAhiRUrXtPmrIFZBKLZzS8=; b=LJO8oPqsqW9pEpLCjUh85QpL5FneebOBhJoYBgvLURFJko9UHJUSAYWRgnv2SmJ+OE1OXTmdP0TXkZLv4ZxIkLgIaFHm/688EPZEh8fyqef5UMo/p1cuatXTONcGRBThyG4iegKLXznzYjx30t+papm6LsYZPtUYXBWj+6sPHtQ= Received: from BY2PR0601MB1591.namprd06.prod.outlook.com (10.163.107.149) by BY2PR0601MB1624.namprd06.prod.outlook.com (10.163.107.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Wed, 14 Feb 2018 18:53:17 +0000 Received: from BY2PR0601MB1591.namprd06.prod.outlook.com ([10.163.107.149]) by BY2PR0601MB1591.namprd06.prod.outlook.com ([10.163.107.149]) with mapi id 15.20.0485.017; Wed, 14 Feb 2018 18:53:17 +0000 From: "Grossman, Ethan A." To: Lou Berger , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGl7KTx5DKkG0G8TO2oT9hE8KOkPoWQ Date: Wed, 14 Feb 2018 18:53:16 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=eagros@dolby.com; x-originating-ip: [8.39.141.5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BY2PR0601MB1624; 7:Lyjuust8iwV+1wdjq3X3kMNOosJaH5VWiUUEoZ80dDc8p6w0Jj2tegHBOYBzjR0IX4wxA6dx9NpUnOvigqdceGw6Cojws0M2okJG8qYk377OKYxO/diQxFMcDJ/FkxFNtLtsLWlvLsqag9qHxUpdJfd6WqRbPN+UnYDugnnoiSDmnREF4BZmZbYOZtS9rPTBzUXEP41u5O91TODupQPF+5uNJgTK2qty5M+HuJM0YZE9XgGNsY0RQfLqgoM6Z9xq x-ms-office365-filtering-correlation-id: 41e3491e-bb4c-4bc4-b9b7-08d573dc35a3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(7021125)(5600026)(4604075)(3008032)(4534165)(7022125)(4603075)(4627221)(201702281549075)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603307)(7153060)(7193020); SRVR:BY2PR0601MB1624; x-ms-traffictypediagnostic: BY2PR0601MB1624: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(41521381080715)(50582790962513)(85827821059158)(95692535739014)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123560045)(20161123558120)(2016111802025)(20161123564045)(20161123562045)(6072148)(6043046)(201708071742011); SRVR:BY2PR0601MB1624; BCL:0; PCL:0; RULEID:; SRVR:BY2PR0601MB1624; x-forefront-prvs: 0583A86C08 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39380400002)(346002)(376002)(366004)(396003)(39850400004)(189003)(199004)(13464003)(8936002)(74316002)(478600001)(110136005)(54906003)(8676002)(81156014)(316002)(14454004)(966005)(81166006)(7416002)(3280700002)(3660700001)(68736007)(4326008)(76176011)(97736004)(6116002)(2201001)(7696005)(2501003)(2906002)(39060400002)(3846002)(86362001)(33656002)(102836004)(25786009)(9686003)(186003)(6306002)(53936002)(77096007)(229853002)(99286004)(26005)(53546011)(105586002)(6246003)(8666007)(6436002)(6506007)(2900100001)(66066001)(2950100002)(305945005)(7736002)(106356001)(5660300001)(55016002)(921003)(1121003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0601MB1624; H:BY2PR0601MB1591.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: dolby.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: WdZyBhYPgs3hvR92uXCfHCw3MTf6Hs4mE7W90nn4KZTqHNRFz/q3R69TX4l6TY8SbFWT1sfjOtEZpvG1hXrUkA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: dolby.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41e3491e-bb4c-4bc4-b9b7-08d573dc35a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 18:53:16.9121 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 05408d25-cd0d-40c8-8962-5462de64a318 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR0601MB1624 Archived-At: X-Mailman-Approved-At: Wed, 14 Feb 2018 11:43:58 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 14 Feb 2018 18:53:32 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K RXRoYW4uDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFtt YWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE0LCAy MDE4IDEwOjI4IEFNDQpUbzogR3Jvc3NtYW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9sYnkuY29tPjsg Y3JhaWcuZ3VudGhlckBoYXJtYW4uY29tOyBwdGh1YmVydEBjaXNjby5jb207IHB3ZXR0ZXJ3QGNp c2NvLmNvbTsgcmF5bW9uZC5qZWFuQGh5ZHJvLnFjLmNhOyBqb3VuaS5ub3NwYW1AZ21haWwuY29t OyB5dTEua2FuZWtvQHRvc2hpYmEuY28uanA7IHNkYXNAYXBwY29tc2NpLmNvbTsgemhheWl5b25n QGh1YXdlaS5jb207IGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTsgamFub3MuZmFya2FzQGVy aWNzc29uLmNvbTsgZnJhbnotam9zZWYuZ29ldHpAc2llbWVucy5jb207IGp1ZXJnZW4uanVlcy5z Y2htaXR0QHNpZW1lbnMuY29tOyB4dmlsYWpvc2FuYUB3b3JsZHNlbnNpbmcuY29tOyB0b2t0YW0u bWFobW9vZGlAa2NsLmFjLnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29tOyBwZXRyYS52aXph cnJldGFAbGtuLmVpLnR1bS5kZTsgaHVhbmcuZ3VhbmdwaW5nQHp0ZS5jb20uY247IGdlbmd4dWVz b25nQGh1YXdlaS5jb207IGRpZWdvLmR1am92bmVAbWFpbC51ZHAuY2w7IG1hc2Vld2FsQGNpc2Nv LmNvbQ0KQ2M6IERldE5ldCBDaGFpcnMgPGRldG5ldC1jaGFpcnNAaWV0Zi5vcmc+OyBEZXROZXQg V0cgPGRldG5ldEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0 Zi1kZXRuZXQtdXNlLWNhc2VzLTEzDQoNCg0KDQpBdXRob3JzLCBDb250cmlidXRvcnMsIFdHLA0K DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTEM6DQoNCkFyZSB5b3UgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRzIGlkZW50aWZpZWQgYWJvdmU/DQoNClBs ZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg YXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBh cHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5LCA1Mzc4 IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVh c2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBj b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpvcg0KIk5vLCB0aGUgSVBSIGhhcyBub3Qg YmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIgbm8sIHBsZWFzZSBwcm92aWRlIGFueSBh ZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxp c3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRo ZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy IG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQg d2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBi ZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9U RTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRP IExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBt ZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3 ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVz IHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJl IG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4g ZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24gb3IgZGlzY3Vzc2lvbiByZWxh dGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNl IHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0dHA6Ly90cmFjLnRvb2xzLmlldGYub3Jn L2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5Lg0KDQpUaGFuayB5b3Us DQpEZXROZXQgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhl IGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIgcmVzcG9uc2UuDQoNCg0K From nobody Wed Feb 14 16:04:21 2018 X-Mailman-Approved-At: Wed, 14 Feb 2018 16:04:19 -0800 Subject: [Detnet] (no subject) X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 14 Feb 2018 22:47:38 -0000 X-List-Received-Date: Wed, 14 Feb 2018 22:47:38 -0000 From nobody Thu Feb 15 05:19:35 2018 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 EB0D212D879 for ; Wed, 14 Feb 2018 20:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mail-udp-cl.20150623.gappssmtp.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 BrSS4ceJJKuk for ; Wed, 14 Feb 2018 20:31:51 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 35EDC12D86E for ; Wed, 14 Feb 2018 20:31:51 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id l124so5961901oib.0 for ; Wed, 14 Feb 2018 20:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mail-udp-cl.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9GdXZLMrPwIqrxPgqye0hxNG6fCdAuA+Ue3vpU/j8f4=; b=uQZesGkXo6AvwAxVdJ8yZ42H++PzM7c0xEtJAdwvt1B5VCtha1dEwvijXv7zJR8jB2 /MjeJJxyASk4sg0LTaqHAV2XjcHtrHj6tr7a6Bg0FN/bDRSwS+1onNS7IOA93FJcuuEO L1DBcEFBmTI1qRY8HCN59+xvnRPTgg/eOqiWcG/pWfwgbJEJUsWzaNQ22nZN4L8qnn7g YcpHYqyHIdTzzjBXZnf896vwcXT9nLycovD0dCEel6M7/C1PDBRT9HUadAchstGgPLkK 8VkyArTwLqxWrj/dqbvmi8gno7xiOqum31fix4Q0AzQb/CxeUwj7OZOLcL4tSM/9F3He ZkAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9GdXZLMrPwIqrxPgqye0hxNG6fCdAuA+Ue3vpU/j8f4=; b=pKnAzDJ4o6d5/laQwTfDFlRaORYZ1NRX7JJKrZVN3kOOe4vc+XR7Ip8kkW6wT392z7 BMOr5SAcjry+b7StL9bLNdYhCf1z5+t4jD3uqqepgGhfiVaR5UMnJlZecW3FVGlfVYXX m5KLT3tfV1AlgSVbqyRtaHkpQ9XF3JmB+GgW5oDFTorJKaqrGBVIihUlERL/JanDzY/3 DG7q4Xc4G4AgXTE+efdHJctsPqS9T4kWgLeLL1bc/Rx1aN4rmq4AcXeJ6yFEUeKUpNhf tYmjz9Eo+Y4PVYJA9VSB4jBweHPER6cpWGy2UyfHOWnZ7gp6HajPCi4wWQw2XRNoAzbh P9xg== X-Gm-Message-State: APf1xPBVI6CbXyl3ziludQb+3nokVGIP4lqqX/aKgoC3k61/u4ysjlZ3 PqOotiisPOSfvqkCsvFzxZYdLpCu+HJ46aYpRgBnWA== X-Google-Smtp-Source: AH8x227e5XxPYFzJjE6vK0jiuRqWmykOUhC5uoJez4MkN+a8SPTMJHF8nkaxhnyGZkPMPE+1dKTxrwIT6xZPVI1dRek= X-Received: by 10.202.221.131 with SMTP id u125mr950596oig.104.1518669110104; Wed, 14 Feb 2018 20:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.24.22 with HTTP; Wed, 14 Feb 2018 20:31:49 -0800 (PST) In-Reply-To: References: From: "Prof. Diego Dujovne" Date: Thu, 15 Feb 2018 01:31:49 -0300 Message-ID: To: Xavier Vilajosana Cc: "Grossman, Ethan A." , Lou Berger , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "maseewal@cisco.com" , DetNet Chairs , DetNet WG Content-Type: multipart/alternative; boundary="001a113d6018d6f190056538b4c4" Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 05:19:33 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 04:31:55 -0000 --001a113d6018d6f190056538b4c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft. Thanks, Diego Le jeudi 15 f=C3=A9vrier 2018, Xavier Vilajosana a =C3=A9crit : > No, I'm not aware of any IPR that applies to this draft > > thanks for handling this. > > regards > X > > > *Xavier Vilajosana* > *CIO* > Office: <+34%20934%2018%2005%2085>[ <+34%20934%2018%2005%2085>+34] 93 418 > 0585 <+34%20934%2018%2005%2085> > Cell: <+34%20934%2018%2005%2085>[ <+34%20934%2018%2005%2085>+34] 646 633 > 681 <+34%20934%2018%2005%2085> > xvilajosana@worldsensing.com > > > 2018-02-14 19:53 GMT+01:00 Grossman, Ethan A. : > >> No, I'm not aware of any IPR that applies to this draft >> Ethan. >> >> -----Original Message----- >> From: Lou Berger [mailto:lberger@labn.net] >> Sent: Wednesday, February 14, 2018 10:28 AM >> To: Grossman, Ethan A. ; craig.gunther@harman.com; >> pthubert@cisco.com; pwetterw@cisco.com; raymond.jean@hydro.qc.ca; >> jouni.nospam@gmail.com; yu1.kaneko@toshiba.co.jp; sdas@appcomsci.com; >> zhayiyong@huawei.com; balazs.a.varga@ericsson.com; >> janos.farkas@ericsson.com; franz-josef.goetz@siemens.com; >> juergen.jues.schmitt@siemens.com; xvilajosana@worldsensing.com; >> toktam.mahmoodi@kcl.ac.uk; spis@intracom-telecom.com; >> petra.vizarreta@lkn.ei.tum.de; huang.guangping@zte.com.cn; >> gengxuesong@huawei.com; diego.dujovne@mail.udp.cl; maseewal@cisco.com >> Cc: DetNet Chairs ; DetNet WG >> Subject: Regarding IPR on draft-ietf-detnet-use-cases-13 >> >> >> >> Authors, Contributors, WG, >> >> As part of the preparation for WG LC: >> >> Are you aware of any IPR that applies to drafts identified above? >> >> Please state either: >> >> "No, I'm not aware of any IPR that applies to this draft" >> or >> "Yes, I'm aware of IPR that applies to this draft" >> >> If so, has this IPR been disclosed in compliance with IETF IPR rules (se= e >> RFCs 3669, 5378 and 8179 for more details)? >> >> If yes to the above, please state either: >> >> "Yes, the IPR has been disclosed in compliance with IETF IPR rules" >> or >> "No, the IPR has not been disclosed" >> >> If you answer no, please provide any additional details you think >> appropriate. >> >> If you are listed as a document author or contributor please answer the >> above by responding to this email regardless of whether or not you are >> aware of any relevant IPR. This document will not advance to the next st= age >> until a response has been received from each author and listed contribut= or. >> NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. >> >> If you are on the WG email list or attend WG meetings but are not listed >> as an author or contributor, we remind you of your obligations under the >> IETF IPR rules which encourages you to notify the IETF if you are aware = of >> IPR of others on an IETF contribution, or to refrain from participating = in >> any contribution or discussion related to your undisclosed IPR. For more >> information, please see the RFCs listed above and >> http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. >> >> Thank you, >> DetNet WG Chairs >> >> PS Please include all listed in the headers of this message in your >> response. >> >> >> > > > > > > *BARCELONA* > Viriat, 47, Edificio Numancia 1, 10th floor, 08014 Barcelona, Spain > *LONDON* > 9-10 Carlos Place, Mayfair - London W1K > > 3AT, United Kingdom - +44 (0) 203 807 2495 > This email may contain confidential information and may be subject to > professional secrecy. Its dissemination, copying, distribution, > reproduction, forwarding or any other unauthorized use is strictly > prohibited. If you receive this email in error, please notify us > immediately and arrange for its deletion, together with any attached > documents. > Este correo electr=C3=B3nico puede contener informaci=C3=B3n estrictament= e > confidencial, y puede estar sometido al secreto profesional. Est=C3=A1 pr= ohibida > su difusi=C3=B3n, copia, distribuci=C3=B3n, reproducci=C3=B3n, reenv=C3= =ADo o cualquier otro > uso no autorizado. En caso de recibir este correo por error, rogamos nos = lo > comunique de inmediato y proceda a su eliminaci=C3=B3n, as=C3=AD como de = cualquier > documento que se adjunte. > --=20 DIEGO DUJOVNE Profesor Asociado Escuela de Inform=C3=A1tica y Telecomunicaciones Facultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile www.ingenieria.udp.cl (56 2) 676 8125 --001a113d6018d6f190056538b4c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft.
Thanks,

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Diego
Le=C2=A0jeudi 15 f=C3=A9vrier 2018, Xavier Vilajosana <xvilajosana@worldsensing.com> a =C3= =A9crit=C2=A0:
No, I'm n= ot aware of any IPR that applies to this draft

thanks for handling this.

= regards
X


2018-02-14 19:53 GMT+01:00 Grossman, Ethan A= . <eagros@dolby.com>:
No, I'm not aware of any IPR that applies to this draft
Ethan.

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.net]
Sent: Wednesday, February 14, 2018 10:28 AM
To: Grossman, Ethan A. <eagros@dolby.com>; craig.gunther@harman.com; pthubert@cisco.com; pwetterw@cisco.com; raymond.jean@hydro.qc.ca;= jouni.nospam@g= mail.com; yu1.kaneko@toshiba.co.jp; sdas@appcomsci.com; zhayiyong@huawei.com; balazs.a.varga@ericsson.com; janos.farkas@ericss= on.com; franz-josef.goetz@siemens.com; juergen.jues.schmitt@siemens.com= ; xvilajo= sana@worldsensing.com; toktam.mahmoodi@kcl.ac.uk; spis@intracom-telecom.com; petra.vizarreta@lk= n.ei.tum.de; huang.guangping@zte.com.cn; gengxuesong@huawei.com; diego.dujovne@mail.udp.cl; maseewal@cisco.com Cc: DetNet Chairs <detnet-chairs@ietf.org>; DetNet WG <detnet@ietf.org>
Subject: Regarding IPR on draft-ietf-detnet-use-cases-13



Authors, Contributors, WG,

As part of the preparation for WG LC:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intellectu= alProperty.

Thank you,
DetNet WG Chairs

PS Please include all listed in the headers of this message in your respons= e.




This emai= l may contain confidential information and may be subject to professional s= ecrecy. Its dissemination, copying, distribution, reproduction, forwarding = or any other unauthorized use is strictly prohibited. If you receive this e= mail in error, please notify us immediately and arrange for its deletion, t= ogether with any attached documents.
<= /a>=
BARCELONA
Viriat, 47, Edificio Numancia 1, 10th floor, 08014 Barcelona, Spain
= LONDON
9-10 Carlos Place, Mayfair - London W1K 3AT, United Kin= gdom - +44 (0) 203 807 2495
Este correo electr=C3=B3nico pue= de contener informaci=C3=B3n estrictamente confidencial, y puede estar some= tido al secreto profesional. Est=C3=A1 prohibida su difusi=C3=B3n, copia, d= istribuci=C3=B3n, reproducci=C3=B3n, reenv=C3=ADo o cualquier otro uso no a= utorizado. En caso de recibir este correo por error, rogamos nos lo comuniq= ue de inmediato y proceda a su eliminaci=C3=B3n, as=C3=AD como de cualquier= documento que se adjunte.


--
DIEGO DUJOVNE<= br>Profesor Asociado
Escuela de Inform=C3=A1tica y TelecomunicacionesFacultad de Ingenier=C3=ADa - Universidad Diego Portales - Chile
www.ingenieria.udp.cl<= /a>
(56 2) 676 8125

--001a113d6018d6f190056538b4c4-- From nobody Thu Feb 15 05:19:47 2018 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 2CFE5126CBF; Thu, 15 Feb 2018 02:14:39 -0800 (PST) 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, 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, URIBL_BLOCKED=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 zC36evJoS3sJ; Thu, 15 Feb 2018 02:14:36 -0800 (PST) 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 3FC591201F8; Thu, 15 Feb 2018 02:14:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4738; q=dns/txt; s=iport; t=1518689676; x=1519899276; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vM2wkany+OH98IXGEuKeOa+S5Csxul4ar8828eCj8ls=; b=bH/tX2NDBrtBvVLtNaAEx0PMBirPHEmzFk0VqHJZzQoelG6mFVAYYQ0z e0g/DITnW/gjAhJ0XABAZ5XzqK/UFcViGmgBIt6qbk+eTZQcoCncwV5Kc 9rb158rhejMCa3MgbJY9fqmul525ZZ3L38etulh5CcVn7HBQCm9FxyN1U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AvAQDFXIVa/4QNJK1cDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDITFmcCgKg1uKJY4EggKBF4d/jkUVggMKI4UYAhqCYFQYAQI?= =?us-ascii?q?BAQEBAQECayiFIwEBAQEDIxFABQwEAgEIEQQBAQMCIwMCAgIfERQBCAgCBAENB?= =?us-ascii?q?QiKFQMVEK5TgieEFwEBgysNgTKCEwEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BD4N?= =?us-ascii?q?zgieBV4Fogy6CazkLAoE+ARECATWDAIJlBaN9NQkCiB6IWoUCgihnhUOLfY4ES?= =?us-ascii?q?IkiAhEZAYE7AR85YHFwFT2CRgmELwQBOngBjHyBGQEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,516,1511827200"; d="scan'208";a="70580849" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 10:14:35 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id w1FAEZGY015933 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 10:14:35 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 04:14:34 -0600 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.1320.000; Thu, 15 Feb 2018 04:14:34 -0600 From: "Pascal Thubert (pthubert)" To: "Grossman, Ethan A." , Lou Berger , "craig.gunther@harman.com" , "Patrick Wetterwald (pwetterw)" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "Maik Seewald (maseewal)" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGkSQAlgPAViUOPtPGY9LZH36OkozYAgACa8NA= Date: Thu, 15 Feb 2018 10:14:05 +0000 Deferred-Delivery: Thu, 15 Feb 2018 10:13:44 +0000 Message-ID: <3f8688494a33461980f63713700cfa5b@XCH-RCD-001.cisco.com> References: In-Reply-To: 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.228.216.16] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 05:19:45 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 10:14:39 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQpQYXNjYWwNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBHcm9zc21hbiwgRXRo YW4gQS4gW21haWx0bzplYWdyb3NAZG9sYnkuY29tXSANClNlbnQ6IG1lcmNyZWRpIDE0IGbDqXZy aWVyIDIwMTggMTk6NTMNClRvOiBMb3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjsgY3JhaWcu Z3VudGhlckBoYXJtYW4uY29tOyBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIDxwdGh1YmVydEBj aXNjby5jb20+OyBQYXRyaWNrIFdldHRlcndhbGQgKHB3ZXR0ZXJ3KSA8cHdldHRlcndAY2lzY28u Y29tPjsgcmF5bW9uZC5qZWFuQGh5ZHJvLnFjLmNhOyBqb3VuaS5ub3NwYW1AZ21haWwuY29tOyB5 dTEua2FuZWtvQHRvc2hpYmEuY28uanA7IHNkYXNAYXBwY29tc2NpLmNvbTsgemhheWl5b25nQGh1 YXdlaS5jb207IGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTsgamFub3MuZmFya2FzQGVyaWNz c29uLmNvbTsgZnJhbnotam9zZWYuZ29ldHpAc2llbWVucy5jb207IGp1ZXJnZW4uanVlcy5zY2ht aXR0QHNpZW1lbnMuY29tOyB4dmlsYWpvc2FuYUB3b3JsZHNlbnNpbmcuY29tOyB0b2t0YW0ubWFo bW9vZGlAa2NsLmFjLnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29tOyBwZXRyYS52aXphcnJl dGFAbGtuLmVpLnR1bS5kZTsgaHVhbmcuZ3VhbmdwaW5nQHp0ZS5jb20uY247IGdlbmd4dWVzb25n QGh1YXdlaS5jb207IGRpZWdvLmR1am92bmVAbWFpbC51ZHAuY2w7IE1haWsgU2Vld2FsZCAobWFz ZWV3YWwpIDxtYXNlZXdhbEBjaXNjby5jb20+DQpDYzogRGV0TmV0IENoYWlycyA8ZGV0bmV0LWNo YWlyc0BpZXRmLm9yZz47IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3JnPg0KU3ViamVjdDogUkU6 IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEzDQoNCk5vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQgRXRoYW4u DQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3UgQmVyZ2VyIFttYWlsdG86 bGJlcmdlckBsYWJuLm5ldF0NClNlbnQ6IFdlZG5lc2RheSwgRmVicnVhcnkgMTQsIDIwMTggMTA6 MjggQU0NClRvOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb20+OyBjcmFpZy5n dW50aGVyQGhhcm1hbi5jb207IHB0aHViZXJ0QGNpc2NvLmNvbTsgcHdldHRlcndAY2lzY28uY29t OyByYXltb25kLmplYW5AaHlkcm8ucWMuY2E7IGpvdW5pLm5vc3BhbUBnbWFpbC5jb207IHl1MS5r YW5la29AdG9zaGliYS5jby5qcDsgc2Rhc0BhcHBjb21zY2kuY29tOyB6aGF5aXlvbmdAaHVhd2Vp LmNvbTsgYmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tOyBqYW5vcy5mYXJrYXNAZXJpY3Nzb24u Y29tOyBmcmFuei1qb3NlZi5nb2V0ekBzaWVtZW5zLmNvbTsganVlcmdlbi5qdWVzLnNjaG1pdHRA c2llbWVucy5jb207IHh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb207IHRva3RhbS5tYWhtb29k aUBrY2wuYWMudWs7IHNwaXNAaW50cmFjb20tdGVsZWNvbS5jb207IHBldHJhLnZpemFycmV0YUBs a24uZWkudHVtLmRlOyBodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbjsgZ2VuZ3h1ZXNvbmdAaHVh d2VpLmNvbTsgZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDsgbWFzZWV3YWxAY2lzY28uY29tDQpD YzogRGV0TmV0IENoYWlycyA8ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZz47IERldE5ldCBXRyA8ZGV0 bmV0QGlldGYub3JnPg0KU3ViamVjdDogUmVnYXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWRldG5l dC11c2UtY2FzZXMtMTMNCg0KDQoNCkF1dGhvcnMsIENvbnRyaWJ1dG9ycywgV0csDQoNCkFzIHBh cnQgb2YgdGhlIHByZXBhcmF0aW9uIGZvciBXRyBMQzoNCg0KQXJlIHlvdSBhd2FyZSBvZiBhbnkg SVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCg0KUGxlYXNlIHN0 YXRlIGVpdGhlcjoNCg0KIk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVz IHRvIHRoaXMgZHJhZnQiDQpvcg0KIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCg0KSWYgc28sIGhhcyB0aGlzIElQUiBiZWVuIGRpc2Nsb3NlZCBpbiBj b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMgKHNlZSBSRkNzIDM2NjksIDUzNzggYW5kIDgx NzkgZm9yIG1vcmUgZGV0YWlscyk/DQoNCklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0 ZSBlaXRoZXI6DQoNCiJZZXMsIHRoZSBJUFIgaGFzIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFu Y2Ugd2l0aCBJRVRGIElQUiBydWxlcyINCm9yDQoiTm8sIHRoZSBJUFIgaGFzIG5vdCBiZWVuIGRp c2Nsb3NlZCINCg0KSWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9u YWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFz IGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yIHBsZWFzZSBhbnN3ZXIgdGhlIGFib3Zl IGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90 IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5v dCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFzIGJlZW4gcmVj ZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1dG9yLiBOT1RFOiBUSElT IEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNTQUdFJ1MgVE8gTElORVMu DQoNCklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdz IGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWlu ZCB5b3Ugb2YgeW91ciBvYmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2gg ZW5jb3VyYWdlcyB5b3UgdG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBS IG9mIG90aGVycyBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9tIHBh cnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8g eW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2Ugc2VlIHRo ZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAv aWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkRldE5l dCBXRyBDaGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVy cyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0KDQo= From nobody Thu Feb 15 05:19:59 2018 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 6BC1312D893; Thu, 15 Feb 2018 01:57:10 -0800 (PST) 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 1p04heFpaNE7; Thu, 15 Feb 2018 01:57:08 -0800 (PST) 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 5FE95126CBF; Thu, 15 Feb 2018 01:57:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2706; q=dns/txt; s=iport; t=1518688628; x=1519898228; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=9wts2rbxzQdJGaSMPSIC8PXYFfj6CiFqvkfxnHw4Yo4=; b=mQvhGCAq6ftlPs29xrxIC6sldFfrjy/lgOpPydaPAx+tuDnjrdizpGGg /5fhnPPbeoMGjzxqcSHm3mMTmTrfjrqs8HqVQ8vTgxagnsOVvmf9t4t47 IhU2vX9SRwl+PDNyyrUVUsCAPT3zutgO7tvvrxqn+x8o7f7jkTfh8RLaS E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AtAQB6WIVa/5NdJa1cDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQGDITFmcCgKg1uKJY4EgxmWRBWCAwojhRgCGoJfVBgBAgE?= =?us-ascii?q?BAQEBAQJrKIUkBiMRQAUQAgEIDgwCJgICAjAVEAIEAQ0FijUQrlCCJ4QXAQG?= =?us-ascii?q?EaoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPg3OCJ4FXgWgpgwWDJAsCgT4?= =?us-ascii?q?BEgEfF4MAMYI0AQSkMgkCiB6NZYIfZ4VDi32OBIlqAhEZAYE7AR85YHFwFT0?= =?us-ascii?q?qAYIbCYQvBAE6eAGLV4ElgRkBAQE?= X-IronPort-AV: E=Sophos;i="5.46,516,1511827200"; d="scan'208";a="354465036" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 09:57:06 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1F9v6a6016049 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 09:57:06 GMT Received: from xch-rtp-014.cisco.com (64.101.220.154) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 04:57:05 -0500 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.1320.000; Thu, 15 Feb 2018 04:57:05 -0500 From: "Patrick Wetterwald (pwetterw)" To: Lou Berger , "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "Pascal Thubert (pthubert)" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "Maik Seewald (maseewal)" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpkNVWb7nuKri/USA4ztsejekbA== Date: Thu, 15 Feb 2018 09:57:05 +0000 Message-ID: <2D9C05C2-E2A8-4F37-9B1A-99D6C9E3B8FC@cisco.com> 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/10.9.0.180116 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.228.216.32] Content-Type: text/plain; charset="utf-8" Content-ID: <499B4F1A80B8A1408B4CBAE8F6E576C6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 05:19:53 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 09:57:10 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KUGF0cmljaw0KDQrvu79PbiAxNC8wMi8yMDE4IDE5OjI4LCAiTG91IEJlcmdlciIgPGxiZXJn ZXJAbGFibi5uZXQ+IHdyb3RlOg0KDQogICAgDQogICAgDQogICAgQXV0aG9ycywgQ29udHJpYnV0 b3JzLCBXRywNCiAgICANCiAgICBBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTEM6 DQogICAgDQogICAgQXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFm dHMgaWRlbnRpZmllZCBhYm92ZT8NCiAgICANCiAgICBQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KICAg IA0KICAgICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0Ig0KICAgIG9yDQogICAgIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMg dG8gdGhpcyBkcmFmdCINCiAgICANCiAgICBJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xv c2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcw0KICAgIChzZWUgUkZDcyAzNjY5 LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KICAgIA0KICAgIElmIHllcyB0byB0 aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQogICAgDQogICAgIlllcywgdGhlIElQUiBo YXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KICAg IG9yDQogICAgIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQogICAgDQogICAg SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5 b3UgdGhpbmsNCiAgICBhcHByb3ByaWF0ZS4NCiAgICANCiAgICBJZiB5b3UgYXJlIGxpc3RlZCBh cyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZQ0KICAg IGFib3ZlIGJ5IHJlc3BvbmRpbmcgdG8gdGhpcyBlbWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIg b3Igbm90IHlvdSBhcmUNCiAgICBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3Vt ZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQNCiAgICBzdGFnZSB1bnRpbCBhIHJlc3Bv bnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZA0KICAgIGNv bnRyaWJ1dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJ UyBNRVNTQUdFJ1MNCiAgICBUTyBMSU5FUy4NCiAgICANCiAgICBJZiB5b3UgYXJlIG9uIHRoZSBX RyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQNCiAg ICBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBvYmxp Z2F0aW9ucyB1bmRlcg0KICAgIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlv dSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZQ0KICAgIGF3YXJlIG9mIElQUiBvZiBvdGhl cnMgb24gYW4gSUVURiBjb250cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbQ0KICAgIHBhcnRp Y2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9uIHJlbGF0ZWQgdG8geW91 cg0KICAgIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUg dGhlIFJGQ3MgbGlzdGVkIGFib3ZlDQogICAgYW5kDQogICAgaHR0cDovL3RyYWMudG9vbHMuaWV0 Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQogICAgDQog ICAgVGhhbmsgeW91LA0KICAgIERldE5ldCBXRyBDaGFpcnMNCiAgICANCiAgICBQUyBQbGVhc2Ug aW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3Vy DQogICAgcmVzcG9uc2UuDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Thu Feb 15 05:20:12 2018 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 CFF0A1270A3; Wed, 14 Feb 2018 20:35:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.041 X-Spam-Level: X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_IMAGE_RATIO_04=0.556, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=toshibaap.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 1FVECle8D1kV; Wed, 14 Feb 2018 20:35:38 -0800 (PST) Received: from mo.tsb.2iij.net (mo1501.tsb.2iij.net [210.149.48.173]) (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 2451B12025C; Wed, 14 Feb 2018 20:35:37 -0800 (PST) Received: by mo.tsb.2iij.net (tsb-mo1501) id w1F4YrN2017778; Thu, 15 Feb 2018 13:34:53 +0900 Received: from unknown [172.27.153.187] (EHLO tsb-mr1501.hop.2iij.net) by mas1511.tsb.2iij.net(mxl_mta-7.2.4-7) with ESMTP id ded058a5.0.4442.00-696.9069.mas1511.tsb.2iij.net (envelope-from ); Thu, 15 Feb 2018 13:34:55 +0900 (JST) X-MXL-Hash: 5a850def33552f1b-dc735734d53d04d0c86aabda59055ab70eace805 Received: from imx12.toshiba.co.jp (imx12.toshiba.co.jp [61.202.160.132]) by relay.tsb.2iij.net (tsb-mr1501) with ESMTP id w1F4YkNM000658; Thu, 15 Feb 2018 13:34:46 +0900 Received: from tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp ([133.199.232.103]) by imx12.toshiba.co.jp with ESMTP id w1F4YklM001009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Feb 2018 13:34:46 +0900 (JST) Received: from tsbmgw-mgw01 (localhost [127.0.0.1]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id w1F4YkFb017388; Thu, 15 Feb 2018 13:34:46 +0900 Received: from localhost ([127.0.0.1]) by tsbmgw-mgw01 (JAMES SMTP Server 2.3.1) with SMTP ID 493; Thu, 15 Feb 2018 13:34:46 +0900 (JST) Received: from arc11.toshiba.co.jp ([133.199.90.127]) by tsbmgw-mgw01.tsbmgw-mgw01.toshiba.co.jp (8.13.8/8.14.5) with ESMTP id w1F4Yk7L017382; Thu, 15 Feb 2018 13:34:46 +0900 Received: (from root@localhost) by arc11.toshiba.co.jp id w1F4YjNw018068; Thu, 15 Feb 2018 13:34:45 +0900 (JST) Received: from ovp11.toshiba.co.jp [133.199.90.148] by arc11.toshiba.co.jp with ESMTP id PAA18066; Thu, 15 Feb 2018 13:34:45 +0900 Received: from mx12.toshiba.co.jp (mx12.toshiba.co.jp [133.199.90.142]) by ovp11.toshiba.co.jp with ESMTP id w1F4Yjhb007666; Thu, 15 Feb 2018 13:34:45 +0900 (JST) Received: from tgxml245.toshiba.local by toshiba.co.jp id w1F4YiYO027407; Thu, 15 Feb 2018 13:34:45 +0900 (JST) Received: from TGXML263.toshiba.local (133.199.86.60) by tgxml245.toshiba.local (133.199.62.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 15 Feb 2018 13:34:43 +0900 Received: from JPN01-OS2-obe.outbound.protection.outlook.com (23.103.139.150) by stsap1.toshiba.co.jp (61.202.160.137) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Thu, 15 Feb 2018 13:34:47 +0900 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toshibaap.onmicrosoft.com; s=selector1-toshiba-co-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=l/XIqwByErO2MtNELQYKQzETXtpvpPlkFvZCQRH6qso=; b=B16ZhNO7OfbW3q2qAlOF0NHwy0O5hCIkgQm89M8H355sjAtvU8tFQhIzqqmh/SVms+HeV3V56MoO+ScXz9z38G/J8cfqNt9NZL3+VP4Kh6Ot2T1b3TBehBfzGA+2b9oDuZ176D9wriz0oKYS8FNjFylVkbqlYiumlsB93VZ3Aus= Received: from OSBPR01MB1766.jpnprd01.prod.outlook.com (52.134.227.145) by OSBPR01MB1478.jpnprd01.prod.outlook.com (52.134.224.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 15 Feb 2018 04:34:32 +0000 Received: from OSBPR01MB1766.jpnprd01.prod.outlook.com ([fe80::8085:2b81:db01:762f]) by OSBPR01MB1766.jpnprd01.prod.outlook.com ([fe80::8085:2b81:db01:762f%13]) with mapi id 15.20.0485.017; Thu, 15 Feb 2018 04:34:32 +0000 From: To: CC: , , , , , , , , , , , , , , , , , , , , , , Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGtA5v9LJQPYEi48F0yr+s3gKOkPqEAgACgb4CAAAE2gIAAAEKw Date: Thu, 15 Feb 2018 04:34:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: ja-JP X-MS-Has-Attach: yes authentication-results: spf=none (sender IP is ) smtp.mailfrom=yu1.kaneko@toshiba.co.jp; x-originating-ip: [103.91.184.160] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; OSBPR01MB1478; 7:C1zpfbkaQ2/vuEvBvHZzRLd31LWPKjCY4UHPa3H4mtp01NjsWrGMunfogqpOt3a691KHxCAuirPApIwP069ijrDWfRenMmHZR5lsIj1CmCZIIlJlpeIWZy6MtJALG2TC4QrQ+576Dpi93kKoxBrm+m4VfVruuwDPctSbsF/hDpUoosS3bU9g1spCYhAhT0p7ZTL21LBCgaKfxe1OLOIFb3pnumz0YBsUDAywDF1dxySrHe7IAs9Qn8wqkD6d7mzU x-ms-office365-filtering-correlation-id: 6a08a73d-6463-4ed8-43ea-08d5742d68cb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(49563074)(7193020); SRVR:OSBPR01MB1478; x-ms-traffictypediagnostic: OSBPR01MB1478: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(31418570063057)(41521381080715)(50582790962513)(85827821059158)(3650984025655)(211936372134217)(95692535739014)(254730959083279); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123558120)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:OSBPR01MB1478; BCL:0; PCL:0; RULEID:; SRVR:OSBPR01MB1478; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39850400004)(39380400002)(366004)(376002)(377424004)(189003)(13464003)(199004)(7416002)(99286004)(93886005)(8676002)(8936002)(106356001)(74482002)(59450400001)(6506007)(102836004)(316002)(81166006)(81156014)(2900100001)(53546011)(99936001)(68736007)(76176011)(606006)(74316002)(86362001)(7736002)(9686003)(236005)(6306002)(54896002)(55016002)(54556002)(6916009)(2950100002)(42882006)(2906002)(53936002)(966005)(105586002)(4326008)(3660700001)(33656002)(107886003)(53386004)(7696005)(39060400002)(478600001)(8666007)(6436002)(229853002)(5250100002)(733005)(5890100001)(3280700002)(54906003)(66066001)(6116002)(3846002)(5660300001)(25786009)(14454004)(6246003)(97736004)(186003)(14971765001)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:OSBPR01MB1478; H:OSBPR01MB1766.jpnprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: toshiba.co.jp does not designate permitted sender hosts) x-microsoft-antispam-message-info: xtl6ndI9GTIEiL5pGqmN0ak/k1nS0zpT4EJVZUyTFBXQwhruiCWg+FyWCXowhdBNHAcIIJ6aaKuuThLu5o/GvQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/related; boundary="_005_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_"; type="multipart/alternative" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a08a73d-6463-4ed8-43ea-08d5742d68cb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 04:34:32.2826 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f109924e-fb71-4ba0-b2cc-65dcdf6fbe4f X-MS-Exchange-Transport-CrossTenantHeadersStamped: OSBPR01MB1478 X-OriginatorOrg: toshiba.co.jp MSSCP.TransferMailToMossAgent: 103 X-MAIL-FROM: X-SOURCE-IP: [172.27.153.187] X-Spam: exempt Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 05:20:04 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 04:35:43 -0000 --_005_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_ Content-Type: multipart/alternative; boundary="_000_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_" --_000_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KUmVnYXJkcywNCkthbmVrbw0KDQoNCkZyb206IFByb2YuIERpZWdvIER1am92bmUgW21haWx0 bzpkaWVnby5kdWpvdm5lQG1haWwudWRwLmNsXQ0KU2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDE1 LCAyMDE4IDE6MzIgUE0NClRvOiBYYXZpZXIgVmlsYWpvc2FuYSA8eHZpbGFqb3NhbmFAd29ybGRz ZW5zaW5nLmNvbT4NCkNjOiBHcm9zc21hbiwgRXRoYW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb20+OyBM b3UgQmVyZ2VyIDxsYmVyZ2VyQGxhYm4ubmV0PjsgY3JhaWcuZ3VudGhlckBoYXJtYW4uY29tOyBw dGh1YmVydEBjaXNjby5jb207IHB3ZXR0ZXJ3QGNpc2NvLmNvbTsgcmF5bW9uZC5qZWFuQGh5ZHJv LnFjLmNhOyBqb3VuaS5ub3NwYW1AZ21haWwuY29tOyBrYW5la28geXUgPHl1MS5rYW5la29AdG9z aGliYS5jby5qcD47IHNkYXNAYXBwY29tc2NpLmNvbTsgemhheWl5b25nQGh1YXdlaS5jb207IGJh bGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTsgamFub3MuZmFya2FzQGVyaWNzc29uLmNvbTsgZnJh bnotam9zZWYuZ29ldHpAc2llbWVucy5jb207IGp1ZXJnZW4uanVlcy5zY2htaXR0QHNpZW1lbnMu Y29tOyB0b2t0YW0ubWFobW9vZGlAa2NsLmFjLnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29t OyBwZXRyYS52aXphcnJldGFAbGtuLmVpLnR1bS5kZTsgaHVhbmcuZ3VhbmdwaW5nQHp0ZS5jb20u Y247IGdlbmd4dWVzb25nQGh1YXdlaS5jb207IG1hc2Vld2FsQGNpc2NvLmNvbTsgRGV0TmV0IENo YWlycyA8ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZz47IERldE5ldCBXRyA8ZGV0bmV0QGlldGYub3Jn Pg0KU3ViamVjdDogUmU6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNh c2VzLTEzDQoNCk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRo aXMgZHJhZnQuDQpUaGFua3MsDQoNCiAgICAgICAgICAgRGllZ28NCg0KTGUgamV1ZGkgMTUgZsOp dnJpZXIgMjAxOCwgWGF2aWVyIFZpbGFqb3NhbmEgPHh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5j b208bWFpbHRvOnh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb20+PiBhIMOpY3JpdCA6DQpObywg SSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0DQoNCnRo YW5rcyBmb3IgaGFuZGxpbmcgdGhpcy4NCg0KcmVnYXJkcw0KWA0KDQoNClhhdmllciBWaWxham9z YW5hDQpDSU8NCk9mZmljZTo8dGVsOiszNCUyMDkzNCUyMDE4JTIwMDUlMjA4NT5bPHRlbDorMzQl MjA5MzQlMjAxOCUyMDA1JTIwODU+KzM0XSA5MyA0MTggMDU4NTx0ZWw6KzM0JTIwOTM0JTIwMTgl MjAwNSUyMDg1Pg0KQ2VsbDo8dGVsOiszNCUyMDkzNCUyMDE4JTIwMDUlMjA4NT5bPHRlbDorMzQl MjA5MzQlMjAxOCUyMDA1JTIwODU+KzM0XSA2NDYgNjMzIDY4MTx0ZWw6KzM0JTIwOTM0JTIwMTgl MjAwNSUyMDg1Pg0KeHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbQ0KPG1haWx0bzp5b3VyZW1h aWxAd29ybGRzZW5zaW5nLmNvbT4NCg0KMjAxOC0wMi0xNCAxOTo1MyBHTVQrMDE6MDAgR3Jvc3Nt YW4sIEV0aGFuIEEuIDxlYWdyb3NAZG9sYnkuY29tPG1haWx0bzplYWdyb3NAZG9sYnkuY29tPj46 DQpObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0 DQpFdGhhbi4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IExvdSBCZXJnZXIg W21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0PG1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0Pl0NClNlbnQ6 IFdlZG5lc2RheSwgRmVicnVhcnkgMTQsIDIwMTggMTA6MjggQU0NClRvOiBHcm9zc21hbiwgRXRo YW4gQS4gPGVhZ3Jvc0Bkb2xieS5jb208bWFpbHRvOmVhZ3Jvc0Bkb2xieS5jb20+PjsgY3JhaWcu Z3VudGhlckBoYXJtYW4uY29tPG1haWx0bzpjcmFpZy5ndW50aGVyQGhhcm1hbi5jb20+OyBwdGh1 YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT47IHB3ZXR0ZXJ3QGNpc2Nv LmNvbTxtYWlsdG86cHdldHRlcndAY2lzY28uY29tPjsgcmF5bW9uZC5qZWFuQGh5ZHJvLnFjLmNh PG1haWx0bzpyYXltb25kLmplYW5AaHlkcm8ucWMuY2E+OyBqb3VuaS5ub3NwYW1AZ21haWwuY29t PG1haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tPjsgeXUxLmthbmVrb0B0b3NoaWJhLmNvLmpw PG1haWx0bzp5dTEua2FuZWtvQHRvc2hpYmEuY28uanA+OyBzZGFzQGFwcGNvbXNjaS5jb208bWFp bHRvOnNkYXNAYXBwY29tc2NpLmNvbT47IHpoYXlpeW9uZ0BodWF3ZWkuY29tPG1haWx0bzp6aGF5 aXlvbmdAaHVhd2VpLmNvbT47IGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTxtYWlsdG86YmFs YXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPjsgamFub3MuZmFya2FzQGVyaWNzc29uLmNvbTxtYWls dG86amFub3MuZmFya2FzQGVyaWNzc29uLmNvbT47IGZyYW56LWpvc2VmLmdvZXR6QHNpZW1lbnMu Y29tPG1haWx0bzpmcmFuei1qb3NlZi5nb2V0ekBzaWVtZW5zLmNvbT47IGp1ZXJnZW4uanVlcy5z Y2htaXR0QHNpZW1lbnMuY29tPG1haWx0bzpqdWVyZ2VuLmp1ZXMuc2NobWl0dEBzaWVtZW5zLmNv bT47IHh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb208bWFpbHRvOnh2aWxham9zYW5hQHdvcmxk c2Vuc2luZy5jb20+OyB0b2t0YW0ubWFobW9vZGlAa2NsLmFjLnVrPG1haWx0bzp0b2t0YW0ubWFo bW9vZGlAa2NsLmFjLnVrPjsgc3Bpc0BpbnRyYWNvbS10ZWxlY29tLmNvbTxtYWlsdG86c3Bpc0Bp bnRyYWNvbS10ZWxlY29tLmNvbT47IHBldHJhLnZpemFycmV0YUBsa24uZWkudHVtLmRlPG1haWx0 bzpwZXRyYS52aXphcnJldGFAbGtuLmVpLnR1bS5kZT47IGh1YW5nLmd1YW5ncGluZ0B6dGUuY29t LmNuPG1haWx0bzpodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbj47IGdlbmd4dWVzb25nQGh1YXdl aS5jb208bWFpbHRvOmdlbmd4dWVzb25nQGh1YXdlaS5jb20+OyBkaWVnby5kdWpvdm5lQG1haWwu dWRwLmNsPG1haWx0bzpkaWVnby5kdWpvdm5lQG1haWwudWRwLmNsPjsgbWFzZWV3YWxAY2lzY28u Y29tPG1haWx0bzptYXNlZXdhbEBjaXNjby5jb20+DQpDYzogRGV0TmV0IENoYWlycyA8ZGV0bmV0 LWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZz4+OyBEZXROZXQg V0cgPGRldG5ldEBpZXRmLm9yZzxtYWlsdG86ZGV0bmV0QGlldGYub3JnPj4NClN1YmplY3Q6IFJl Z2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEzDQoNCg0KDQpBdXRo b3JzLCBDb250cmlidXRvcnMsIFdHLA0KDQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3Ig V0cgTEM6DQoNCkFyZSB5b3UgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gZHJhZnRz IGlkZW50aWZpZWQgYWJvdmU/DQoNClBsZWFzZSBzdGF0ZSBlaXRoZXI6DQoNCiJObywgSSdtIG5v dCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0Kb3INCiJZZXMs IEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQiDQoNCklmIHNvLCBo YXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzIChzZWUgUkZDcyAzNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0KDQpJ ZiB5ZXMgdG8gdGhlIGFib3ZlLCBwbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiWWVzLCB0aGUgSVBS IGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMiDQpv cg0KIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCklmIHlvdSBhbnN3ZXIg bm8sIHBsZWFzZSBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJv cHJpYXRlLg0KDQpJZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250 cmlidXRvciBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1h aWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxl dmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFn ZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5k IGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElT VEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KDQpJZiB5b3UgYXJlIG9uIHRoZSBXRyBl bWFpbCBsaXN0IG9yIGF0dGVuZCBXRyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4g YXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMg dW5kZXIgdGhlIElFVEYgSVBSIHJ1bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0 aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4gSUVURiBjb250 cmlidXRpb24sIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmli dXRpb24gb3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3Ig bW9yZSBpbmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kIGh0 dHA6Ly90cmFjLnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVh bFByb3BlcnR5Lg0KDQpUaGFuayB5b3UsDQpEZXROZXQgV0cgQ2hhaXJzDQoNClBTIFBsZWFzZSBp bmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdlIGluIHlvdXIg cmVzcG9uc2UuDQoNCg0KDQpb44Kk44Oh44O844K444Gv5beu5Ye65Lq644Gr44KI44Gj44Gm5YmK 6Zmk44GV44KM44G+44GX44Gf44CCXQ0KDQpb44Kk44Oh44O844K444Gv5beu5Ye65Lq644Gr44KI 44Gj44Gm5YmK6Zmk44GV44KM44G+44GX44Gf44CCXTxodHRwOi8vd3d3Lndvcmxkc2Vuc2luZy5j b20vPg0KDQpb44Kk44Oh44O844K444Gv5beu5Ye65Lq644Gr44KI44Gj44Gm5YmK6Zmk44GV44KM 44G+44GX44Gf44CCXTxodHRwczovL2VzLmxpbmtlZGluLmNvbS9jb21wYW55L3dvcmxkc2Vuc2lu Zy1zLmwubi5lPg0KDQpb44Kk44Oh44O844K444Gv5beu5Ye65Lq644Gr44KI44Gj44Gm5YmK6Zmk 44GV44KM44G+44GX44Gf44CCXTxodHRwczovL3R3aXR0ZXIuY29tL3dvcmxkc2Vuc2luZz4NCg0K W+OCpOODoeODvOOCuOOBr+W3ruWHuuS6uuOBq+OCiOOBo+OBpuWJiumZpOOBleOCjOOBvuOBl+OB n+OAgl08aHR0cHM6Ly93d3cueW91dHViZS5jb20vY2hhbm5lbC9VQ0V4QmQzZ08tWkJad3o0ZnFP cktnV0E+DQoNCg0KQkFSQ0VMT05BDQpWaXJpYXQsIDQ3LCBFZGlmaWNpbyBOdW1hbmNpYSAxLCAx MHRoIGZsb29yLCAwODAxNCBCYXJjZWxvbmEsIFNwYWluDQoNCkxPTkRPTg0KOS0xMCBDYXJsb3Mg UGxhY2UsIE1heWZhaXIgLSBMb25kb24gVzFLPGh0dHBzOi8vbWFwcy5nb29nbGUuY29tLz9xPTkt MTArQ2FybG9zK1BsYWNlLCtNYXlmYWlyKy0rTG9uZG9uK1cxSyZlbnRyeT1nbWFpbCZzb3VyY2U9 Zz4gM0FULCBVbml0ZWQgS2luZ2RvbSAtICs0NCAoMCkgMjAzIDgwNyAyNDk1DQoNCg0KVGhpcyBl bWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5kIG1heSBiZSBzdWJq ZWN0IHRvIHByb2Zlc3Npb25hbCBzZWNyZWN5LiBJdHMgZGlzc2VtaW5hdGlvbiwgY29weWluZywg ZGlzdHJpYnV0aW9uLCByZXByb2R1Y3Rpb24sIGZvcndhcmRpbmcgb3IgYW55IG90aGVyIHVuYXV0 aG9yaXplZCB1c2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl bWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB1cyBpbW1lZGlhdGVseSBhbmQgYXJyYW5nZSBm b3IgaXRzIGRlbGV0aW9uLCB0b2dldGhlciB3aXRoIGFueSBhdHRhY2hlZCBkb2N1bWVudHMuDQoN CkVzdGUgY29ycmVvIGVsZWN0csOzbmljbyBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gZXN0 cmljdGFtZW50ZSBjb25maWRlbmNpYWwsIHkgcHVlZGUgZXN0YXIgc29tZXRpZG8gYWwgc2VjcmV0 byBwcm9mZXNpb25hbC4gRXN0w6EgcHJvaGliaWRhIHN1IGRpZnVzacOzbiwgY29waWEsIGRpc3Ry aWJ1Y2nDs24sIHJlcHJvZHVjY2nDs24sIHJlZW52w61vIG8gY3VhbHF1aWVyIG90cm8gdXNvIG5v IGF1dG9yaXphZG8uIEVuIGNhc28gZGUgcmVjaWJpciBlc3RlIGNvcnJlbyBwb3IgZXJyb3IsIHJv Z2Ftb3Mgbm9zIGxvIGNvbXVuaXF1ZSBkZSBpbm1lZGlhdG8geSBwcm9jZWRhIGEgc3UgZWxpbWlu YWNpw7NuLCBhc8OtIGNvbW8gZGUgY3VhbHF1aWVyIGRvY3VtZW50byBxdWUgc2UgYWRqdW50ZS4N Cg0KDQoNCi0tDQpESUVHTyBEVUpPVk5FDQpQcm9mZXNvciBBc29jaWFkbw0KRXNjdWVsYSBkZSBJ bmZvcm3DoXRpY2EgeSBUZWxlY29tdW5pY2FjaW9uZXMNCkZhY3VsdGFkIGRlIEluZ2VuaWVyw61h IC0gVW5pdmVyc2lkYWQgRGllZ28gUG9ydGFsZXMgLSBDaGlsZQ0Kd3d3LmluZ2VuaWVyaWEudWRw LmNsPGh0dHA6Ly93d3cuaW5nZW5pZXJpYS51ZHAuY2w+DQooNTYgMikgNjc2IDgxMjUNCg0K --_000_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg44K044K344OD44KvIjsNCglwYW5vc2UtMToyIDExIDYg OSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgi Ow0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiTWVpcnlvIFVJIjsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9u dC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiLvvK3vvLMg77yw44K044K344OD44KvIjsNCglwYW5vc2Ut MToyIDExIDYgMCA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQO+8 re+8syDjgrTjgrfjg4Pjgq8iOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxA77yt77yzIO+8sOOCtOOCt+ODg+OCryI7DQoJcGFu b3NlLTE6MiAxMSA2IDAgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToi XEBNZWlyeW8gVUkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuODoeOCpOODquOCqjsNCglwYW5vc2UtMToy IDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOODoeOC pOODquOCqiI7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVm aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBtbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToi77yt77yzIO+8sOOCtOOCt+ODg+OCryI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi4xOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1y ZXBseTsNCglmb250LWZhbWlseToiTWVpcnlvIFVJIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5 OiJBcmlhbCIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjk5LjI1cHQgMzAuMG1tIDMwLjBtbSAzMC4wbW07fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiI+DQo8djp0ZXh0Ym94IGluc2V0PSI1Ljg1cHQsLjdwdCw1Ljg1cHQsLjdwdCIgLz4NCjwvbzpz aGFwZWRlZmF1bHRzPjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJKQSIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5LYW5la288bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVpcnlvIFVJJnF1b3Q7Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVpcnlvIFVJJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4gUHJvZi4gRGllZ28gRHVqb3ZuZSBbbWFpbHRvOmRpZWdvLmR1 am92bmVAbWFpbC51ZHAuY2xdDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5 IDE1LCAyMDE4IDE6MzIgUE08YnI+DQo8Yj5Ubzo8L2I+IFhhdmllciBWaWxham9zYW5hICZsdDt4 dmlsYWpvc2FuYUB3b3JsZHNlbnNpbmcuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gR3Jvc3NtYW4s IEV0aGFuIEEuICZsdDtlYWdyb3NAZG9sYnkuY29tJmd0OzsgTG91IEJlcmdlciAmbHQ7bGJlcmdl ckBsYWJuLm5ldCZndDs7IGNyYWlnLmd1bnRoZXJAaGFybWFuLmNvbTsgcHRodWJlcnRAY2lzY28u Y29tOyBwd2V0dGVyd0BjaXNjby5jb207IHJheW1vbmQuamVhbkBoeWRyby5xYy5jYTsgam91bmku bm9zcGFtQGdtYWlsLmNvbTsga2FuZWtvIHl1ICZsdDt5dTEua2FuZWtvQHRvc2hpYmEuY28uanAm Z3Q7OyBzZGFzQGFwcGNvbXNjaS5jb207IHpoYXlpeW9uZ0BodWF3ZWkuY29tOw0KIGJhbGF6cy5h LnZhcmdhQGVyaWNzc29uLmNvbTsgamFub3MuZmFya2FzQGVyaWNzc29uLmNvbTsgZnJhbnotam9z ZWYuZ29ldHpAc2llbWVucy5jb207IGp1ZXJnZW4uanVlcy5zY2htaXR0QHNpZW1lbnMuY29tOyB0 b2t0YW0ubWFobW9vZGlAa2NsLmFjLnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29tOyBwZXRy YS52aXphcnJldGFAbGtuLmVpLnR1bS5kZTsgaHVhbmcuZ3VhbmdwaW5nQHp0ZS5jb20uY247IGdl bmd4dWVzb25nQGh1YXdlaS5jb207DQogbWFzZWV3YWxAY2lzY28uY29tOyBEZXROZXQgQ2hhaXJz ICZsdDtkZXRuZXQtY2hhaXJzQGlldGYub3JnJmd0OzsgRGV0TmV0IFdHICZsdDtkZXRuZXRAaWV0 Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0 LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPk5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJh ZnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O0RpZWdvPGJyPg0KPGJyPg0KTGUmbmJzcDtqZXVkaSAxNSBmw6l2cmllciAyMDE4LCBYYXZpZXIg VmlsYWpvc2FuYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5j b20iPnh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb208L2E+Jmd0OyBhIMOpY3JpdCZuYnNwOzo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowbW0iPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIyMjIyMjtiYWNrZ3JvdW5k OndoaXRlIj5ObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPnRoYW5rcyBmb3IgaGFuZGxpbmcgdGhpcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPnJlZ2FyZHM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyI+WDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48YnIgY2xlYXI9ImFsbCI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjVwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzNDc3QjkiPlhhdmllciBWaWxham9zYW5hPC9z cGFuPjwvc3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tYm90dG9tOjUuMjVwdCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM2 QzdFODUiPkNJTzwvc3Bhbj48L3N0cm9uZz48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojNkM3RTg1Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTdCMUI0Ij48 YSBocmVmPSJ0ZWw6JiM0MzszNCUyMDkzNCUyMDE4JTIwMDUlMjA4NSIgdGFyZ2V0PSJfYmxhbmsi PjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1NUNDIj5PZmZpY2U6PC9zcGFuPjwvYT48YSBocmVmPSJ0 ZWw6JiM0MzszNCUyMDkzNCUyMDE4JTIwMDUlMjA4NSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMTE1NUNDIj5bPC9zcGFuPjwvYT48YSBocmVmPSJ0ZWw6JiM0MzszNCUyMDkz NCUyMDE4JTIwMDUlMjA4NSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMTE1 NUNDIj4mIzQzOzM0XQ0KIDkzIDQxOCAwNTg1PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6I0E3QjFCNCI+PGEgaHJlZj0idGVsOiYjNDM7MzQlMjA5 MzQlMjAxOCUyMDA1JTIwODUiIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6IzEx NTVDQyI+Q2VsbDo8L3NwYW4+PC9hPjxhIGhyZWY9InRlbDomIzQzOzM0JTIwOTM0JTIwMTglMjAw NSUyMDg1IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPls8L3Nw YW4+PC9hPjxhIGhyZWY9InRlbDomIzQzOzM0JTIwOTM0JTIwMTglMjAwNSUyMDg1IiB0YXJnZXQ9 Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxMTU1Q0MiPiYjNDM7MzRdDQogNjQ2IDYzMyA2 ODE8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJtYXJnaW4tYm90dG9tOjUuMjVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojQTdCMUI0Ij48YSBocmVmPSJtYWlsdG86eW91 cmVtYWlsQHdvcmxkc2Vuc2luZy5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29s b3I6IzExNTVDQyI+eHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbTxicj4NCjwvc3Bhbj48L2E+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj4yMDE4LTAyLTE0IDE5OjUzIEdNVCYjNDM7MDE6MDAgR3Jvc3NtYW4s IEV0aGFuIEEuICZsdDs8YSBocmVmPSJtYWlsdG86ZWFncm9zQGRvbGJ5LmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmVhZ3Jvc0Bkb2xieS5jb208L2E+Jmd0Ozo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBtbSAwbW0gMG1tIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk5vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQ8YnI+DQpF dGhhbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxi cj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPGJyPg0KRnJvbTogTG91IEJlcmdlciBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpsYmVyZ2VyQGxhYm4ubmV0IiB0YXJnZXQ9Il9ibGFuayI+bGJl cmdlckBsYWJuLm5ldDwvYT5dPGJyPg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNCwgMjAx OCAxMDoyOCBBTTxicj4NClRvOiBHcm9zc21hbiwgRXRoYW4gQS4gJmx0OzxhIGhyZWY9Im1haWx0 bzplYWdyb3NAZG9sYnkuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZWFncm9zQGRvbGJ5LmNvbTwvYT4m Z3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmNyYWlnLmd1bnRoZXJAaGFybWFuLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmNyYWlnLmd1bnRoZXJAaGFybWFuLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86cHRo dWJlcnRAY2lzY28uY29tIiB0YXJnZXQ9Il9ibGFuayI+cHRodWJlcnRAY2lzY28uY29tPC9hPjsg PGEgaHJlZj0ibWFpbHRvOnB3ZXR0ZXJ3QGNpc2NvLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPg0KcHdl dHRlcndAY2lzY28uY29tPC9hPjsgPGEgaHJlZj0ibWFpbHRvOnJheW1vbmQuamVhbkBoeWRyby5x Yy5jYSIgdGFyZ2V0PSJfYmxhbmsiPg0KcmF5bW9uZC5qZWFuQGh5ZHJvLnFjLmNhPC9hPjsgPGEg aHJlZj0ibWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj4NCmpv dW5pLm5vc3BhbUBnbWFpbC5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86eXUxLmthbmVrb0B0b3No aWJhLmNvLmpwIiB0YXJnZXQ9Il9ibGFuayI+DQp5dTEua2FuZWtvQHRvc2hpYmEuY28uanA8L2E+ OyA8YSBocmVmPSJtYWlsdG86c2Rhc0BhcHBjb21zY2kuY29tIiB0YXJnZXQ9Il9ibGFuayI+DQpz ZGFzQGFwcGNvbXNjaS5jb208L2E+OyA8YSBocmVmPSJtYWlsdG86emhheWl5b25nQGh1YXdlaS5j b20iIHRhcmdldD0iX2JsYW5rIj56aGF5aXlvbmdAaHVhd2VpLmNvbTwvYT47DQo8YSBocmVmPSJt YWlsdG86YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+YmFsYXpz LmEudmFyZ2FAZXJpY3Nzb24uY29tPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpqYW5vcy5mYXJrYXNA ZXJpY3Nzb24uY29tIiB0YXJnZXQ9Il9ibGFuayI+amFub3MuZmFya2FzQGVyaWNzc29uLmNvbTwv YT47DQo8YSBocmVmPSJtYWlsdG86ZnJhbnotam9zZWYuZ29ldHpAc2llbWVucy5jb20iIHRhcmdl dD0iX2JsYW5rIj5mcmFuei1qb3NlZi5nb2V0ekBzaWVtZW5zLmNvbTwvYT47DQo8YSBocmVmPSJt YWlsdG86anVlcmdlbi5qdWVzLnNjaG1pdHRAc2llbWVucy5jb20iIHRhcmdldD0iX2JsYW5rIj5q dWVyZ2VuLmp1ZXMuc2NobWl0dEBzaWVtZW5zLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86eHZp bGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnh2aWxham9zYW5hQHdv cmxkc2Vuc2luZy5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOnRva3RhbS5tYWhtb29kaUBrY2wu YWMudWsiIHRhcmdldD0iX2JsYW5rIj50b2t0YW0ubWFobW9vZGlAa2NsLmFjLnVrPC9hPjsNCjxh IGhyZWY9Im1haWx0bzpzcGlzQGludHJhY29tLXRlbGVjb20uY29tIiB0YXJnZXQ9Il9ibGFuayI+ c3Bpc0BpbnRyYWNvbS10ZWxlY29tLmNvbTwvYT47DQo8YSBocmVmPSJtYWlsdG86cGV0cmEudml6 YXJyZXRhQGxrbi5laS50dW0uZGUiIHRhcmdldD0iX2JsYW5rIj5wZXRyYS52aXphcnJldGFAbGtu LmVpLnR1bS5kZTwvYT47DQo8YSBocmVmPSJtYWlsdG86aHVhbmcuZ3VhbmdwaW5nQHp0ZS5jb20u Y24iIHRhcmdldD0iX2JsYW5rIj5odWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbjwvYT47DQo8YSBo cmVmPSJtYWlsdG86Z2VuZ3h1ZXNvbmdAaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmdlbmd4 dWVzb25nQGh1YXdlaS5jb208L2E+Ow0KPGEgaHJlZj0ibWFpbHRvOmRpZWdvLmR1am92bmVAbWFp bC51ZHAuY2wiIHRhcmdldD0iX2JsYW5rIj5kaWVnby5kdWpvdm5lQG1haWwudWRwLmNsPC9hPjsN CjxhIGhyZWY9Im1haWx0bzptYXNlZXdhbEBjaXNjby5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXNl ZXdhbEBjaXNjby5jb208L2E+PGJyPg0KQ2M6IERldE5ldCBDaGFpcnMgJmx0OzxhIGhyZWY9Im1h aWx0bzpkZXRuZXQtY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZGV0bmV0LWNoYWly c0BpZXRmLm9yZzwvYT4mZ3Q7OyBEZXROZXQgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpkZXRuZXRA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kZXRuZXRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1 YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEzPGJy Pg0KPGJyPg0KPGJyPg0KPGJyPg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8YnI+DQo8YnI+ DQpBcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTEM6PGJyPg0KPGJyPg0KQXJlIHlv dSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92 ZT88YnI+DQo8YnI+DQpQbGVhc2Ugc3RhdGUgZWl0aGVyOjxicj4NCjxicj4NCiZxdW90O05vLCBJ J20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8 YnI+DQpvcjxicj4NCiZxdW90O1llcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8g dGhpcyBkcmFmdCZxdW90Ozxicj4NCjxicj4NCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNj bG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzNjY5LCA1 Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPzxicj4NCjxicj4NCklmIHllcyB0byB0aGUg YWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6PGJyPg0KPGJyPg0KJnF1b3Q7WWVzLCB0aGUgSVBS IGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBjb21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVv dDs8YnI+DQpvcjxicj4NCiZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQm cXVvdDs8YnI+DQo8YnI+DQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRk aXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS48YnI+DQo8YnI+DQpJZiB5b3Ug YXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBvciBjb250cmlidXRvciBwbGVhc2UgYW5z d2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3 aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9j dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl IGhhcyBiZWVuIHJlY2VpdmVkIGZyb20NCiBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1 dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNT QUdFJ1MgVE8gTElORVMuPGJyPg0KPGJyPg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlz dCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv ciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRo ZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYg aWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9u LA0KIG9yIHRvIHJlZnJhaW4gZnJvbSBwYXJ0aWNpcGF0aW5nIGluIGFueSBjb250cmlidXRpb24g b3IgZGlzY3Vzc2lvbiByZWxhdGVkIHRvIHlvdXIgdW5kaXNjbG9zZWQgSVBSLiBGb3IgbW9yZSBp bmZvcm1hdGlvbiwgcGxlYXNlIHNlZSB0aGUgUkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQo8YSBocmVm PSJodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxl Y3R1YWxQcm9wZXJ0eSIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHk8L2E+Ljxicj4NCjxi cj4NClRoYW5rIHlvdSw8YnI+DQpEZXROZXQgV0cgQ2hhaXJzPGJyPg0KPGJyPg0KUFMgUGxlYXNl IGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0aGlzIG1lc3NhZ2UgaW4geW91 ciByZXNwb25zZS48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjx0YWJsZSBjbGFzcz0iTXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2Vs bHBhZGRpbmc9IjAiIGFsaWduPSJsZWZ0IiB3aWR0aD0iMCIgc3R5bGU9IndpZHRoOjQ4Ny41cHQ7 bWF4LXdpZHRoOjY1MHB4Ij4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzouNzVw dCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVs ZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13 cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVt ZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrO2JvcmRlcjpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MG1tIj48aW1nIGJvcmRlcj0iMCIgd2lkdGg9IjEwMjQiIGhlaWdo dD0iMTAyNCIgaWQ9Il94MDAwMF9pMTAyNSIgc3JjPSJjaWQ6aW1hZ2UwMDEuanBnQDAxRDNBNjYx LkIzMEZDNEYwIiBhbHQ9IuOCpOODoeODvOOCuOOBr+W3ruWHuuS6uuOBq+OCiOOBo+OBpuWJiumZ pOOBleOCjOOBvuOBl+OBn+OAgiI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29s b3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRk IHN0eWxlPSJwYWRkaW5nOi43NXB0IC43NXB0IC43NXB0IC43NXB0Ij4NCjx0YWJsZSBjbGFzcz0i TXNvTm9ybWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHBhZGRpbmc9IjAiIHdpZHRoPSIxMDAlIiBz dHlsZT0id2lkdGg6MTAwLjAlIj4NCjx0Ym9keT4NCjx0cj4NCjx0ZCBzdHlsZT0icGFkZGluZzou NzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVu dC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1l bGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3d3dy53b3JsZHNlbnNpbmcuY29t LyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAx LjBwdDtwYWRkaW5nOjBtbTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdp ZHRoPSIxMDAiIGhlaWdodD0iMTAwIiBpZD0iX3gwMDAwX2kxMDI2IiBzcmM9ImNpZDp+V1JEMDAw LmpwZyIgYWx0PSLjgqTjg6Hjg7zjgrjjga/lt67lh7rkurrjgavjgojjgaPjgabliYrpmaTjgZXj gozjgb7jgZfjgZ/jgIIiPjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4N Cjx0ZCBzdHlsZT0icGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNw YWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVy dGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28t aGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6 Ly9lcy5saW5rZWRpbi5jb20vY29tcGFueS93b3JsZHNlbnNpbmctcy5sLm4uZSIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJib3JkZXI6c29saWQgd2luZG93dGV4dCAxLjBwdDtwYWRkaW5n OjBtbTt0ZXh0LWRlY29yYXRpb246bm9uZSI+PGltZyBib3JkZXI9IjAiIHdpZHRoPSIxMDAiIGhl aWdodD0iMTAwIiBpZD0iX3gwMDAwX2kxMDI3IiBzcmM9ImNpZDp+V1JEMDAwLmpwZyIgYWx0PSLj gqTjg6Hjg7zjgrjjga/lt67lh7rkurrjgavjgojjgaPjgabliYrpmaTjgZXjgozjgb7jgZfjgZ/j gIIiPjwvc3Bhbj48L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0i cGFkZGluZzouNzVwdCAuNzVwdCAuNzVwdCAuNzVwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJhbWUtaHNwYWNlOjIuMjVwdDtt c28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNob3ItdmVydGljYWw6cGFyYWdy YXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVtbjttc28taGVpZ2h0LXJ1bGU6 ZXhhY3RseSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly90d2l0dGVyLmNv bS93b3JsZHNlbnNpbmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iYm9yZGVyOnNvbGlk IHdpbmRvd3RleHQgMS4wcHQ7cGFkZGluZzowbW07dGV4dC1kZWNvcmF0aW9uOm5vbmUiPjxpbWcg Ym9yZGVyPSIwIiB3aWR0aD0iMTAwIiBoZWlnaHQ9IjEwMCIgaWQ9Il94MDAwMF9pMTAyOCIgc3Jj PSJjaWQ6fldSRDAwMC5qcGciIGFsdD0i44Kk44Oh44O844K444Gv5beu5Ye65Lq644Gr44KI44Gj 44Gm5YmK6Zmk44GV44KM44G+44GX44Gf44CCIj48L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVt ZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1l bnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRh bDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPjxh IGhyZWY9Imh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL2NoYW5uZWwvVUNFeEJkM2dPLVpCWnd6NGZx T3JLZ1dBIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImJvcmRlcjpzb2xpZCB3aW5kb3d0 ZXh0IDEuMHB0O3BhZGRpbmc6MG1tO3RleHQtZGVjb3JhdGlvbjpub25lIj48aW1nIGJvcmRlcj0i MCIgd2lkdGg9IjEwMCIgaGVpZ2h0PSIxMDAiIGlkPSJfeDAwMDBfaTEwMjkiIHNyYz0iY2lkOn5X UkQwMDAuanBnIiBhbHQ9IuOCpOODoeODvOOCuOOBr+W3ruWHuuS6uuOBq+OCiOOBo+OBpuWJiumZ pOOBleOCjOOBvuOBl+OBn+OAgiI+PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQg c3R5bGU9InBhZGRpbmc6Ljc1cHQgLjc1cHQgLjc1cHQgLjc1cHQiPg0KPHRhYmxlIGNsYXNzPSJN c29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIxIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAi IHdpZHRoPSIwIiBzdHlsZT0id2lkdGg6NDgzLjBwdDtib3JkZXItdG9wOnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7Ym9yZGVyLWxlZnQ6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 Ym9yZGVyLXJpZ2h0Om5vbmUiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9u ZTtwYWRkaW5nOjcuNXB0IDBtbSA3LjVwdCAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDoxNS4wcHQ7bWFyZ2luLXJpZ2h0OjBtbTttYXJnaW4tYm90 dG9tOjE1LjBwdDttYXJnaW4tbGVmdDowbW07bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQt ZnJhbWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1h bmNob3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNv bHVtbjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDvvLDjgrTj grfjg4Pjgq8mcXVvdDs7Y29sb3I6IzZDN0U4NSI+QkFSQ0VMT05BPC9zcGFuPjwvc3Ryb25nPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiM2QzdFODUiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjE1LjBwdDttYXJnaW4tcmlnaHQ6MG1tO21hcmdpbi1ib3R0b206 MTUuMHB0O21hcmdpbi1sZWZ0OjBtbTttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFt ZS1oc3BhY2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hv ci12ZXJ0aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1u O21zby1oZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjkuMHB0O2NvbG9yOiMyMjc3QkIiPlZpcmlhdCwgNDcsIEVkaWZpY2lvIE51bWFuY2lh IDEsIDEwdGggZmxvb3IsIDA4MDE0IEJhcmNlbG9uYSwgU3BhaW48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3RyPg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6bm9uZTtw YWRkaW5nOjcuNXB0IDBtbSA3LjVwdCAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDoxNS4wcHQ7bWFyZ2luLXJpZ2h0OjBtbTttYXJnaW4tYm90dG9t OjE1LjBwdDttYXJnaW4tbGVmdDowbW07bXNvLWVsZW1lbnQ6ZnJhbWU7bXNvLWVsZW1lbnQtZnJh bWUtaHNwYWNlOjIuMjVwdDttc28tZWxlbWVudC13cmFwOmFyb3VuZDttc28tZWxlbWVudC1hbmNo b3ItdmVydGljYWw6cGFyYWdyYXBoO21zby1lbGVtZW50LWFuY2hvci1ob3Jpem9udGFsOmNvbHVt bjttc28taGVpZ2h0LXJ1bGU6ZXhhY3RseSI+DQo8c3Ryb25nPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O++8re+8syDvvLDjgrTjgrfj g4Pjgq8mcXVvdDs7Y29sb3I6IzZDN0U4NSI+TE9ORE9OPC9zcGFuPjwvc3Ryb25nPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2NvbG9yOiM2QzdFODUiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OjE1LjBwdDttYXJnaW4tcmlnaHQ6MG1tO21hcmdpbi1ib3R0b206MTUuMHB0 O21hcmdpbi1sZWZ0OjBtbTttc28tZWxlbWVudDpmcmFtZTttc28tZWxlbWVudC1mcmFtZS1oc3Bh Y2U6Mi4yNXB0O21zby1lbGVtZW50LXdyYXA6YXJvdW5kO21zby1lbGVtZW50LWFuY2hvci12ZXJ0 aWNhbDpwYXJhZ3JhcGg7bXNvLWVsZW1lbnQtYW5jaG9yLWhvcml6b250YWw6Y29sdW1uO21zby1o ZWlnaHQtcnVsZTpleGFjdGx5Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2NvbG9yOiMyMjc3QkIiPjxhIGhyZWY9Imh0dHBzOi8vbWFwcy5nb29nbGUuY29tLz9x PTktMTAmIzQzO0NhcmxvcyYjNDM7UGxhY2UsJiM0MztNYXlmYWlyJiM0MzstJiM0MztMb25kb24m IzQzO1cxSyZhbXA7ZW50cnk9Z21haWwmYW1wO3NvdXJjZT1nIj45LTEwIENhcmxvcyBQbGFjZSwg TWF5ZmFpciAtIExvbmRvbiBXMUs8L2E+IDNBVCwgVW5pdGVkIEtpbmdkb20gLSAmIzQzOzQ0ICgw KSAyMDMgODA3IDI0OTU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvdGQ+DQo8L3Ry Pg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBzdHlsZT0icGFk ZGluZzozLjc1cHQgMG1tIDMuNzVwdCAwbW0iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToyLjI1cHQ7bXNvLWVs ZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2FsOnBhcmFncmFwaDtt c28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdodC1ydWxlOmV4YWN0 bHkiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Y29sb3I6I0FE QURBRCI+VGhpcyBlbWFpbCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gYW5k IG1heSBiZSBzdWJqZWN0IHRvIHByb2Zlc3Npb25hbCBzZWNyZWN5LiBJdHMgZGlzc2VtaW5hdGlv biwgY29weWluZywgZGlzdHJpYnV0aW9uLCByZXByb2R1Y3Rpb24sIGZvcndhcmRpbmcgb3IgYW55 IG90aGVyIHVuYXV0aG9yaXplZCB1c2UgaXMgc3RyaWN0bHkNCiBwcm9oaWJpdGVkLiBJZiB5b3Ug cmVjZWl2ZSB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHVzIGltbWVkaWF0ZWx5 IGFuZCBhcnJhbmdlIGZvciBpdHMgZGVsZXRpb24sIHRvZ2V0aGVyIHdpdGggYW55IGF0dGFjaGVk IGRvY3VtZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0 ZCBzdHlsZT0icGFkZGluZzozLjc1cHQgMG1tIDMuNzVwdCAwbW0iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1lbGVtZW50OmZyYW1lO21zby1lbGVtZW50LWZyYW1lLWhzcGFjZToy LjI1cHQ7bXNvLWVsZW1lbnQtd3JhcDphcm91bmQ7bXNvLWVsZW1lbnQtYW5jaG9yLXZlcnRpY2Fs OnBhcmFncmFwaDttc28tZWxlbWVudC1hbmNob3ItaG9yaXpvbnRhbDpjb2x1bW47bXNvLWhlaWdo dC1ydWxlOmV4YWN0bHkiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OC41 cHQ7Y29sb3I6I0FEQURBRCI+RXN0ZSBjb3JyZW8gZWxlY3Ryw7NuaWNvIHB1ZWRlIGNvbnRlbmVy IGluZm9ybWFjacOzbiBlc3RyaWN0YW1lbnRlIGNvbmZpZGVuY2lhbCwgeSBwdWVkZSBlc3RhciBz b21ldGlkbyBhbCBzZWNyZXRvIHByb2Zlc2lvbmFsLiBFc3TDoSBwcm9oaWJpZGEgc3UgZGlmdXNp w7NuLCBjb3BpYSwgZGlzdHJpYnVjacOzbiwgcmVwcm9kdWNjacOzbiwgcmVlbnbDrW8gbyBjdWFs cXVpZXINCiBvdHJvIHVzbyBubyBhdXRvcml6YWRvLiBFbiBjYXNvIGRlIHJlY2liaXIgZXN0ZSBj b3JyZW8gcG9yIGVycm9yLCByb2dhbW9zIG5vcyBsbyBjb211bmlxdWUgZGUgaW5tZWRpYXRvIHkg cHJvY2VkYSBhIHN1IGVsaW1pbmFjacOzbiwgYXPDrSBjb21vIGRlIGN1YWxxdWllciBkb2N1bWVu dG8gcXVlIHNlIGFkanVudGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8 L3Rib2R5Pg0KPC90YWJsZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KPGJyPg0KLS0gPG86cD48L286 cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5ESUVHTyBEVUpPVk5FPGJyPg0KUHJvZmVzb3IgQXNv Y2lhZG88YnI+DQpFc2N1ZWxhIGRlIEluZm9ybcOhdGljYSB5IFRlbGVjb211bmljYWNpb25lczxi cj4NCkZhY3VsdGFkIGRlIEluZ2VuaWVyw61hIC0gVW5pdmVyc2lkYWQgRGllZ28gUG9ydGFsZXMg LSBDaGlsZTxicj4NCjxhIGhyZWY9Imh0dHA6Ly93d3cuaW5nZW5pZXJpYS51ZHAuY2wiIHRhcmdl dD0iX2JsYW5rIj53d3cuaW5nZW5pZXJpYS51ZHAuY2w8L2E+PGJyPg0KKDU2IDIpIDY3NiA4MTI1 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_-- --_005_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_ Content-Type: image/jpeg; name="~WRD000.jpg" Content-Description: ~WRD000.jpg Content-Disposition: inline; filename="~WRD000.jpg"; size=823; creation-date="Thu, 15 Feb 2018 04:31:59 GMT"; modification-date="Thu, 15 Feb 2018 04:32:45 GMT" Content-ID: <~WRD000.jpg> Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABkAGQDASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD3+iii gAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKA CiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAK KKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAoo ooAKKKKACiiigAooooAKKKKACiiigD//2Q== --_005_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=12620; creation-date="Thu, 15 Feb 2018 04:34:31 GMT"; modification-date="Thu, 15 Feb 2018 04:34:31 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/2wBDAAoHBwkHBgoJCAkLCwoMDxkQDw4ODx4WFxIZJCAmJSMg IyIoLTkwKCo2KyIjMkQyNjs9QEBAJjBGS0U+Sjk/QD3/wAALCAQABAABAREA/8QAHwAAAQUBAQEB AQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1Fh ByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZ WmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXG x8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/9oACAEBAAA/APZqKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKK KKKKKKKKKKKKKKKKKKKKKKKKKKK//9k= --_005_OSBPR01MB17662BF3AF0EBF974259EE3E90F40OSBPR01MB1766jpnp_-- From nobody Thu Feb 15 05:21:20 2018 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 9707012D879 for ; Wed, 14 Feb 2018 20:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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_NONE=-0.0001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=worldsensing.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 eFPVanr6zKST for ; Wed, 14 Feb 2018 20:27:32 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 9344612D7E9 for ; Wed, 14 Feb 2018 20:27:31 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id s5so2035898wra.0 for ; Wed, 14 Feb 2018 20:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=worldsensing.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dX2Lvml1YzTc408n3NWi1XvUANSHb4kkQcKTS5vGsK4=; b=Jy4c7a9rwwhfrN62M12aqwwTo6/cLYa0EHjlgtGjKdWsnVbp3kmEq0Lgbsx80g8uR2 mxCEdSTj5fXf3exw0dqv1spww1/DIoDhdqZtVnH8wIbZyxlvp6wq82m40tVF9JFapVo+ 94qGQjCls0q61jUE3DNF3mUDjEaFXI0yvkfoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dX2Lvml1YzTc408n3NWi1XvUANSHb4kkQcKTS5vGsK4=; b=tS9sZV30REHuqbl7AZIYfj1a3gVOMT9kAh2NrlFNuUcw4xA/MREayF5P0N57BH1gxi p1M9DLkCEtF9pLJzMOXtqS8kmKi6U05MKBw1DC6ekb8ZCz22C3N7OPMmFnfBARV1sQ2O DoX5L2xioqDzE/Hg5ki7XbXh56lDc+px96gwkFcNSG4pMpwJNjqGUwGcCxgpgLEFi7pO EMz5Mw1ecpgsaNKR8H9BnTugaVsJapqNLt+WAM8Vf9Lao0BngbxkbQhpbl6EZ9YoVJ/3 VXWf1AMhhaoUYk9oAsAZuq7G9RO0+q0bEwQ3jagQn5YoOtFoG4NR127xhLZim6Hf/bmz q5vw== X-Gm-Message-State: APf1xPDVdoEHAIgp+0+a7TGLJNKmmUFEOJfBHb5aV2XdhTsn7LXDQsnQ 9ZD9e5bVA4R2UDrtpB0qrkgrCfcRDr9kXbOJ5uvVQLEHEaLnVE5uRaj5lPQVgrTnkfGvxsIbQzY xbp1NJyLrlMZcIL0= X-Google-Smtp-Source: AH8x2263YwU9Ya62f6+PfZ4kpblsqBThCQRGIThyk5JibTzn6a3JZ16Rwe2G3YHWAxCYJRl+rMngmLUupD25tudBpnc= X-Received: by 10.223.151.101 with SMTP id r92mr1170217wrb.120.1518668849865; Wed, 14 Feb 2018 20:27:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.192.5 with HTTP; Wed, 14 Feb 2018 20:27:29 -0800 (PST) In-Reply-To: References: From: Xavier Vilajosana Date: Thu, 15 Feb 2018 05:27:29 +0100 Message-ID: To: "Grossman, Ethan A." Cc: Lou Berger , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" , DetNet Chairs , DetNet WG Content-Type: multipart/alternative; boundary="f403045d5cf253fa15056538a53b" Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 05:21:18 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 04:27:36 -0000 --f403045d5cf253fa15056538a53b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No, I'm not aware of any IPR that applies to this draft thanks for handling this. regards X *Xavier Vilajosana* *CIO* Office: <+34%20934%2018%2005%2085>[ <+34%20934%2018%2005%2085>+34] 93 418 0585 <+34%20934%2018%2005%2085> Cell: <+34%20934%2018%2005%2085>[ <+34%20934%2018%2005%2085>+34] 646 633 68= 1 <+34%20934%2018%2005%2085> xvilajosana@worldsensing.com 2018-02-14 19:53 GMT+01:00 Grossman, Ethan A. : > No, I'm not aware of any IPR that applies to this draft > Ethan. > > -----Original Message----- > From: Lou Berger [mailto:lberger@labn.net] > Sent: Wednesday, February 14, 2018 10:28 AM > To: Grossman, Ethan A. ; craig.gunther@harman.com; > pthubert@cisco.com; pwetterw@cisco.com; raymond.jean@hydro.qc.ca; > jouni.nospam@gmail.com; yu1.kaneko@toshiba.co.jp; sdas@appcomsci.com; > zhayiyong@huawei.com; balazs.a.varga@ericsson.com; > janos.farkas@ericsson.com; franz-josef.goetz@siemens.com; > juergen.jues.schmitt@siemens.com; xvilajosana@worldsensing.com; > toktam.mahmoodi@kcl.ac.uk; spis@intracom-telecom.com; > petra.vizarreta@lkn.ei.tum.de; huang.guangping@zte.com.cn; > gengxuesong@huawei.com; diego.dujovne@mail.udp.cl; maseewal@cisco.com > Cc: DetNet Chairs ; DetNet WG > Subject: Regarding IPR on draft-ietf-detnet-use-cases-13 > > > > Authors, Contributors, WG, > > As part of the preparation for WG LC: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see > RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next sta= ge > until a response has been received from each author and listed contributo= r. > NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under the > IETF IPR rules which encourages you to notify the IETF if you are aware o= f > IPR of others on an IETF contribution, or to refrain from participating i= n > any contribution or discussion related to your undisclosed IPR. For more > information, please see the RFCs listed above and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > DetNet WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > --=20 =20 =20 =20 *BARCELONA* Viriat, 47, Edificio Numancia 1, 10th floor, 08014 Barcelona, Spain *LONDON* 9-10 Carlos Place, Mayfair - London W1K 3AT, United Kingdom - +44 (0) 203= =20 807 2495 This email may contain confidential information and may be subject to=20 professional secrecy. Its dissemination, copying, distribution,=20 reproduction, forwarding or any other unauthorized use is strictly=20 prohibited. If you receive this email in error, please notify us=20 immediately and arrange for its deletion, together with any attached=20 documents. Este correo electr=C3=B3nico puede contener informaci=C3=B3n estrictamente= =20 confidencial, y puede estar sometido al secreto profesional. Est=C3=A1 proh= ibida=20 su difusi=C3=B3n, copia, distribuci=C3=B3n, reproducci=C3=B3n, reenv=C3=ADo= o cualquier otro=20 uso no autorizado. En caso de recibir este correo por error, rogamos nos lo= =20 comunique de inmediato y proceda a su eliminaci=C3=B3n, as=C3=AD como de cu= alquier=20 documento que se adjunte. --f403045d5cf253fa15056538a53b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
No, I'm not aware of any IPR that applies to= this draft

thanks for handling this.

= regards
X


2018-02-14 19:53 GMT+01:00 Grossman, Ethan A= . <eagros@dolby.com>:
No, I'm not aware of any IPR that applies to this draft
Ethan.

-----Original Message-----
From: Lou Berger [mailto:lberger@labn.n= et]
Sent: Wednesday, February 14, 2018 10:28 AM
To: Grossman, Ethan A. <eagros@dolby= .com>; craig.gunther@har= man.com; pthubert@cisco.com; = pwetterw@cisco.com; raymond.jean@hydro.qc.ca; jouni.nospam@gmail.com; yu1.kaneko@toshiba.co.jp; sdas@appcomsci.com; zhayiyong@huawei.com; balazs.a.varga@ericsson.com; janos.farkas@ericsson.com; franz-josef.goetz@siemens.com; juergen.jues.schmitt@siemens.com; xvilajosana@worldsensing.com; = toktam.mahmoodi@kcl.ac.uk;= spis@intracom-telecom.com= ; petra.vizarreta@lkn.ei.t= um.de; huang.guangping@zt= e.com.cn; gengxuesong@huawei.= com; diego.dujovne@mail.ud= p.cl; maseewal@cisco.com
Cc: DetNet Chairs <detnet-chai= rs@ietf.org>; DetNet WG <detne= t@ietf.org>
Subject: Regarding IPR on draft-ietf-detnet-use-cases-13



Authors, Contributors, WG,

As part of the preparation for WG LC:

Are you aware of any IPR that applies to drafts identified above?

Please state either:

"No, I'm not aware of any IPR that applies to this draft"
or
"Yes, I'm aware of IPR that applies to this draft"

If so, has this IPR been disclosed in compliance with IETF IPR rules (see R= FCs 3669, 5378 and 8179 for more details)?

If yes to the above, please state either:

"Yes, the IPR has been disclosed in compliance with IETF IPR rules&quo= t;
or
"No, the IPR has not been disclosed"

If you answer no, please provide any additional details you think appropria= te.

If you are listed as a document author or contributor please answer the abo= ve by responding to this email regardless of whether or not you are aware o= f any relevant IPR. This document will not advance to the next stage until = a response has been received from each author and listed contributor. NOTE:= THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S TO LINES.

If you are on the WG email list or attend WG meetings but are not listed as= an author or contributor, we remind you of your obligations under the IETF= IPR rules which encourages you to notify the IETF if you are aware of IPR = of others on an IETF contribution, or to refrain from participating in any = contribution or discussion related to your undisclosed IPR. For more inform= ation, please see the RFCs listed above and http://trac.tools.ietf.org/group/iesg/trac/wiki/Intel= lectualProperty.

Thank you,
DetNet WG Chairs

PS Please include all listed in the headers of this message in your respons= e.




<= /a>=
=
BARCELONA
Viriat, 47, Edificio Numancia 1, 10th floor, 08014 Barcelona, Spain
= LONDON
9-10 Carlos Place, Mayf= air - London W1K 3AT, United Kingdom - +44 (0) 203 807 2495
This email may contain confidential information and = may be subject to professional secrecy. Its dissemination, copying, distrib= ution, reproduction, forwarding or any other unauthorized use is strictly p= rohibited. If you receive this email in error, please notify us immediately= and arrange for its deletion, together with any attached documents.
= Este correo electr=C3=B3nico puede contener informaci=C3=B3n estrictamente = confidencial, y puede estar sometido al secreto profesional. Est=C3=A1 proh= ibida su difusi=C3=B3n, copia, distribuci=C3=B3n, reproducci=C3=B3n, reenv= =C3=ADo o cualquier otro uso no autorizado. En caso de recibir este correo = por error, rogamos nos lo comunique de inmediato y proceda a su eliminaci= =C3=B3n, as=C3=AD como de cualquier documento que se adjunte.
--f403045d5cf253fa15056538a53b-- From nobody Thu Feb 15 06:25:13 2018 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 9BD161241F5 for ; Thu, 15 Feb 2018 06:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 jH77L5tj-vSO for ; Thu, 15 Feb 2018 06:25:11 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 9DBAE120454 for ; Thu, 15 Feb 2018 06:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518704708; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=M0x+7Wa2i4vZH7PDREPIdEo9tOrW5jpYQheBnKJ2HQk=; b=SD3plZCjhkoAdDuPaUSTivckL6xZ2Usp7JZW0vI5IT6C7MR8x9ica0bCT4menRh8 YxwswYCzLKtOoVimO5vluvAYNLXNghf5L7jakhHZxFBecB+5gi5tkopEGnUiQg6q kf2L7XDlUDeUuFxdXKeT+ckM7AAwfpGEcqhRFxrzEqk=; X-AuditID: c1b4fb30-799639c000004778-6f-5a859844c249 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 86.DA.18296.448958A5; Thu, 15 Feb 2018 15:25:08 +0100 (CET) Received: from [159.107.197.203] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.65) with Microsoft SMTP Server id 14.3.352.0; Thu, 15 Feb 2018 15:25:08 +0100 To: References: From: =?UTF-8?Q?J=c3=a1nos_Farkas?= Message-ID: <078adf31-746e-266e-8e7a-c0c304be3bfd@ericsson.com> Date: Thu, 15 Feb 2018 15:25:07 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprHLMWRmVeSWpSXmKPExsUyM2K7va7LjNYog0PPrC1+f5rN4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujEVt21kL1vBVHNq+lamBcS53FyMnh4SAicT+0/+Yuhi5OIQE DjNKfJj/lBnCWcso0bt/FTtIlbCAjcSOP+fBbBEBUYkTUzrBbCEBa4mWF+uZQWw2AXuJu5c2 gNm8QPbbPe0sIDaLgKrEpNfP2LoYOThEBWIk1vclQJQISpyc+QSshBNofOuE60wgNrOAhcTM +ecZIWx5ie1v5zBDrFKT+PT2IfsERv5ZSNpnIWmZhaRlASPzKkbR4tTipNx0IyO91KLM5OLi /Dy9vNSSTYzAUDu45bfBDsaXzx0PMQpwMCrx8MZmtkYJsSaWFVfmHmKU4GBWEuH9GAUU4k1J rKxKLcqPLyrNSS0+xCjNwaIkznvSkzdKSCA9sSQ1OzW1ILUIJsvEwSnVwKj32M/smFet8y2B AMbTk1/nedg6t9QKTZW6pct2e9fsFvvgg08m3bR+aWwrwKb3QKhtkfMVkSU6lkv3lTWmnPbp 2shZ+cnU+OIjOfcb0T5x8X2qr7gmlcoWiDsriTr29QT/efZxzW3BJ4ES79sdmGX7/hxulbEy 53Nq8Thyvsq7Z6aZBWOZEktxRqKhFnNRcSIA4A6bIDECAAA= Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 14:25:13 -0000 No, I'm not aware of any IPR that applies to this draft. Regards, Janos On 2/14/2018 7:28 PM, Lou Berger wrote: > > > Authors, Contributors, WG, > > As part of the preparation for WG LC: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > DetNet WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > From nobody Thu Feb 15 08:35:38 2018 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 3D66112D949 for ; Thu, 15 Feb 2018 08:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=T9GV3eA9; dkim=pass (1024-bit key) header.d=ericsson.com header.b=CGwwFwvz 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 OMNddqPDeR1S for ; Thu, 15 Feb 2018 08:35:33 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 462F512DA6B for ; Thu, 15 Feb 2018 08:35:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518712531; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5C917Dl1bKBHeWH6S//ouFkhXpA1dyYuC/KOe9xfZPs=; b=T9GV3eA9aaqPNtmEGMGCU6RKqH5MG0BjU3YQSnwSqF98zA8u4k0BdHok2hz8paeg G0jm7vKbtbOI2nFqFar6PUw3g14bBkrtCuxWSaO6t8uM8wH07eX8wV0jffMFCQ2Z IF3iVWEdYVITmnMAt1ODNR42OX10CrFtH2JBCJcAhzs=; X-AuditID: c1b4fb2d-499ff70000005540-b4-5a85b6d35392 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id CA.34.21824.3D6B58A5; Thu, 15 Feb 2018 17:35:31 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 15 Feb 2018 17:35:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5C917Dl1bKBHeWH6S//ouFkhXpA1dyYuC/KOe9xfZPs=; b=CGwwFwvzb4SmUMFJMdCKdWfgWQva1apXIOLTHcDa72Nwzb/zM3nCFGkZwlxHW+hAiDKqDqkq5n6Le8a0ymxrYhUQBEXbiMHNVT1Q5R5cIlKSMH8nYJ2YNmZajKvnuUrdvI2xY26dgMIYgcVmoqt28VdMFrav2P0mFQw2WCXvp8A= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1SPR8PMB101.eurprd07.prod.outlook.com (10.163.248.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.527.6; Thu, 15 Feb 2018 16:35:29 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd%17]) with mapi id 15.20.0506.020; Thu, 15 Feb 2018 16:35:29 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGosf+NzXBYRkW5HDAOEcVq0qOlp5rAgAACuQA= Date: Thu, 15 Feb 2018 16:35:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [94.21.187.181] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB101; 7:/UwH0w/k1uspLfXE5yamOoaj1oslbUvVgF9aIk7GLu72+bDo5SdEtdA2BRdkInbc576AIz6jMpKViXFCiu8FSTl8U5OrNLCC1VMoPHP9ZsAu7TXtqS0wFJtkJZ4NISlZlGzjkhTnIydFK+8DiHREZ9uCkZojJ5NuFmOmp18xKIAqGFgeSc9pBzWSFvBuwmvEBWCtYU2Vm4vPe9lRCw1pMv0DVVgPOsUz8EKqIoGoGhzmvzSKqKSbIwI1cy4V5HsA x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ac2de7a2-d064-4620-ef69-08d574921ffb x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1SPR8PMB101; x-ms-traffictypediagnostic: VI1SPR8PMB101: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(41521381080715)(50582790962513)(85827821059158)(95692535739014)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(944501161)(10201501046)(3002001)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:VI1SPR8PMB101; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB101; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(346002)(396003)(39380400002)(199004)(189003)(13464003)(2900100001)(53936002)(81166006)(68736007)(106356001)(6306002)(85202003)(6506007)(81156014)(53546011)(102836004)(55016002)(9686003)(33656002)(7736002)(305945005)(8676002)(316002)(3660700001)(86362001)(99286004)(6246003)(25786009)(26005)(186003)(2906002)(6436002)(85182001)(97736004)(3280700002)(8936002)(76176011)(14454004)(3846002)(6116002)(229853002)(5250100002)(2940100002)(5660300001)(2950100002)(6916009)(105586002)(478600001)(966005)(74316002)(66066001)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1SPR8PMB101; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: d+zvSh3CJAdKVi1TDKHqb6+6Dzn3hIpoKTy03YKx8cpTIWafJ/5iSfcdLsS6TRWt8n7/T2Ci+IfiVEgzqraJhQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ac2de7a2-d064-4620-ef69-08d574921ffb X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 16:35:29.2507 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB101 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe9733fa6HDxNzdNSwlVgS2cXIQuNQqEMuiB9qGG6kW/TptP2 rpF9mpGJLm+pecnSZBAktlqWUl5wMlS6iaFIILEpqQwxZ0TihbY9Bn37/f//wznPOTwsLV1n ZGyO3sgZ9JpcuVDMNF7q2hP79W2x6oDZHpmw6n3EnECnrdYV6gJSiROzuNwcE2eIO64WZzsb +oQFv2W3XvfVMWbULCtDQSzgeJhpfITKkJiV4kEEH6fuCIkYRlCz0kf7BYO9FLyfX6RJUk3B xE8rRYQLQa+7VuhvJsQp0G1vFvg5FO+CovJlkZ9DcCJU/mmjiZ8EvbYXiPAx6Givp/zM4L1g 8XoCfSQ4HYpGSxkyoALB0oPxQBCEr4C55J6PWRbhSHB1JPhtGofDt5kWiiyEwdrzhSYcBvPT G4H3IJwBq/3mTT8KambXRIQjYazFEjgA4E4KXK1TQhIo4U31AiJ8FmyvHopIke8wgxXezSIF lFWZBYR1sGExU6TIgmBtbowmopIGz3T55rwIcH/uZQi7BdBgz6tCyqb/1mjybUfjfWB7F0fs KKi1uERNgctsg5HGGaYVMc9RGM/xfJ720GElZ8i5yvP5eqWeM9qR71MMdK7GdqN2z0kHwiyS B0sUOcUqqUBj4gvzHAhYWh4qWVL5LEmWpvA2Z8jPNNzM5XgH2sky8nDJSKpEJcVajZHTcVwB Z/iXUmyQzIy21PfM1SWvx2SbamEi5sbWVk0SrU3W6U8NpaQMd3Q90zXQ5zI8L2OeqmuMGZZS bjJNnR9BhTweTTZe3zH2/Wjzr/px5+5r6Ze1DhwsLrn4I/OISJEaOkRF95+PL690aj7E27bf XdjPr7Q5l3sWJ6PPtN8f0KXNprqffJpVmyRyhs/WHFTQBl7zF1+cmIYQAwAA Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 16:35:36 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N CkNoZWVycyBCYWxhJ3pzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiAyMDE4LiBmZWJydcOhciAx NC4gMTk6MjgNClRvOiBldGhhbi5ncm9zc21hbkBkb2xieS5jb207IGNyYWlnLmd1bnRoZXJAaGFy bWFuLmNvbTsgcHRodWJlcnRAY2lzY28uY29tOyBwd2V0dGVyd0BjaXNjby5jb207IHJheW1vbmQu amVhbkBoeWRyby5xYy5jYTsgam91bmkubm9zcGFtQGdtYWlsLmNvbTsgeXUxLmthbmVrb0B0b3No aWJhLmNvLmpwOyBzZGFzQGFwcGNvbXNjaS5jb207IHpoYXlpeW9uZ0BodWF3ZWkuY29tOyBCYWzD oXpzIFZhcmdhIEEgPGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbT47IEphbm9zIEZhcmthcyA8 SmFub3MuRmFya2FzQGVyaWNzc29uLmNvbT47IGZyYW56LWpvc2VmLmdvZXR6QHNpZW1lbnMuY29t OyBqdWVyZ2VuLmp1ZXMuc2NobWl0dEBzaWVtZW5zLmNvbTsgeHZpbGFqb3NhbmFAd29ybGRzZW5z aW5nLmNvbTsgdG9rdGFtLm1haG1vb2RpQGtjbC5hYy51azsgc3Bpc0BpbnRyYWNvbS10ZWxlY29t LmNvbTsgcGV0cmEudml6YXJyZXRhQGxrbi5laS50dW0uZGU7IGh1YW5nLmd1YW5ncGluZ0B6dGUu Y29tLmNuOyBnZW5neHVlc29uZ0BodWF3ZWkuY29tOyBkaWVnby5kdWpvdm5lQG1haWwudWRwLmNs OyBtYXNlZXdhbEBjaXNjby5jb20NCkNjOiBEZXROZXQgQ2hhaXJzIDxkZXRuZXQtY2hhaXJzQGll dGYub3JnPjsgRGV0TmV0IFdHIDxkZXRuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZWdhcmRpbmcg SVBSIG9uIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMw0KDQoNCg0KQXV0aG9ycywgQ29u dHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExDOg0K DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlm aWVkIGFib3ZlPw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBub3QgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdh cmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRv IHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMgYmVl biBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJObywg dGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVh c2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4N Cg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3Ig cGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2Fy ZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS LiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwg YSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQg Y29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBU SElTIE1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlz dCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv ciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRo ZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYg aWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9u LCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9y IGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5m b3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0 eS4NCg0KVGhhbmsgeW91LA0KRGV0TmV0IFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBh bGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNl Lg0KDQoNCg== From nobody Thu Feb 15 08:39:47 2018 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 50C74124D37; Thu, 15 Feb 2018 06:28:54 -0800 (PST) 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, 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, URIBL_BLOCKED=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 YkcbCbNyCBKU; Thu, 15 Feb 2018 06:28:52 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468001241F5; Thu, 15 Feb 2018 06:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1826; q=dns/txt; s=iport; t=1518704932; x=1519914532; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Rq2HXdeio1kIPmpPMoyv42SSaG9M/hprhZWCjrIwk2o=; b=TbXLwpcRPZH4owwAkBctl8CdALSQB/LlKcBM4s2yjeZlNv9eptXVh2y3 UpY1vRdpXjo5VuuzXQ2ql0d6i5CjGR+ZsVwwEIsWLE2kn1ePE0ayCl5lr 4QMhmjFvlA6o93OdxJ69eBMB6073m3saIEDwBzKQO0C3BaxsggOOdy30p k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQANmIVa/4YNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDUmZwKAqOAI4EgxmWRRWCAwojhRgCgkJUGAECAQEBAQEBAms?= =?us-ascii?q?ohSQGdAUQAgEIDjgyJQIEAQ0FijUQsFWEFwEBhGWCEwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2FA4IngVeBaIMugyQLAoE+ARIBhhsFkxyRFgkCiB6NZYIfZ4VDi32?= =?us-ascii?q?OBYlqAhEZAYE7AR85YHFwFT2CRgmELwQBOngBi36BJYEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208";a="71241070" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 14:28:51 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1FESpsC018462 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 14:28:51 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 09:28:50 -0500 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 09:28:50 -0500 From: "Maik Seewald (maseewal)" To: Lou Berger , "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "Pascal Thubert (pthubert)" , "Patrick Wetterwald (pwetterw)" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpmlMWb7nuKri/USA4ztsejekbA== Date: Thu, 15 Feb 2018 14:28:50 +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.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.162.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:43 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 14:28:54 -0000 "No, I'm not aware of any IPR that applies to this draft=B2 Maik Seewald On 14.02.18, 19:28, "Lou Berger" wrote: > > >Authors, Contributors, WG, > >As part of the preparation for WG LC: > >Are you aware of any IPR that applies to drafts identified above? > >Please state either: > >"No, I'm not aware of any IPR that applies to this draft" >or >"Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3669, 5378 and 8179 for more details)? > >If yes to the above, please state either: > >"Yes, the IPR has been disclosed in compliance with IETF IPR rules" >or >"No, the IPR has not been disclosed" > >If you answer no, please provide any additional details you think >appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S >TO LINES. > >If you are on the WG email list or attend WG meetings but are not listed >as an author or contributor, we remind you of your obligations under >the IETF IPR rules which encourages you to notify the IETF if you are >aware of IPR of others on an IETF contribution, or to refrain from >participating in any contribution or discussion related to your >undisclosed IPR. For more information, please see the RFCs listed above >and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >DetNet WG Chairs > >PS Please include all listed in the headers of this message in your >response. > > From nobody Thu Feb 15 08:39:56 2018 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 A76B81205D3; Thu, 15 Feb 2018 07:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_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 RKzDutx3Va41; Thu, 15 Feb 2018 07:11:37 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (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 05BC51204DA; Thu, 15 Feb 2018 07:11:37 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id 37so15626959lfs.7; Thu, 15 Feb 2018 07:11:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:content-language :thread-index; bh=nyGMtPDK0tAr2ZiU89aihcwUDZQRCi4oXbbeJGYUEMI=; b=JNds+nHUXKmDR1WymgJk03Klpl9J5V8pe/10797phKm9GizD/tqGQG6cbU8Be/zyZf 5wgaQFLpEJ5bu81Dy6Dy+WMJ1wGl4YCkC1pl0cFPaD7zI4XjdXuVFAI/DQ6KfT3ExSj0 e7l2Pgq48jCfSleUJFZStWnNpUYgyQK764CHOOhyQBpQuM85Eby00ih8bESoyHXVAm1U vsOShm5RAYa07AMskFePQx2JX+ZynUjYKZYG/du2x8F4iQm+BPqoeMcAjfDsvp+G7Bv8 hUc5ChPlUPEhWMQHEPHSiFGyKWEtdCQEjqqwgNVNaeYekpiK7cxHAch39jD9sOE4f6ai UmOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:content-language :thread-index; bh=nyGMtPDK0tAr2ZiU89aihcwUDZQRCi4oXbbeJGYUEMI=; b=Xy9YM6VQ0vJj8GxIm4Nra1PQ/HI0RwpMdZFlWWjicgEimYH2Rp0x6fMOGm8Y+G24uA NdRjepizswP6WUbZJyNYExxnxiF2MKC4Im21gsFCKzpxfpFBv/Ag2DXjPsqieM9g+1mg 5obsLUUMt4jlIvCB0AKA6miOU8AH/kAPwRCGDgdLKPOcVMD1frrlxMiQnClb6kF0FtRb /eVLcBTTbEHY00PwgR6d73a13i31DAaaO45Xj8RYineQXq8EfXDLz/6f03i17gRj+gjv lZTD/HyX+BhaaClCyh7TChB45GuKHT2tN9Ufc2T5x6RMLPRQdIFBtWR5sE5FYTG1i7Mj oadw== X-Gm-Message-State: APf1xPDjjx4VG6Y9hp+TSg/J0RDNmt6yRW+lUKKZPUXGbfg7h5O72ILq OBPTIV56xob91oEGvuNusDY= X-Google-Smtp-Source: AH8x224K1kNVxbElWAkGcfSAbdaLa4Zfb9sGD3fTfHRofyEBicwDJCSmeDzxE4KK2OqUWs52obw6Hg== X-Received: by 10.25.193.7 with SMTP id r7mr2166149lff.37.1518707495264; Thu, 15 Feb 2018 07:11:35 -0800 (PST) Received: from JOKO ([83.145.195.18]) by smtp.gmail.com with ESMTPSA id u129sm1125863lff.73.2018.02.15.07.11.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 07:11:34 -0800 (PST) From: "Jouni" To: "'Lou Berger'" , , , , , , , , , , , , , , , , , , , , Cc: "'DetNet Chairs'" , "'DetNet WG'" References: In-Reply-To: Date: Thu, 15 Feb 2018 17:11:31 +0200 Message-ID: <08c201d3a66f$450b8580$cf229080$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQDUe1yxBJpbFVsuxJcTGlkJW4zwAaWjbutw Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:41 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 15:11:39 -0000 "No, I'm not aware of any IPR that applies to this draft" From nobody Thu Feb 15 08:40:06 2018 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 15DAD127863; Thu, 15 Feb 2018 07:29:50 -0800 (PST) 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, 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, URIBL_BLOCKED=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 kV6wDjrpdIGf; Thu, 15 Feb 2018 07:29:48 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EA5C124E15; Thu, 15 Feb 2018 07:29:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1814; q=dns/txt; s=iport; t=1518708588; x=1519918188; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cYUpxTucfNm5Li8UXtXAVyqNjQyAHmb5NF3N6GxpTzc=; b=C8boOWbAhMRB55CXLG/dzIKrGmO2F63VDbM46CvFXFtyIT4fc9jUckGp rixujPhNeRB6+IyMSKH54Rva4zlm+Hsgv3hWSuszA0Y7ip1z5L6jlBNo4 bA5SY0bGEqONlA0EzpAVmlg0esD7TxquouNmAAO+SLhSJWmhZsmkMxIRO 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQB7poVa/4MNJK1dDgsBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGDUmZwKAqOAI4EgxmWRRWCAwojhRgCgkJUGAECAQEBAQEBAms?= =?us-ascii?q?ohSQGOjoFEAIBCA4oEDIlAgQBDQWKNRCwY4QXAQGEY4ITAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBHYUDgieBV4Fogy6DJAsCgT4BEgGGGwWkMgkCiB6NZYIfZ4VDi32?= =?us-ascii?q?OBYlqAhEZAYE7AR85YHFwFT2CRgmELwQBOngBi36BJYEZAQEB?= X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208";a="71408094" Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 15:29:47 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1FFTlpw028103 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 15 Feb 2018 15:29:47 GMT Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 15 Feb 2018 10:29:46 -0500 Received: from xch-rtp-002.cisco.com ([64.101.220.142]) by XCH-RTP-002.cisco.com ([64.101.220.142]) with mapi id 15.00.1320.000; Thu, 15 Feb 2018 10:29:46 -0500 From: "Maik Seewald (maseewal)" To: Lou Berger , "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "Pascal Thubert (pthubert)" , "Patrick Wetterwald (pwetterw)" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpnHPWb7nuKri/USA4ztsejekbA== Date: Thu, 15 Feb 2018 15:29:46 +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.5.6.150930 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.60.162.73] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:43 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 15:29:50 -0000 No, I'm not aware of any IPR that applies to this draft Maik On 14.02.18, 19:28, "Lou Berger" wrote: > > >Authors, Contributors, WG, > >As part of the preparation for WG LC: > >Are you aware of any IPR that applies to drafts identified above? > >Please state either: > >"No, I'm not aware of any IPR that applies to this draft" >or >"Yes, I'm aware of IPR that applies to this draft" > >If so, has this IPR been disclosed in compliance with IETF IPR rules >(see RFCs 3669, 5378 and 8179 for more details)? > >If yes to the above, please state either: > >"Yes, the IPR has been disclosed in compliance with IETF IPR rules" >or >"No, the IPR has not been disclosed" > >If you answer no, please provide any additional details you think >appropriate. > >If you are listed as a document author or contributor please answer the >above by responding to this email regardless of whether or not you are >aware of any relevant IPR. This document will not advance to the next >stage until a response has been received from each author and listed >contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S >TO LINES. > >If you are on the WG email list or attend WG meetings but are not listed >as an author or contributor, we remind you of your obligations under >the IETF IPR rules which encourages you to notify the IETF if you are >aware of IPR of others on an IETF contribution, or to refrain from >participating in any contribution or discussion related to your >undisclosed IPR. For more information, please see the RFCs listed above >and >http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > >Thank you, >DetNet WG Chairs > >PS Please include all listed in the headers of this message in your >response. > > From nobody Thu Feb 15 08:40:13 2018 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 928E2127978; Thu, 15 Feb 2018 07:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=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 IbziZSuaqpKt; Thu, 15 Feb 2018 07:46:34 -0800 (PST) Received: from thumper.appcomsci.com (thumper.appcomsci.com [205.132.0.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 983A6126BF6; Thu, 15 Feb 2018 07:46:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id 45EA7646B52; Thu, 15 Feb 2018 10:41:39 -0500 (EST) X-Virus-Scanned: by SpamTitan at appcomsci.com Received: from thumper.appcomsci.com (localhost [127.0.0.1]) by thumper.appcomsci.com (Postfix) with ESMTP id ABCEA646B00; Thu, 15 Feb 2018 10:41:38 -0500 (EST) Received: from bambi.appcomsci.com (bambi.appcomsci.com [192.4.5.54]) by thumper.appcomsci.com (Postfix) with ESMTPS id 6C6A8646B37; Thu, 15 Feb 2018 10:41:38 -0500 (EST) Received: from brg-exmb1.ats.atsinnovate.com (exch.appcomsci.com [192.4.5.112]) by bambi.appcomsci.com (8.14.4/8.13.4) with ESMTP id w1FFkQhc014107; Thu, 15 Feb 2018 10:46:26 -0500 Received: from RRC-ATS-EXMB2.ats.atsinnovate.com ([2002:c004:56a::c004:56a]) by brg-ats-exhb1.ats.atsinnovate.com ([fe80::fc05:b53:7f2b:84f9%18]) with mapi id 14.03.0361.001; Thu, 15 Feb 2018 10:48:42 -0500 From: "Das, Subir" To: Lou Berger CC: "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" , DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcTLUk6sE+ZMFEqhFs7GkV/22KOlnV5v Date: Thu, 15 Feb 2018 15:46:25 +0000 Message-ID: <196A473F-801A-43C4-9C28-6007FD5CE0CC@appcomsci.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:42 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 15:46:37 -0000 No, I'm not aware of any IPR that applies to this draft.=20 Sent from my iPhone > On Feb 15, 2018, at 12:21 AM, Lou Berger wrote: >=20 > No, I'm not aware of any IPR that applies to this draft" From nobody Thu Feb 15 08:40:23 2018 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 16D63126BF6; Thu, 15 Feb 2018 07:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 HqwiqQ3sjAcO; Thu, 15 Feb 2018 07:57:22 -0800 (PST) Received: from mail-pg0-x230.google.com (mail-pg0-x230.google.com [IPv6:2607:f8b0:400e:c05::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 6A4B7126BF0; Thu, 15 Feb 2018 07:57:22 -0800 (PST) Received: by mail-pg0-x230.google.com with SMTP id j9so78300pgv.3; Thu, 15 Feb 2018 07:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJ8h5J/GzsFizFDzykuEv2VoRngJY+1FNO61J4rm+UQ=; b=bzctDYA9J5f/hDhCcHO3oG2Fu2b95XpvF5fmj7lBcNIr74Wn1t2iICeW4/NwH9oSw4 mBgqfGK3xx7sFIBHqictVB+eTeCS9KP26YC9Cm8qg95jUAlwajQ/PBybZhAqqNYWLqlM DGiS++LOAZusAae4SFVPp7g0Yr9M+HIjGdzHq9aCbTo0Fb83IyJC2K/ejTQT7mAtTC9+ 0DR+QS9880FnqMYmfpedyqGqcrM4i2tUiQZOmZx+pw/PuNyGTDE61l/iz4FgOTzs+ILI cU39gVCLWwRATb2Hmpacjkfr/Z/RIPm2ejLekgPG5+5mDWkiJy+Gf9FuRQECFoi9S+0q xx7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=zJ8h5J/GzsFizFDzykuEv2VoRngJY+1FNO61J4rm+UQ=; b=A/14cyGJ5MtP1Pf1TXfqXhrtZXqSEGhO2rzjMDUOlnHxay01QAwGv4T6CqZOqMqhwk 3uIf6rkZIpuBxhWAyE6ES0lCJD2qHhX9t1FkPM9QPIysy+XFE8kN9Ue18mZH+i/gdRGo 81kCXob89vP8etx9aluu0eZl4I6zdYOZ1pbLj9VrGYdYNlOgodbkginzGOtZhlr6NRUK ikoYKyJseVO9yixplbPdeL0M7YYf8XXnBHU1H320Q4MflNxGXCUibOPTGwAV2j8PVyEI GmUTIdGcQTXa7LgTknAL9aZYZH3jbjEK5DZ7IHCdTFN4Ytw/UmOOwDCvpueV3oOT4Oeb 0vgQ== X-Gm-Message-State: APf1xPBrw1Rs+orrabQZF2oScmef9DlR8wag8Ijg9ZUlYbUOZq0j0X42 oK8VW5j/2w5eZDUte2119H8= X-Google-Smtp-Source: AH8x2245Q5dwQ3e/kBNmGgmsaPTxAIZGbjCrVC64/SAKvgY6vPsVsufUxteAgUzVuTuPQog8G3vMYA== X-Received: by 10.99.190.15 with SMTP id l15mr2630053pgf.325.1518710241875; Thu, 15 Feb 2018 07:57:21 -0800 (PST) Received: from [100.89.24.71] (204.sub-174-214-18.myvzw.com. [174.214.18.204]) by smtp.gmail.com with ESMTPSA id q62sm47076641pfd.48.2018.02.15.07.57.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 15 Feb 2018 07:57:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Subir X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Thu, 15 Feb 2018 21:27:14 +0530 Cc: ethan.grossman@dolby.com, craig.gunther@harman.com, pthubert@cisco.com, pwetterw@cisco.com, raymond.jean@hydro.qc.ca, jouni.nospam@gmail.com, yu1.kaneko@toshiba.co.jp, sdas@appcomsci.com, zhayiyong@huawei.com, balazs.a.varga@ericsson.com, janos.farkas@ericsson.com, franz-josef.goetz@siemens.com, juergen.jues.schmitt@siemens.com, xvilajosana@worldsensing.com, toktam.mahmoodi@kcl.ac.uk, spis@intracom-telecom.com, petra.vizarreta@lkn.ei.tum.de, huang.guangping@zte.com.cn, gengxuesong@huawei.com, diego.dujovne@mail.udp.cl, maseewal@cisco.com, DetNet WG , DetNet Chairs Content-Transfer-Encoding: 7bit Message-Id: <10A80472-EBCC-42A5-AE6D-0354B3758972@gmail.com> References: To: Lou Berger Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:43 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 15:57:24 -0000 No, I'm not aware of any IPR that applies to this draft. Sent from my iPhone > On Feb 14, 2018, at 11:58 PM, Lou Berger wrote: > > > > Authors, Contributors, WG, > > As part of the preparation for WG LC: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty. > > Thank you, > DetNet WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet From nobody Thu Feb 15 08:40:29 2018 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 0C65F12DA4C; Thu, 15 Feb 2018 08:14:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.02 X-Spam-Level: X-Spam-Status: No, score=-1.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kcl.ac.uk 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 GneD37BBjmyh; Thu, 15 Feb 2018 08:14:07 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0135.outbound.protection.outlook.com [104.47.1.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C78212D949; Thu, 15 Feb 2018 08:14:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kcl.ac.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=mfRhLh6Gro431Iv+Ls7rQK1J/1R9JQqf/6/D22vE90s=; b=UGbEJH8nWGNmLJ47andm8x57DEW5AMrKzmTy8v5/lSyLtSxGhxFedQhxzxOfkxngO/dVeL/1CLIvmHii3FTZRMy/5r1RFdlo/n7Bhk4x9CZeU2tRw+Anycaxd8qLBsM7qzLebD57jLV0IzpoNwnRd9Pse9kDvaup8Akv0ETi6vU= Received: from DB6PR03MB3061.eurprd03.prod.outlook.com (10.165.162.146) by DB6PR03MB2901.eurprd03.prod.outlook.com (10.165.140.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.10; Thu, 15 Feb 2018 16:14:04 +0000 Received: from DB6PR03MB3061.eurprd03.prod.outlook.com ([fe80::68f5:60e0:cdb1:bd02]) by DB6PR03MB3061.eurprd03.prod.outlook.com ([fe80::68f5:60e0:cdb1:bd02%13]) with mapi id 15.20.0485.016; Thu, 15 Feb 2018 16:14:04 +0000 From: "Mahmoodi, Toktam" To: Subir , Lou Berger CC: "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" , DetNet WG , DetNet Chairs Thread-Topic: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGgBtjnwQkqqUOLGgyxIRk1/qOln8cAgAAEp4Q= Date: Thu, 15 Feb 2018 16:14:03 +0000 Message-ID: References: , <10A80472-EBCC-42A5-AE6D-0354B3758972@gmail.com> In-Reply-To: <10A80472-EBCC-42A5-AE6D-0354B3758972@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=toktam.mahmoodi@kcl.ac.uk; x-originating-ip: [159.92.238.45] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR03MB2901; 6:+q97Nbbm4XRSO+cqLTMbn851hHBhLifNaZt51d/0O5i7I6hveEkwS6+7drUL2SHCGhNhR5lIty3P0LZ1lcMWKe+3dx0Vi1lhcF6y0mNIsAqgIf9X+sDk3SRZUZ+B4fqPelLctKM/a//hCKxkyXy8wdydVa7EudQhTYMGTrgSugQZ8p4hNGROgRK4+suL4+7Nt8+xt2uyGrhyif8A87/Lt5B1bNKMl0uipTwoGFG6/AJFqfR7gpGnpfhpD9p2Mncc1V8i8GO++bF1ro1pvvUV+5JsdHDlO6palOYUJlrJDG/xFyHlFIfqM4Zwo+DmUo/5pw5Xy6ZAi/0kGbAtuYanOryZZ2Vvyje5EBPz3pPmfOQ9eTyc5oKogi+4u3liZbFb; 5:BsCoIQ5c2GGTyEtmXbrrqAK6xzDaCOj/08tfJqJJQhw4JeKM/K8dAY+EbJRvHPC/EiNdK5T317X+0DE4zK5516M60A3Q4+bqt6wh91a8dLsgrXDyTRhhXPdkxtf2qvYuGGfKsw9U4DOKn6ApnoAEQQjegD1z7cKHkqJ35HDJuYg=; 24:rUeMBcK1EsKZCJ20oXMWd0CBkiua1fnqTtoi9k11lGyQYW+KbqL9/VY0BilwpcriljC7yEA3Iv0YvI8M+EdjGFH3ds+5UVtU1HI0GwKpWno=; 7:erdpC0Cni0tIWi2dO5ZM8+N+RoDWJ2MRzE20XqXQAvatd5rRC5kupXKoDSumUiKCPJYGycaY60pjiqYHuillzjYJ510PQ2d7mtTUkpk/LpH4Q5hdaPAMjIj5dMJl6Jz+0kJEkWUzjqCEyOEHv+wRHfBCVGjsXNYX0dy+DkdrMSbqTrOnI+0SpXG9ogbhkuFGaK+pxfhCVISIMcudWhzWXtl0Js0d2U3ONc80YgryL0QYufYuUt7vQcI61zNU3D27 x-ms-office365-filtering-correlation-id: 107070a1-ee3c-4994-870a-08d5748f21dc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR03MB2901; x-ms-traffictypediagnostic: DB6PR03MB2901: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(189930954265078)(50582790962513)(85827821059158)(95692535739014)(126837547833334)(45079756050767); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6041288)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DB6PR03MB2901; BCL:0; PCL:0; RULEID:; SRVR:DB6PR03MB2901; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(376002)(346002)(39380400002)(366004)(189003)(199004)(478600001)(25786009)(105586002)(2906002)(7416002)(3846002)(966005)(3280700002)(45080400002)(4326008)(39060400002)(97736004)(55016002)(54896002)(6116002)(6436002)(6306002)(6606003)(53936002)(99286004)(26005)(86362001)(9686003)(54906003)(76176011)(102836004)(786003)(7736002)(8676002)(5660300001)(19627405001)(8936002)(81166006)(68736007)(6246003)(236005)(6506007)(53546011)(33656002)(186003)(316002)(5003630100001)(606006)(14971765001)(2950100002)(42882006)(74316002)(14454004)(3660700001)(229853002)(110136005)(5250100002)(66066001)(106356001)(7696005)(81156014)(74482002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR03MB2901; H:DB6PR03MB3061.eurprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: kcl.ac.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: tnnBBpJ8hr0w6U2OHGNfTygRov3BuVz5fj+Jaf9/cIQKqFwHyHHzDYM5G5WRvu0VbDAGKmCr845i9HcLMjY9tQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB6PR03MB3061C6021D661F3218471665A0F40DB6PR03MB3061eurp_" MIME-Version: 1.0 X-OriginatorOrg: kcl.ac.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 107070a1-ee3c-4994-870a-08d5748f21dc X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 16:14:03.9414 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8370cf14-16f3-4c16-b83c-724071654356 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR03MB2901 Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:43 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 16:14:15 -0000 --_000_DB6PR03MB3061C6021D661F3218471665A0F40DB6PR03MB3061eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm not aware of any IPR that applies to this draft, neither. Toktam ________________________________ From: Subir Sent: 15 February 2018 15:57:14 To: Lou Berger Cc: ethan.grossman@dolby.com; craig.gunther@harman.com; pthubert@cisco.com;= pwetterw@cisco.com; raymond.jean@hydro.qc.ca; jouni.nospam@gmail.com; yu1.= kaneko@toshiba.co.jp; sdas@appcomsci.com; zhayiyong@huawei.com; balazs.a.va= rga@ericsson.com; janos.farkas@ericsson.com; franz-josef.goetz@siemens.com;= juergen.jues.schmitt@siemens.com; xvilajosana@worldsensing.com; Mahmoodi, = Toktam; spis@intracom-telecom.com; petra.vizarreta@lkn.ei.tum.de; huang.gua= ngping@zte.com.cn; gengxuesong@huawei.com; diego.dujovne@mail.udp.cl; masee= wal@cisco.com; DetNet WG; DetNet Chairs Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 No, I'm not aware of any IPR that applies to this draft. Sent from my iPhone > On Feb 14, 2018, at 11:58 PM, Lou Berger wrote: > > > > Authors, Contributors, WG, > > As part of the preparation for WG LC: > > Are you aware of any IPR that applies to drafts identified above? > > Please state either: > > "No, I'm not aware of any IPR that applies to this draft" > or > "Yes, I'm aware of IPR that applies to this draft" > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)? > > If yes to the above, please state either: > > "Yes, the IPR has been disclosed in compliance with IETF IPR rules" > or > "No, the IPR has not been disclosed" > > If you answer no, please provide any additional details you think > appropriate. > > If you are listed as a document author or contributor please answer the > above by responding to this email regardless of whether or not you are > aware of any relevant IPR. This document will not advance to the next > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S > TO LINES. > > If you are on the WG email list or attend WG meetings but are not listed > as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are > aware of IPR of others on an IETF contribution, or to refrain from > participating in any contribution or discussion related to your > undisclosed IPR. For more information, please see the RFCs listed above > and > https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Ftrac.= tools.ietf.org%2Fgroup%2Fiesg%2Ftrac%2Fwiki%2FIntellectualProperty&data=3D0= 1%7C01%7Ctoktam.mahmoodi%40kcl.ac.uk%7Cf896f094ce5d46018fd408d5748ccd54%7C8= 370cf1416f34c16b83c724071654356%7C0&sdata=3Dxc4OvoS6R%2FN%2Bz9ckdyzrJBbFT2%= 2FPR39zY%2FXdXFR5%2FMk%3D&reserved=3D0. > > Thank you, > DetNet WG Chairs > > PS Please include all listed in the headers of this message in your > response. > > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.= ietf.org%2Fmailman%2Flistinfo%2Fdetnet&data=3D01%7C01%7Ctoktam.mahmoodi%40k= cl.ac.uk%7Cf896f094ce5d46018fd408d5748ccd54%7C8370cf1416f34c16b83c724071654= 356%7C0&sdata=3DjK5YiSGGq75Hf%2FSWYGPEx6NpFD07QlA8YF%2Ff5JiMOuI%3D&reserved= =3D0 --_000_DB6PR03MB3061C6021D661F3218471665A0F40DB6PR03MB3061eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I'm not aware of any IPR that applies to this draft, neither.


Toktam

From: Subir <subirdas21@= gmail.com>
Sent: 15 February 2018 15:57:14
To: Lou Berger
Cc: ethan.grossman@dolby.com; craig.gunther@harman.com; pthubert@cis= co.com; pwetterw@cisco.com; raymond.jean@hydro.qc.ca; jouni.nospam@gmail.co= m; yu1.kaneko@toshiba.co.jp; sdas@appcomsci.com; zhayiyong@huawei.com; bala= zs.a.varga@ericsson.com; janos.farkas@ericsson.com; franz-josef.goetz@siemens.com; juergen.jues.schmitt@siemens.com; xvilajosa= na@worldsensing.com; Mahmoodi, Toktam; spis@intracom-telecom.com; petra.viz= arreta@lkn.ei.tum.de; huang.guangping@zte.com.cn; gengxuesong@huawei.com; d= iego.dujovne@mail.udp.cl; maseewal@cisco.com; DetNet WG; DetNet Chairs
Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-1= 3
 
No, I'm not aware of any IPR that applies to this = draft.

Sent from my iPhone

> On Feb 14, 2018, at 11:58 PM, Lou Berger <lberger@labn.net> wrot= e:
>
>
>
> Authors, Contributors, WG,
>
> As part of the preparation for WG LC:
>
> Are you aware of any IPR that applies to drafts identified above?
>
> Please state either:
>
> "No, I'm not aware of any IPR that applies to this draft" > or
> "Yes, I'm aware of IPR that applies to this draft"
>
> If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3669, 5378 and 8179 for more details)?
>
> If yes to the above, please state either:
>
> "Yes, the IPR has been disclosed in compliance with IETF IPR rule= s"
> or
> "No, the IPR has not been disclosed"
>
> If you answer no, please provide any additional details you think
> appropriate.
>
> If you are listed as a document author or contributor please answer th= e
> above by responding to this email regardless of whether or not you are=
> aware of any relevant IPR. This document will not advance to the next<= br> > stage until a response has been received from each author and listed > contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS MESSAGE'S=
> TO LINES.
>
> If you are on the WG email list or attend WG meetings but are not list= ed
> as an author or contributor, we remind you of your obligations under > the IETF IPR rules which encourages you to notify the IETF if you are<= br> > aware of IPR of others on an IETF contribution, or to refrain from
> participating in any contribution or discussion related to your
> undisclosed IPR. For more information, please see the RFCs listed abov= e
> and
> https://emea01.safelinks.protection.outlook.com/?url=3Dhttp%3A%2F%2Ftrac.to= ols.ietf.org%2Fgroup%2Fiesg%2Ftrac%2Fwiki%2FIntellectualProperty&data= =3D01%7C01%7Ctoktam.mahmoodi%40kcl.ac.uk%7Cf896f094ce5d46018fd408d5748ccd54= %7C8370cf1416f34c16b83c724071654356%7C0&sdata=3Dxc4OvoS6R%2FN%2Bz9ckdyz= rJBbFT2%2FPR39zY%2FXdXFR5%2FMk%3D&reserved=3D0.
>
> Thank you,
> DetNet WG Chairs
>
> PS Please include all listed in the headers of this message in your > response.
>
>
> _______________________________________________
> detnet mailing list
> detnet@ietf.org
> https://emea01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ie= tf.org%2Fmailman%2Flistinfo%2Fdetnet&data=3D01%7C01%7Ctoktam.mahmoodi%4= 0kcl.ac.uk%7Cf896f094ce5d46018fd408d5748ccd54%7C8370cf1416f34c16b83c7240716= 54356%7C0&sdata=3DjK5YiSGGq75Hf%2FSWYGPEx6NpFD07QlA8YF%2Ff5JiMOuI%3D&am= p;reserved=3D0
--_000_DB6PR03MB3061C6021D661F3218471665A0F40DB6PR03MB3061eurp_-- From nobody Thu Feb 15 08:40:32 2018 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 3F17F12DA51 for ; Thu, 15 Feb 2018 08:25:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Xy4x245G; dkim=pass (1024-bit key) header.d=ericsson.com header.b=dwQ5twUc 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 Ym2CPIycszCm for ; Thu, 15 Feb 2018 08:25:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 4FF54126B7E for ; Thu, 15 Feb 2018 08:25:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518711932; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5C917Dl1bKBHeWH6S//ouFkhXpA1dyYuC/KOe9xfZPs=; b=Xy4x245GVjsshBrbApmI4BS0e1hXtG8gIUTZNOBmg2uSoj6bGzkQA3FYh/A6h/eP djHMZr/HB5KRJeKjjPEb1/paqqJyaAODq7yFSsC+PoFeCqovbZ0IOHP7oFhPEhx0 kmXuCpbuToUjWOr+zt8ZX+WOIj3Vw3X6aceO48nibe8=; X-AuditID: c1b4fb25-473ff7000000341b-a3-5a85b47cb70e Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 95.8B.13339.C74B58A5; Thu, 15 Feb 2018 17:25:32 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 15 Feb 2018 17:25:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5C917Dl1bKBHeWH6S//ouFkhXpA1dyYuC/KOe9xfZPs=; b=dwQ5twUcaJhp/eD+jahmapxJcw6VQLzJ5sa4XPzwWTVTt1/hlPQJwUhDWvb2T9lkbxUI5BT9ma6RMgwpXzP6ih8jOZ64nePwwsUB05xHIMLMYqFklxnZueGp+HybehJOzTAzabyx9mlvgiFto9PBfw+HpsHq+TOLSG5guKEPWaE= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB1549.eurprd07.prod.outlook.com (10.165.238.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Thu, 15 Feb 2018 16:25:29 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::f8bc:9e5b:947:26fd%17]) with mapi id 15.20.0506.020; Thu, 15 Feb 2018 16:25:29 +0000 From: =?utf-8?B?QmFsw6F6cyBWYXJnYSBB?= To: Lou Berger , "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , Janos Farkas , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGosf+NzXBYRkW5HDAOEcVq0qOlp5rA Date: Thu, 15 Feb 2018 16:25:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [94.21.187.181] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1549; 7:esmWis1XvuXuvLV1Xm48+hxO4DtrHO80GbsJjyGjlWY2JtTbS3ZU18b6sXSVHNNZkmoRzWjwA79c2ztedwNQkd2xN6XO+6+XeRtrDvvMrdGub5yll6lRleUzRwfu6AaAchKjo6EDiMxrQlPWUoam62uWTda1qhz1/j9SwlNa+R1VQA/IkKvkWaTIBJTYmqQ60KU+G08XuCdhyx/a/XvphabcGZiFn+ZR4Zj0vvtIl0br+f5W/GWUQxkyB7ueVviO x-ms-office365-filtering-correlation-id: 8d3e9f3e-dabb-44c5-de05-08d57490ba3c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:VI1PR07MB1549; x-ms-traffictypediagnostic: VI1PR07MB1549: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(41521381080715)(50582790962513)(85827821059158)(95692535739014)(126837547833334); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001026)(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(10201501046)(3002001)(93006095)(93001095)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR07MB1549; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1549; x-forefront-prvs: 058441C12A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39380400002)(39860400002)(346002)(396003)(366004)(189003)(199004)(13464003)(85202003)(6246003)(76176011)(99286004)(6436002)(6116002)(3660700001)(5250100002)(316002)(110136005)(53936002)(2900100001)(229853002)(9686003)(54906003)(4326008)(8666007)(25786009)(2501003)(7696005)(39060400002)(68736007)(66066001)(3846002)(6306002)(7416002)(97736004)(2950100002)(5660300001)(33656002)(6346003)(55016002)(81156014)(478600001)(105586002)(8936002)(81166006)(186003)(8676002)(966005)(102836004)(53546011)(3280700002)(7736002)(2906002)(6506007)(305945005)(26005)(2201001)(86362001)(74316002)(14454004)(85182001)(106356001)(921003)(1121003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB1549; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-microsoft-antispam-message-info: wEBUvViSUoczF/u2Vm8do1QIgVl3tmOQRd1gWIWdkNAfu0zxynIyFkV5/eW2MebbZb+kvqmslHYS5JBoiffBoQ== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d3e9f3e-dabb-44c5-de05-08d57490ba3c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 16:25:29.0519 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1549 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sf0yMcRzHfZ/n+zz31Nx8negjjM6vaRSy+W7yc8Zjw1g2djMcnhFJ7onR 2KLCalapqHNIrlD6IemoHI7ktjg6+Tm1I4tR+mGJy4+7e9j8935/X5/f+wqs5jIfJETFxEmG GH20lvfHuWssc6fsr0zWTb1cN45eaS3m6LO0Pkzd3acwvXT/GkeLuibSruYujlreJnK088Vz ht4qTWBoU8tBjh5NbMfUea5WRV3PNDQnqwPRUmsuotbmcoa6XoygFmcHT2tbcjhqrz/C0vZC u4q6ywvwvGGi82sGFrPcVzjRmnEPizeMb1Risc2MxaR77ZzY2VbPiGbzd0Z01LtZsS1vrdhZ kciLNlszEjM6HCrRYj/OiK+Kw8X8tgZuxWCdf8RmKTpqj2QIm7PBf2tdjpWP7Q3ae9WajROQ KSgF+QlAZkDvNxOTgvwFDbmL4OvFI3/NAwRutxN5DSbdDFT0nuEVcpKB4w/eYMW4EDheGzlv MZ4shOsVJs4LAkifAC0FSSovYMli+HgnH3n1EBIBaX35rFcHkNlws6wUKXo6WLPMvnhMxoPl gsun1WQtFDXc98VoyCxI+lDmy/Xz1ElOf+4ZVhAQGQWuEqq0CoRXrWcZZTkC5loHq+ih8PHd L07RwZDZ1q9S9ChoPJvqWxNIJQO3M379Bcug2pTHKMBzjKfuFqSAEKiqOYS8jYFsh+ymyUpM KoL+D42sYk6x8PRlOa8kjIS3j25iBVTxkGsx8co6ElwoSUbpKNT43+hGT2GWTIKy6jDlORiy Ul0qo+8Yg8Ge24rzEC5CQ2VJ3rhjy/TwUMkQtUmWd8aExkhxFcjzh+9UusdfR87P822ICEg7 UF25LVmn4fR75H07bAgEVhug7tJ5ntSb9fviJcPO9Ybd0ZJsQyMErA1U25eodRqyRR8nbZek WMnwjzKCX1ACGjRmdHfe+erYePndCfPKOm0t+XFXHVHyxG/Cj58wLzBsbM1Pa/bEY6uqji7Y Nebx0gnLmWXXZn3OPjjtZX/jp8efwh3B4/ZHfimbAesW3ThhPY2bDs0faR79m59ZkxIfIjUU 9KQt/M0URhzOHP6+IfpA5N7Qng27M1+r81NXp59/iAf0aLG8VT8thDXI+j+bJacGvwMAAA== Archived-At: X-Mailman-Approved-At: Thu, 15 Feb 2018 08:39:43 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 16:25:39 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N CkNoZWVycyBCYWxhJ3pzDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMb3Ug QmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpTZW50OiAyMDE4LiBmZWJydcOhciAx NC4gMTk6MjgNClRvOiBldGhhbi5ncm9zc21hbkBkb2xieS5jb207IGNyYWlnLmd1bnRoZXJAaGFy bWFuLmNvbTsgcHRodWJlcnRAY2lzY28uY29tOyBwd2V0dGVyd0BjaXNjby5jb207IHJheW1vbmQu amVhbkBoeWRyby5xYy5jYTsgam91bmkubm9zcGFtQGdtYWlsLmNvbTsgeXUxLmthbmVrb0B0b3No aWJhLmNvLmpwOyBzZGFzQGFwcGNvbXNjaS5jb207IHpoYXlpeW9uZ0BodWF3ZWkuY29tOyBCYWzD oXpzIFZhcmdhIEEgPGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbT47IEphbm9zIEZhcmthcyA8 SmFub3MuRmFya2FzQGVyaWNzc29uLmNvbT47IGZyYW56LWpvc2VmLmdvZXR6QHNpZW1lbnMuY29t OyBqdWVyZ2VuLmp1ZXMuc2NobWl0dEBzaWVtZW5zLmNvbTsgeHZpbGFqb3NhbmFAd29ybGRzZW5z aW5nLmNvbTsgdG9rdGFtLm1haG1vb2RpQGtjbC5hYy51azsgc3Bpc0BpbnRyYWNvbS10ZWxlY29t LmNvbTsgcGV0cmEudml6YXJyZXRhQGxrbi5laS50dW0uZGU7IGh1YW5nLmd1YW5ncGluZ0B6dGUu Y29tLmNuOyBnZW5neHVlc29uZ0BodWF3ZWkuY29tOyBkaWVnby5kdWpvdm5lQG1haWwudWRwLmNs OyBtYXNlZXdhbEBjaXNjby5jb20NCkNjOiBEZXROZXQgQ2hhaXJzIDxkZXRuZXQtY2hhaXJzQGll dGYub3JnPjsgRGV0TmV0IFdHIDxkZXRuZXRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZWdhcmRpbmcg SVBSIG9uIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMw0KDQoNCg0KQXV0aG9ycywgQ29u dHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExDOg0K DQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlm aWVkIGFib3ZlPw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBub3QgYXdhcmUg b2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdh cmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMg SVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2Vl IFJGQ3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRv IHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMgYmVl biBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJObywg dGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVh c2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4N Cg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3Ig cGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2Fy ZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBS LiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwg YSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQg Y29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBU SElTIE1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlz dCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBv ciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRo ZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYg aWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9u LCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9y IGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5m b3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJh Yy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0 eS4NCg0KVGhhbmsgeW91LA0KRGV0TmV0IFdHIENoYWlycw0KDQpQUyBQbGVhc2UgaW5jbHVkZSBh bGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNl Lg0KDQoNCg== From nobody Thu Feb 15 23:58:37 2018 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 BCE4212D7F5; Thu, 15 Feb 2018 23:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 o-pXeEFkSwdN; Thu, 15 Feb 2018 23:58:32 -0800 (PST) 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 301B212D7EE; Thu, 15 Feb 2018 23:58:32 -0800 (PST) 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 w1G7wTWU026559 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Feb 2018 08:58:30 +0100 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 w1G7vrnC000841 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 16 Feb 2018 08:58:29 +0100 Received: from DENBGAT9ERPMSX.ww902.siemens.net (139.22.70.194) by DEFTHW99ERGMSX.ww902.siemens.net (139.22.70.132) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 16 Feb 2018 08:58:24 +0100 Received: from DEFTHW99EK3MSX.ww902.siemens.net ([169.254.4.69]) by DENBGAT9ERPMSX.ww902.siemens.net ([139.22.70.194]) with mapi id 14.03.0361.001; Fri, 16 Feb 2018 08:58:23 +0100 From: "Schmitt, Juergen" To: Lou Berger CC: "detnet@ietf.org" , "detnet-chairs@ietf.org" Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGis+HK2ZctOkat7Clw2kMFVaOmrAhQ Date: Fri, 16 Feb 2018 07:58:23 +0000 Message-ID: <4E310F17BD503646BD155B102AF875E81E4957EC@DEFTHW99EK3MSX.ww902.siemens.net> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [139.22.70.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 16 Feb 2018 07:58:36 -0000 Ik5vLCBJJ20gbm90IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQi DQoNCg0KSsO8cmdlbiBTY2htaXR0DQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQt LS0tLQ0KVm9uOiBMb3UgQmVyZ2VyIFttYWlsdG86bGJlcmdlckBsYWJuLm5ldF0gDQpHZXNlbmRl dDogTWl0dHdvY2gsIDE0LiBGZWJydWFyIDIwMTggMTk6MjgNCkFuOiBldGhhbi5ncm9zc21hbkBk b2xieS5jb207IGNyYWlnLmd1bnRoZXJAaGFybWFuLmNvbTsgcHRodWJlcnRAY2lzY28uY29tOyBw d2V0dGVyd0BjaXNjby5jb207IHJheW1vbmQuamVhbkBoeWRyby5xYy5jYTsgam91bmkubm9zcGFt QGdtYWlsLmNvbTsgeXUxLmthbmVrb0B0b3NoaWJhLmNvLmpwOyBzZGFzQGFwcGNvbXNjaS5jb207 IHpoYXlpeW9uZ0BodWF3ZWkuY29tOyBiYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb207IGphbm9z LmZhcmthc0Blcmljc3Nvbi5jb207IEdvZXR6LCBGcmFuei1Kb3NlZiAoUEQgVEkgQVQgNCk7IFNj aG1pdHQsIEp1ZXJnZW4gKERGIENTIFNEIEVIIDEgMyk7IHh2aWxham9zYW5hQHdvcmxkc2Vuc2lu Zy5jb207IHRva3RhbS5tYWhtb29kaUBrY2wuYWMudWs7IHNwaXNAaW50cmFjb20tdGVsZWNvbS5j b207IHBldHJhLnZpemFycmV0YUBsa24uZWkudHVtLmRlOyBodWFuZy5ndWFuZ3BpbmdAenRlLmNv bS5jbjsgZ2VuZ3h1ZXNvbmdAaHVhd2VpLmNvbTsgZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDsg bWFzZWV3YWxAY2lzY28uY29tDQpDYzogRGV0TmV0IENoYWlyczsgRGV0TmV0IFdHDQpCZXRyZWZm OiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMw0KDQoNCg0K QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24g Zm9yIFdHIExDOg0KDQpBcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRy YWZ0cyBpZGVudGlmaWVkIGFib3ZlPw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEkn bSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoi WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBz bywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQ UiBydWxlcyAoc2VlIFJGQ3MgMzY2OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8N Cg0KSWYgeWVzIHRvIHRoZSBhYm92ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhl IElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVz Ig0Kb3INCiJObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5z d2VyIG5vLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBh cHByb3ByaWF0ZS4NCg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3Ig Y29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlz IGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkg cmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQg c3RhZ2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9y IGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9V IExJU1RFRCBJTiBUSElTIE1FU1NBR0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUg V0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFz IGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRp b25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3Rp ZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYg Y29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29u dHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4g Rm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFu ZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxl Y3R1YWxQcm9wZXJ0eS4NCg0KVGhhbmsgeW91LA0KRGV0TmV0IFdHIENoYWlycw0KDQpQUyBQbGVh c2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5 b3VyIHJlc3BvbnNlLg0KDQoNCg== From nobody Fri Feb 16 08:04:34 2018 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 F1F4712DB6C; Thu, 15 Feb 2018 09:28:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 e8pUTweMlv8y; Thu, 15 Feb 2018 09:28:04 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.15]) (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 1BC4A12D775; Thu, 15 Feb 2018 09:28:03 -0800 (PST) Received: from [216.82.250.83] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-15.bemta-12.messagelabs.com id 6B/DA-03104-223C58A5; Thu, 15 Feb 2018 17:28:02 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJsWRWlGSWpSXmKPExsXinSZ8TFfxcGu UwbGXRhYn/k5gtbjW/4PF4ven2SwWK49tZbVY9VHd4uO9j6wW2x81s1p8uHGdyWLflTYmi/3r Gpgsrt5vZLXoaH7LYnF54R52i4fXhCxmTHnHaLFu30xGi333NjBZPLwhbbH98js2iz33Z7Ban DzezmzxdtlJdovfG5ayOIh7XP4ykcVjyu+NrB77Jh5h8fj19Sqbx85Zd9k9Wo68ZfX48Pw4k8 eSJT+ZPM4f/83s8XxBjMeHTc1sHocO3WP0mPjuPLvH9pOTmDxurTb2WPT8DGuAYBRrZl5SfkU Ca8buZQeZCq7KV1xe8YS1gXGBfBcjF4eQwGZGiSlXrjNCOJsYJVrWPoRyDjJKfOp4xdLFyMnB JmAo0dfcywySEBH4wyGx9cxlZpAEs4C7xMuDixhBbGEgu33bXDBbRMBD4suiGywQtpHE+e8Tw OpZBFQlrvxayAJhG0m0fu8Ds3mBek8evglmCwlYS7S8WA9WzylgI9E64ToTiM0oICbx/dQaJo i94hK3nswHsyUEBCSW7DnPDGGLSrx8/I8VwjaQ2Lp0HwuELSexbPtzoHoOoF5NifW79CHGKEp M6X7IDnGCoMTJmU+gTlCVWHh/ItMERolZSLbNQuiehaR7FpLuBYwsqxg1ilOLylKLdE1M9JKK MtMzSnITM3N0DQ2N9HJTi4sT01NzEpOK9ZLzczcxAhNcPQMD4w7GD/ujDzFKcjApifKmxLZGC fEl5adUZiQWZ8QXleakFh9ilOHgUJLgXXkQKCdYlJqeWpGWmQNMtTBpCQ4eJRHeJJA0b3FBYm 5xZjpE6hSjJce3vQ/amDluvHgNJLcse9PGLMSSl5+XKiXOuwCkQQCkIaM0D24cLB9cYpSVEuZ lZGBgEOIpSC3KzSxBlX/FKM7BqCTMK3UIaApPZl4J3NZXQAcxAR3EqwR2UEkiQkqqgTHaXyJl 1vu7zX0mOhun99wzPbKzOOnLlfboGhbLQFW1PwurFzv94+R76Pe756njbuc4fqcCz/o1ZuplJ 2ezaE9YuufIjPALQcmRfgssN/5N2rJWUOi7ht/kZR3fM3k827WlznOt1FnmpHxnubzsIX9fLU 1m6wZmvWAxrY5MnwfxB/s+BBVaKbEUZyQaajEXFScCAOKFlncCBAAA X-Env-Sender: craig.gunther@harman.com X-Msg-Ref: server-10.tower-120.messagelabs.com!1518715677!133551015!5 X-Originating-IP: [75.102.19.198] X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25335 invoked from network); 15 Feb 2018 17:28:01 -0000 Received: from unknown.ord.scnet.net (HELO HICGWSMB10.ad.harman.com) (75.102.19.198) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Feb 2018 17:28:01 -0000 Received: from HICGWSMB04.ad.harman.com (10.10.24.97) by HICGWSMB10.ad.harman.com (10.10.24.242) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 15 Feb 2018 09:27:59 -0800 Received: from HICGWSMB01.ad.harman.com (10.10.24.94) by HICGWSMB04.ad.harman.com (10.10.24.97) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 15 Feb 2018 09:27:57 -0800 Received: from HICGWSMB01.ad.harman.com ([fe80::91b7:22df:5f7f:96a9]) by HICGWSMB01.ad.harman.com ([fe80::91b7:22df:5f7f:96a9%14]) with mapi id 15.00.1365.000; Thu, 15 Feb 2018 09:27:56 -0800 From: "Gunther, Craig" To: Lou Berger , "ethan.grossman@dolby.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "gengxuesong@huawei.com" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" CC: DetNet Chairs , DetNet WG Thread-Topic: [EXTERNAL] Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcG7EmbCrrg+WEmhJOEeEu9UA6OluIIw Date: Thu, 15 Feb 2018 17:27:49 +0000 Deferred-Delivery: Thu, 15 Feb 2018 17:27:37 +0000 Message-ID: <4d6c509a1c5f4e8f8d0fb273f7b09af2@HICGWSMB01.ad.harman.com> 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.70.50.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-Mailman-Approved-At: Fri, 16 Feb 2018 08:04:33 -0800 Subject: Re: [Detnet] [EXTERNAL] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 15 Feb 2018 17:28:07 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdA0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTG91IEJlcmdlciBbbWFpbHRvOmxi ZXJnZXJAbGFibi5uZXRdIA0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNCwgMjAxOCAxMToy OCBBTQ0KVG86IGV0aGFuLmdyb3NzbWFuQGRvbGJ5LmNvbTsgR3VudGhlciwgQ3JhaWcgPGNyYWln Lmd1bnRoZXJAaGFybWFuLmNvbT47IHB0aHViZXJ0QGNpc2NvLmNvbTsgcHdldHRlcndAY2lzY28u Y29tOyByYXltb25kLmplYW5AaHlkcm8ucWMuY2E7IGpvdW5pLm5vc3BhbUBnbWFpbC5jb207IHl1 MS5rYW5la29AdG9zaGliYS5jby5qcDsgc2Rhc0BhcHBjb21zY2kuY29tOyB6aGF5aXlvbmdAaHVh d2VpLmNvbTsgYmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tOyBqYW5vcy5mYXJrYXNAZXJpY3Nz b24uY29tOyBmcmFuei1qb3NlZi5nb2V0ekBzaWVtZW5zLmNvbTsganVlcmdlbi5qdWVzLnNjaG1p dHRAc2llbWVucy5jb207IHh2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb207IHRva3RhbS5tYWht b29kaUBrY2wuYWMudWs7IHNwaXNAaW50cmFjb20tdGVsZWNvbS5jb207IHBldHJhLnZpemFycmV0 YUBsa24uZWkudHVtLmRlOyBodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbjsgZ2VuZ3h1ZXNvbmdA aHVhd2VpLmNvbTsgZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDsgbWFzZWV3YWxAY2lzY28uY29t DQpDYzogRGV0TmV0IENoYWlycyA8ZGV0bmV0LWNoYWlyc0BpZXRmLm9yZz47IERldE5ldCBXRyA8 ZGV0bmV0QGlldGYub3JnPg0KU3ViamVjdDogW0VYVEVSTkFMXSBSZWdhcmRpbmcgSVBSIG9uIGRy YWZ0LWlldGYtZGV0bmV0LXVzZS1jYXNlcy0xMw0KDQoNCg0KQXV0aG9ycywgQ29udHJpYnV0b3Jz LCBXRywNCg0KQXMgcGFydCBvZiB0aGUgcHJlcGFyYXRpb24gZm9yIFdHIExDOg0KDQpBcmUgeW91 IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0cyBpZGVudGlmaWVkIGFib3Zl Pw0KDQpQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQoiTm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQ UiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCm9yDQoiWWVzLCBJJ20gYXdhcmUgb2YgSVBS IHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQpJZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4g ZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzY2 OSwgNTM3OCBhbmQgODE3OSBmb3IgbW9yZSBkZXRhaWxzKT8NCg0KSWYgeWVzIHRvIHRoZSBhYm92 ZSwgcGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9z ZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0Kb3INCiJObywgdGhlIElQUiBo YXMgbm90IGJlZW4gZGlzY2xvc2VkIg0KDQpJZiB5b3UgYW5zd2VyIG5vLCBwbGVhc2UgcHJvdmlk ZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KSWYgeW91 IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFu c3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Yg d2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBhbnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRv Y3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3RhZ2UgdW50aWwgYSByZXNwb25z ZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0 b3IuIE5PVEU6IFRISVMgQVBQTElFUyBUTyBBTEwgT0YgWU9VIExJU1RFRCBJTiBUSElTIE1FU1NB R0UnUyBUTyBMSU5FUy4NCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRl bmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmli dXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQ UiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFy ZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byBy ZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Np b24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24s IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwczovL2NsaWNrdGltZS5z eW1hbnRlYy5jb20vYS8xL0JKWXU0MHBVX3pZc1RjVU9jY3lrMzE5SmVpdWc2X2I5Zm40dEx3b3Y1 X2M9P2Q9ZlZBX3lHVW1kNE1rVXE0ZjBnTkZLb3ZwTy1SN3RQbzZfTEd5SkhOdUM5YUtPSFQ2VFZX eVE0MjVRYXhpV0lmbDJ3WDZ5cmRwblhhVE5TR0V1d3VRM0NWUDhzelRtWkFPWkdRQ2x2WWlWRl9a MXV4cGphODRZbm1fTjBLRFFHWkwyMGs3OUczTHV0WE9wTzJhY2Fqb2xBWC1nU1Y4dnBMMXBZUnlh cldWSFp6UWhVZ2pNbmVqcUN0UGdRMXBaaDRSU0dSM1hFRTVjeEUyYURhYkhVbncyc3Z2ZWRXVU8x ZnpFTTgtdGJhZjRkb3p6eHVpTEYzUEhoaVRCUlR5Qnk0T0lKUWZQV3l2cFZwYzlzYzVpX2VoX1ZQ MFd1N29UTEpqYnZzLS1ZNE5uaVRKRnlkVDN2MmxBT2tTQmhQeHNXdXhSQ1RGaVprMjhVb1hPYWow dFIxc1FQNHFpZ1owSDR3UXZlN0lfeU9NcW9rNWNnTndidVY3WUMxVjBCbnVYUEVINFElM0QlM0Qm dT1odHRwJTNBJTJGJTJGdHJhYy50b29scy5pZXRmLm9yZyUyRmdyb3VwJTJGaWVzZyUyRnRyYWMl MkZ3aWtpJTJGSW50ZWxsZWN0dWFsUHJvcGVydHkuDQoNClRoYW5rIHlvdSwNCkRldE5ldCBXRyBD aGFpcnMNCg0KUFMgUGxlYXNlIGluY2x1ZGUgYWxsIGxpc3RlZCBpbiB0aGUgaGVhZGVycyBvZiB0 aGlzIG1lc3NhZ2UgaW4geW91ciByZXNwb25zZS4NCg0KDQo= From nobody Wed Feb 21 07:25:10 2018 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 4F3D51270AB for ; Wed, 21 Feb 2018 07:25:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.06 X-Spam-Level: X-Spam-Status: No, score=-4.06 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, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=UORQSXTC; dkim=pass (1024-bit key) header.d=ericsson.com header.b=hPMSgeKg 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 fsV9TugI7S40 for ; Wed, 21 Feb 2018 07:25:06 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 83535127010 for ; Wed, 21 Feb 2018 07:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1519226704; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=4HIwSq9z8YS+W4i9Fk7F25aaRt/iBLeDHv6btRTsf6s=; b=UORQSXTCH/0WnZwtXxvesJ4vWu6Eg2N7cMNp3BzUq6EaHcSDwTKqZHx5FED5aqc3 dfP1pfmH7mKWKMEKLcXzHs2LIeHvKE2Hflo2UovDmu7GGR+MvU+lph40dK3d6ggt fnVvMZkZAkB8VpAMJmW7L9hrkULGObL8W8Md4yTEG40=; X-AuditID: c1b4fb3a-35fff700000067b4-51-5a8d8f505770 Received: from ESESSHC022.ericsson.se (Unknown_Domain [153.88.183.84]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 5F.66.26548.05F8D8A5; Wed, 21 Feb 2018 16:25:04 +0100 (CET) Received: from ESESSMR501.ericsson.se (153.88.183.108) by ESESSHC022.ericsson.se (153.88.183.84) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 21 Feb 2018 16:25:03 +0100 Received: from ESESSMB505.ericsson.se (153.88.183.166) by ESESSMR501.ericsson.se (153.88.183.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Wed, 21 Feb 2018 16:25:03 +0100 Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB505.ericsson.se (153.88.183.166) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26 via Frontend Transport; Wed, 21 Feb 2018 16:25:03 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3iPrPaefa+sUhgNk6cI8+HM4wQ508FriCiW8lpapdpY=; b=hPMSgeKgnm4Jp2rzaF0vdRCcYA4/XVWNFkfHYVp+CQ2w6rsi8cMYazw0WkxH3HcYA5YlgLj/rQh7SAaj9k/2S2lC4SekDdjk0n+uyn/lkw5CHt4wUTpfTFEFzXx4WUSe23YNMUBCh35XhneN9YsL0gSVBKeMcaLmmlYgI8ACUGQ= Received: from VI1PR07MB1005.eurprd07.prod.outlook.com (10.161.110.21) by VI1PR07MB3231.eurprd07.prod.outlook.com (10.175.243.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Wed, 21 Feb 2018 15:25:02 +0000 Received: from VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::2c76:12a5:c368:af0a]) by VI1PR07MB1005.eurprd07.prod.outlook.com ([fe80::2c76:12a5:c368:af0a%3]) with mapi id 15.20.0527.012; Wed, 21 Feb 2018 15:25:02 +0000 From: =?iso-8859-1?Q?Bal=E1zs_Varga_A?= To: "detnet@ietf.org" Thread-Topic: Service model related update in draft-ietf-detnet-flow-information-model Thread-Index: AdOrJ3dKFHpzr2fESAGkZn/5CyG/Dg== Date: Wed, 21 Feb 2018 15:25:02 +0000 Message-ID: Accept-Language: hu-HU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.a.varga@ericsson.com; x-originating-ip: [84.236.33.255] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3231; 7:AOuCrMGnU4E6aB+PNXfZ0mJfyqqxko0VIb5xzX1ZHkJ6HOP8JQ6lAjE5Ki/g+WT+sV3mTQJEutDVrSUwNXNRHvyGNGACKX6uZVzLZnSUVrx3c33bDNVMtwwXEWbQYqURPx1O/uyiNC+l+vswdiAJtUhc3bTOIfG9dJRhTN03r1GdR9EvqbgeKtIM9/v9fWe8h0md1MOZgpnElwOWy2tAVw3OlkYfTSj6j9PjgWlOORn3o5d0rX+5opQUJ2AC2aGY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 64e20a92-3b26-4cc9-fc75-08d5793f4727 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:VI1PR07MB3231; x-ms-traffictypediagnostic: VI1PR07MB3231: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001068)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR07MB3231; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3231; x-forefront-prvs: 0590BBCCBC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(39380400002)(396003)(376002)(346002)(199004)(189003)(2906002)(3280700002)(33656002)(6916009)(106356001)(86362001)(3660700001)(316002)(55016002)(1730700003)(81166006)(236005)(81156014)(97736004)(8676002)(25786009)(54896002)(68736007)(53936002)(3846002)(9686003)(6436002)(105586002)(8936002)(790700001)(2900100001)(5640700003)(9326002)(7110500001)(6306002)(6116002)(102836004)(7736002)(5250100002)(26005)(2501003)(606006)(15650500001)(2420400007)(66066001)(99286004)(6506007)(10710500007)(5660300001)(2351001)(478600001)(7696005)(186003)(14454004)(5630700001)(59450400001)(74316002)(19609705001)(7756004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3231; H:VI1PR07MB1005.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: MZ2pGC5thHc8H2BQx9V2zsvABjSxarZ2RlFHcAcsefRkH8+6hYJrm3P3fkvIiN6yzZU1TkFgxv60zIAbIv1iW9DYjkHCpp7BzEYVvjzBomdp6UFSZ/+zsv/BB+PPcxY5KBHHzYIuWTfeTz1QHUCnKDnUXe4b9oVvpePs29wKtBQ= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB1005F3BD55E177A485A6695FACCE0VI1PR07MB1005eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 64e20a92-3b26-4cc9-fc75-08d5793f4727 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2018 15:25:02.4934 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3231 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGee+9267L0ZspHjQFBxJYmyZBImpaCCUKmhE20lx5/cCP2a5a 9sUIs5qYShZ+RGqsoZKWpk7FUCfhhMCSKJlCqUOZFagro0aa13eB//2e5zznnPfAy9IeTSIf NqegiNMWqPPkYilTn2I6rUisqlSFjN/2DXOuNTLR6ITB8JtKRCppRAaXl1PCaYOj0qXZA39G mEJH4JUHukGkQ+YAPXJjAR+G9+ODlB5JWQ88hmD2sYUhogfBrdkamohfCJwGh4iIZxRMt9yT CILBaxT0PrJKSKWGgk+GPlfPPALHS7tEWCPGseC4OycW2BPvh/JvH5EesexenAwrzUDsFJh6 PioRbE+sBKM1X7AZHAj3bcvbU2T4HLwemWSECMJ+MNcRJtg09garrYki92AwDE3ShL3AvrAh EhjhNHAO62ihFXAAWMqvkYgfTDVVIOHBgHsoMD41MqSghN6a74hwAqzbN8WELQhM/ZcJB0FV w2dXJhc6ZxZce+Ng820VTYY20mCy1blC+6B7oJEihXYxDLe9EVcjRcOOIwhrwL5qEzds37wH JuptDPGVMP2wVkz4ABhbvtKEFVC3YWZ2+s1I0o68eI7n87NCQ5WcNuciz2sKlAVcUTfa+jaj Pc7wfjS6FGNGmEVyd9nEjUqVh0hdwpfmmxGwtNxTZknfsmQZ6tKrnFZzXlucx/Fm5Msycm/Z scwwlQfOUhdxuRxXyGn/VynWzUeH/BMcbTFL89mJfY8zi8fjkXdw1ox/1Jm4kutna8MzUVLS +oXIH4ttyoMV2Frf2XvpSc+XSPvx5DRR/M2/BgirPYJTXy1GaJZPxq2+Kz0l6jIk7WoNGVO4 mz6UuvNld8qQMdk/RrGiL2u1LB+t6Bh7sbukWjU71G3vqviZKoqNljN8tvpQEK3l1f8ABGqC BDIDAAA= Archived-At: Subject: [Detnet] Service model related update in draft-ietf-detnet-flow-information-model X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 21 Feb 2018 15:25:08 -0000 --_000_VI1PR07MB1005F3BD55E177A485A6695FACCE0VI1PR07MB1005eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, We've got comments to update service model related text in "draft-ietf-detn= et-flow-information-model". For that update we are considering the following inputs: - Service model related IETF considerations are recently published in rfc83= 09, especially the customer service m= odel illustrated in Figure 1 - Several aspects of such a service model were discussed in "draft-varga-de= tnet-service-model", e.g., Chapter 5. In order to improve service model text we consider to extend "draft-ietf-de= tnet-flow-information-model" with DetNet service model, service parameters; serv= ice reference points and service scenarios. Any comments, suggestions are welcome. We suggest discussion on the details= after putting the updates on the table in a new revision of the draft, e.g= ., in London. Regards, Bala'zs & J=E1nos --_000_VI1PR07MB1005F3BD55E177A485A6695FACCE0VI1PR07MB1005eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

We've got comments to update service model related t= ext in “draft-ietf-detnet-flow-information-model”.

For that update we are considering the following inp= uts:
- Service model related IETF considerations are recently published in rfc8309, especially  the customer service model illustrated in Fig= ure 1
- Several aspects of such a service model were discussed in “draft-var= ga-detnet-service-model”, e.g., Chapter 5.

In order to improve service model text we consider t= o extend “draft-ietf-detnet-flow-information-model” w= ith DetNet service model, service parameters; service reference points and service scenarios.

 

Any comments, suggestions are welcome. We suggest di= scussion on the details after putting the updates on the table in a new rev= ision of the draft, e.g., in London.

 

Regards,
Bala’zs & J=E1nos

 

 

--_000_VI1PR07MB1005F3BD55E177A485A6695FACCE0VI1PR07MB1005eurp_-- From nobody Fri Feb 23 07:49:26 2018 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 8B8A012E878 for ; Fri, 23 Feb 2018 07:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 GA4URSbx0WyX for ; Fri, 23 Feb 2018 07:49:24 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 32C501271DF for ; Fri, 23 Feb 2018 07:49:24 -0800 (PST) Received: from cmgw4 (unknown [10.0.90.85]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id BBFC3175E45 for ; Fri, 23 Feb 2018 08:49:23 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id EFpK1x0142SSUrH01FpNjy; Fri, 23 Feb 2018 08:49:23 -0700 X-Authority-Analysis: v=2.2 cv=G85sK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=NojvYFcnAAAA:8 a=-QDdsokXnC-ciJDEfDgA:9 a=QEXdDO2ut3YA:10 a=L4dRxlfgLVMA:10 a=RBq7MeES940A: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:Sender:Reply-To:Cc:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=XaROxlKGygi4x5oVmCliZYA8Pg+tJqKowegrBW4M1II=; b=DGtiJbqy62nRnsP+t0t4LEcJUo OM3cFsA8PWJSugJHmeCllrrOdid4lfKxFhHjzk5fHUWjI9yDR7AYV41ZOvt1PkkvsRLt4FD2ILJ8p tv5M2Ah8/gylO0YjEQLeyFz12; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:51650 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1epFb5-003Imr-OJ for detnet@ietf.org; Fri, 23 Feb 2018 08:49:19 -0700 To: DetNet WG From: Lou Berger Message-ID: Date: Fri, 23 Feb 2018 10:49:16 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1epFb5-003Imr-OJ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:51650 X-Source-Auth: lberger@labn.net X-Email-Count: 6 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Detnet] webex recording of interim - DetNet Data Plane #3 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 23 Feb 2018 15:49:25 -0000 (Thanks to Andy for the reminder to send this) Recording Information: Interim: DetNet Data Plane #3-20180214 1505-1 Topic: Interim: DetNet Data Plane #3-20180214 1505-1 Create time: 2/14/18 12:26 pm File size: 89.56MB Duration: 2 hours 16 minutes Security: Description: Streaming recording link: https://ietf.webex.com/ietf/ldr.php?RCID=31291b05cbff43820ac8bcd3120c9abd Download recording link: https://ietf.webex.com/ietf/lsr.php?RCID=80b30651899cabc9aeecd57e0200f91a From nobody Fri Feb 23 07:58:12 2018 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 C287612E88C for ; Fri, 23 Feb 2018 07:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.739 X-Spam-Level: X-Spam-Status: No, score=-1.739 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwSaXqTv641Y for ; Fri, 23 Feb 2018 07:58:08 -0800 (PST) Received: from mail-wr0-x236.google.com (mail-wr0-x236.google.com [IPv6:2a00:1450:400c:c0c::236]) (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 9BE7A12E85E for ; Fri, 23 Feb 2018 07:58:07 -0800 (PST) Received: by mail-wr0-x236.google.com with SMTP id n7so14605218wrn.5 for ; Fri, 23 Feb 2018 07:58:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=k5of3wsgtNdq19oTkDKIOhmH6sLTUh0JgHVM123lb9A=; b=YuMAqS/uEOSfW9p3HwJlXMOhS8te9ylxJ6VnLUVmGO1nUNmx7+ZR3A8IvNU6IYqzXO zBvetRmBgDtnBe4HhiTVNURzy2RkOYiuLVMvafs4H9sdqAsxnBxg9EdiWipCbtd7Sk3C VRcm+iCpRlf+9+GWSRNArD5Ab1H2+VbKwkVhYZWYm0cduUYrcy2EMSkJEsdoDpUZr2D4 6qQ+g+elKJwqoB4ecmr4kTXUfoNlkPl2eVTPR9xOUpd/in9/Diyws/Q7xszbhmiEwlan LbnH+/en7Z/yJ7EIe0UwL72mBRhetwGULNf9iN7XUo/bXR+GisEKg5yRiki1XFJGjYqv q3JA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k5of3wsgtNdq19oTkDKIOhmH6sLTUh0JgHVM123lb9A=; b=UEC4HaAWZCAiNsFDjHp8OyfuYryEOCRbnAyRTlAWeX32L+Hi8SqxqhWQXVYftmwms2 gRllUmz1pZVRfVDc9D6Yw4iEXzCWaphJSgLP/IBfi9ZdxQNdKq4NU+qNxcffVfdFH9om qMYhPRe8Jm2Oj3SEHSoiCso0bP1dcsAPdVcQ8U+xHZfPY+i6tXjYoSYY1UfurCvcCsHN LxqkFtULdlKHZ4ofRp26QqL8EXAUbMh6C16HhOB/p0fifBKlFKsGRWOBXFZt2Pp6dlyP bGZYyhiwqxeWd8zj6ON89rCZLDRFOB0m6XvPKBvNJMHVfj2k0QVyjlmFuC3rPH4pqhsP ip2A== X-Gm-Message-State: APf1xPCjdDp1Rgz4wcPJm13EIMY39LxLoXzzF2bwipgu7ClcROMVysFE wbsbaKrXaL04WJsiDXGotcAC7wnQXdIQMRjwXYw= X-Google-Smtp-Source: AH8x227+8hL8sx6IoLyaFWT91Zc7cYYQ+yTqSPqTKiE/vSnuolTBfrr208W8xxpTPJhZkGdKmCPsfg/AUaWgvjbz4W8= X-Received: by 10.223.138.130 with SMTP id y2mr1963518wry.242.1519401486140; Fri, 23 Feb 2018 07:58:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.91.195 with HTTP; Fri, 23 Feb 2018 07:57:45 -0800 (PST) In-Reply-To: References: From: "Andrew G. Malis" Date: Fri, 23 Feb 2018 10:57:45 -0500 Message-ID: To: Lou Berger Cc: DetNet WG Content-Type: multipart/alternative; boundary="001a1144298eda49cd0565e339b8" Archived-At: Subject: Re: [Detnet] webex recording of interim - DetNet Data Plane #3 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 23 Feb 2018 15:58:10 -0000 --001a1144298eda49cd0565e339b8 Content-Type: text/plain; charset="UTF-8" Lou, Thanks! Cheers, Andy On Fri, Feb 23, 2018 at 10:49 AM, Lou Berger wrote: > (Thanks to Andy for the reminder to send this) > > Recording Information: Interim: DetNet Data Plane #3-20180214 1505-1 > > Topic: > Interim: DetNet Data Plane #3-20180214 1505-1 > Create time: > 2/14/18 12:26 pm > File size: > 89.56MB > Duration: > 2 hours 16 minutes > Security: > > Description: > Streaming recording link: > https://ietf.webex.com/ietf/ldr.php?RCID=31291b05cbff43820ac8bcd3120c9abd > > Download recording link: > https://ietf.webex.com/ietf/lsr.php?RCID=80b30651899cabc9aeecd57e0200f91a > > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > --001a1144298eda49cd0565e339b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lou,

Thanks!

C= heers,
Andy

=
On Fri, Feb 23, 2018 at 10:49 AM, Lou Berger= <lberger@labn.net> wrote:
= (Thanks to Andy for the reminder to send this)

Recording Information: Interim: DetNet Data Plane #3-20180214 1505-1

Topic:
Interim: DetNet Data Plane #3-20180214 1505-1
Create time:
2/14/18 12:26 pm
File size:
89.56MB
Duration:
2 hours 16 minutes
Security:

Description:
Streaming recording link:
https://ietf.webex.com/ie= tf/ldr.php?RCID=3D31291b05cbff43820ac8bcd3120c9abd

Download recording link:
https://ietf.webex.com/ie= tf/lsr.php?RCID=3D80b30651899cabc9aeecd57e0200f91a

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

--001a1144298eda49cd0565e339b8-- From nobody Fri Feb 23 09:24:25 2018 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 EA04712E6A3; Wed, 21 Feb 2018 18:05:42 -0800 (PST) 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, URIBL_BLOCKED=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 KU-u9Xbhtd_K; Wed, 21 Feb 2018 18:05:40 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5C1E5126C83; Wed, 21 Feb 2018 18:05:40 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1DB15E94EDDC3; Thu, 22 Feb 2018 02:05:37 +0000 (GMT) Received: from DGGEMA404-HUB.china.huawei.com (10.3.20.45) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 22 Feb 2018 02:05:37 +0000 Received: from DGGEMA501-MBX.china.huawei.com ([169.254.1.200]) by DGGEMA404-HUB.china.huawei.com ([10.3.20.45]) with mapi id 14.03.0361.001; Thu, 22 Feb 2018 10:05:31 +0800 From: "Gengxuesong (Geng Xuesong)" To: Lou Berger , "ethan.grossman@dolby.com" , "craig.gunther@harman.com" , "pthubert@cisco.com" , "pwetterw@cisco.com" , "raymond.jean@hydro.qc.ca" , "jouni.nospam@gmail.com" , "yu1.kaneko@toshiba.co.jp" , "sdas@appcomsci.com" , "zhayiyong@huawei.com" , "balazs.a.varga@ericsson.com" , "janos.farkas@ericsson.com" , "franz-josef.goetz@siemens.com" , "juergen.jues.schmitt@siemens.com" , "xvilajosana@worldsensing.com" , "toktam.mahmoodi@kcl.ac.uk" , "spis@intracom-telecom.com" , "petra.vizarreta@lkn.ei.tum.de" , "huang.guangping@zte.com.cn" , "diego.dujovne@mail.udp.cl" , "maseewal@cisco.com" CC: DetNet Chairs , DetNet WG Thread-Topic: Regarding IPR on draft-ietf-detnet-use-cases-13 Thread-Index: AQHTpcGibW9kLCLezU2erCLlvGEhO6OvtzpA Date: Thu, 22 Feb 2018 02:05:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 23 Feb 2018 09:24:24 -0800 Subject: Re: [Detnet] Regarding IPR on draft-ietf-detnet-use-cases-13 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 02:05:43 -0000 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4N Cg0KWHVlc29uZw0KDQoNCj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExvdSBC ZXJnZXIgW21haWx0bzpsYmVyZ2VyQGxhYm4ubmV0XQ0KPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFy eSAxNSwgMjAxOCAyOjI4IEFNDQo+VG86IGV0aGFuLmdyb3NzbWFuQGRvbGJ5LmNvbTsgY3JhaWcu Z3VudGhlckBoYXJtYW4uY29tOw0KPnB0aHViZXJ0QGNpc2NvLmNvbTsgcHdldHRlcndAY2lzY28u Y29tOyByYXltb25kLmplYW5AaHlkcm8ucWMuY2E7DQo+am91bmkubm9zcGFtQGdtYWlsLmNvbTsg eXUxLmthbmVrb0B0b3NoaWJhLmNvLmpwOyBzZGFzQGFwcGNvbXNjaS5jb207DQo+emhheWl5b25n QGh1YXdlaS5jb207IGJhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbTsNCj5qYW5vcy5mYXJrYXNA ZXJpY3Nzb24uY29tOyBmcmFuei1qb3NlZi5nb2V0ekBzaWVtZW5zLmNvbTsNCj5qdWVyZ2VuLmp1 ZXMuc2NobWl0dEBzaWVtZW5zLmNvbTsgeHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbTsNCj50 b2t0YW0ubWFobW9vZGlAa2NsLmFjLnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29tOw0KPnBl dHJhLnZpemFycmV0YUBsa24uZWkudHVtLmRlOyBodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbjsg R2VuZ3h1ZXNvbmcNCj4oR2VuZyBYdWVzb25nKTsgZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDsg bWFzZWV3YWxAY2lzY28uY29tDQo+Q2M6IERldE5ldCBDaGFpcnM7IERldE5ldCBXRw0KPlN1Ympl Y3Q6IFJlZ2FyZGluZyBJUFIgb24gZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEzDQo+DQo+ DQo+DQo+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCj4NCj5BcyBwYXJ0IG9mIHRoZSBwcmVw YXJhdGlvbiBmb3IgV0cgTEM6DQo+DQo+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBw bGllcyB0byBkcmFmdHMgaWRlbnRpZmllZCBhYm92ZT8NCj4NCj5QbGVhc2Ugc3RhdGUgZWl0aGVy Og0KPg0KPiJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz IGRyYWZ0Ig0KPm9yDQo+IlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp cyBkcmFmdCINCj4NCj5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBs aWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MNCj4zNjY5LCA1Mzc4IGFuZCA4MTc5 IGZvciBtb3JlIGRldGFpbHMpPw0KPg0KPklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0 ZSBlaXRoZXI6DQo+DQo+IlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxp YW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KPm9yDQo+Ik5vLCB0aGUgSVBSIGhhcyBub3QgYmVl biBkaXNjbG9zZWQiDQo+DQo+SWYgeW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFk ZGl0aW9uYWwgZGV0YWlscyB5b3UgdGhpbmsgYXBwcm9wcmlhdGUuDQo+DQo+SWYgeW91IGFyZSBs aXN0ZWQgYXMgYSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0 aGUgYWJvdmUNCj5ieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0 aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueQ0KPnJlbGV2YW50IElQUi4gVGhpcyBkb2N1 bWVudCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UN Cj5oYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0 b3IuIE5PVEU6IFRISVMgQVBQTElFUw0KPlRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVT U0FHRSdTIFRPIExJTkVTLg0KPg0KPklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3Ig YXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxpc3RlZCBhcyBhbg0KPmF1dGhvciBvciBj b250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJ RVRGIElQUiBydWxlcw0KPndoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBp ZiB5b3UgYXJlIGF3YXJlIG9mIElQUiBvZiBvdGhlcnMgb24gYW4NCj5JRVRGIGNvbnRyaWJ1dGlv biwgb3IgdG8gcmVmcmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBv cg0KPmRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUg aW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlDQo+UkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQo+aHR0 cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFs UHJvcGVydHkuDQo+DQo+VGhhbmsgeW91LA0KPkRldE5ldCBXRyBDaGFpcnMNCj4NCj5QUyBQbGVh c2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5 b3VyIHJlc3BvbnNlLg0KPg0KDQo= From nobody Fri Feb 23 09:24:31 2018 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 2859212E8AD; Wed, 21 Feb 2018 19:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.208 X-Spam-Level: X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=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 8prN1cBPeKPZ; Wed, 21 Feb 2018 19:16:18 -0800 (PST) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 743E71241FC; Wed, 21 Feb 2018 19:16:17 -0800 (PST) Received: from mxct.zte.com.cn (unknown [192.168.164.215]) by Forcepoint Email with ESMTPS id D6294B9BE27AC33415F1; Thu, 22 Feb 2018 11:16:14 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Forcepoint Email with ESMTPS id 9E8F1A053D9395569D5B; Thu, 22 Feb 2018 11:16:14 +0800 (CST) Received: from kjyxapp04.zte.com.cn ([10.30.12.203]) by mse02.zte.com.cn with SMTP id w1M3Fidu043560; Thu, 22 Feb 2018 11:15:44 +0800 (GMT-8) (envelope-from huang.guangping@zte.com.cn) Received: from mapi (kjyxapp01[null]) by mapi (Zmail) with MAPI id mid17; Thu, 22 Feb 2018 11:15:45 +0800 (CST) Date: Thu, 22 Feb 2018 11:15:45 +0800 (CST) X-Zmail-TransId: 2b035a8e35e1463-3a3ed X-Mailer: Zmail v1.0 Message-ID: <201802221115453730872@zte.com.cn> In-Reply-To: References: a5bf4312-b3be-88fe-fe9b-b6b15d426bb1@labn.net, F1C1D5B02EA3FA4A8AF54C86BA4F325C22C8C0A8@DGGEMA501-MBX.china.huawei.com Mime-Version: 1.0 From: To: Cc: , , , , , , , , , , , , , , , , , , , , , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse02.zte.com.cn w1M3Fidu043560 Archived-At: X-Mailman-Approved-At: Fri, 23 Feb 2018 09:24:24 -0800 Subject: [Detnet] =?utf-8?b?562U5aSNOiBSRTogUmVnYXJkaW5nIElQUiBvbiBkcmFm?= =?utf-8?q?t-ietf-detnet-use-cases-13?= X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 22 Feb 2018 03:16:21 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiBhcHBseWluZyB0byB0aGlzIGRyYWZ0Lg0KDQoN Cg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K DQrpu4TlhYnlubMgaHVhbmdndWFuZ3BpbmcNCg0KDQoNCg0KDQoNCumihOeglOagh+WHhumDqC/m nInnur/noJTnqbbpmaIv5pyJ57q/5Lqn5ZOB57uP6JCl6YOoIFN0YW5kYXJkIFByZXJlc2VhcmNo IERlcHQuL1dpcmVsaW5lIFByb2R1Y3QgT3BlcmF0aW9uIERpdmlzaW9uDQoNCg0KDQoNCg0KDQoN Cg0KDQrljZfkuqzluILpm6joirHljLrova/ku7blpKfpgZM1MOWPt+S4reWFtOmAmuiurzHlj7fm pbwgDQpSJkQgQnVpbGRpbmcsIFpURQpDb3Jwb3JhdGlvbiBTb2Z0d2FyZSBSb2FkIE5vLjUwLCAN Cll1aHVhIERpc3RyaWN0LCBOYW5qaW5nLCBQLi5SLkNoaW5hLCAyMTAwMTIgDQpNOiArODYgMTM3 NzAzMTEwNTIgDQpFOiBodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbiANCnd3dy56dGUuY29tLmNu DQoNCg0KDQoNCg0KDQoNCg0K5Y6f5aeL6YKu5Lu2DQoNCg0KDQoNCuWPkeS7tuS6uu+8miA8Z2Vu Z3h1ZXNvbmdAaHVhd2VpLmNvbT47DQrmlLbku7bkurrvvJogPGxiZXJnZXJAbGFibi5uZXQ+OyA8 ZXRoYW4uZ3Jvc3NtYW5AZG9sYnkuY29tPjsgPGNyYWlnLmd1bnRoZXJAaGFybWFuLmNvbT47IDxw dGh1YmVydEBjaXNjby5jb20+OyA8cHdldHRlcndAY2lzY28uY29tPjsgPHJheW1vbmQuamVhbkBo eWRyby5xYy5jYT47IDxqb3VuaS5ub3NwYW1AZ21haWwuY29tPjsgPHl1MS5rYW5la29AdG9zaGli YS5jby5qcD47IDxzZGFzQGFwcGNvbXNjaS5jb20+OyA8emhheWl5b25nQGh1YXdlaS5jb20+OyA8 YmFsYXpzLmEudmFyZ2FAZXJpY3Nzb24uY29tPjsgPGphbm9zLmZhcmthc0Blcmljc3Nvbi5jb20+ OyA8ZnJhbnotam9zZWYuZ29ldHpAc2llbWVucy5jb20+OyA8anVlcmdlbi5qdWVzLnNjaG1pdHRA c2llbWVucy5jb20+OyA8eHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbT47IDx0b2t0YW0ubWFo bW9vZGlAa2NsLmFjLnVrPjsgPHNwaXNAaW50cmFjb20tdGVsZWNvbS5jb20+OyA8cGV0cmEudml6 YXJyZXRhQGxrbi5laS50dW0uZGU+O+m7hOWFieW5szEwMDM5NzE0OyA8ZGllZ28uZHVqb3ZuZUBt YWlsLnVkcC5jbD47IDxtYXNlZXdhbEBjaXNjby5jb20+Ow0K5oqE6YCB5Lq677yaIDxkZXRuZXQt Y2hhaXJzQGlldGYub3JnPjsgPGRldG5ldEBpZXRmLm9yZz47DQrml6Ug5pyfIO+8mjIwMTjlubQw MuaciDIy5pelIDEwOjA1DQrkuLsg6aKYIO+8mlJFOiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWll dGYtZGV0bmV0LXVzZS1jYXNlcy0xMw0KDQoNCg0KDQoNCg0KTm8sIEknbSBub3QgYXdhcmUgb2Yg YW55IElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdC4NCg0KWHVlc29uZw0KDQoNCj4tLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPkZyb206IExvdSBCZXJnZXIgW21haWx0bzpsYmVyZ2Vy QGxhYm4ubmV0XQ0KPlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAxNSwgMjAxOCAyOjI4IEFNDQo+ VG86IGV0aGFuLmdyb3NzbWFuQGRvbGJ5LmNvbTsgY3JhaWcuZ3VudGhlckBoYXJtYW4uY29tOw0K PnB0aHViZXJ0QGNpc2NvLmNvbTsgcHdldHRlcndAY2lzY28uY29tOyByYXltb25kLmplYW5AaHlk cm8ucWMuY2E7DQo+am91bmkubm9zcGFtQGdtYWlsLmNvbTsgeXUxLmthbmVrb0B0b3NoaWJhLmNv LmpwOyBzZGFzQGFwcGNvbXNjaS5jb207DQo+emhheWl5b25nQGh1YXdlaS5jb207IGJhbGF6cy5h LnZhcmdhQGVyaWNzc29uLmNvbTsNCj5qYW5vcy5mYXJrYXNAZXJpY3Nzb24uY29tOyBmcmFuei1q b3NlZi5nb2V0ekBzaWVtZW5zLmNvbTsNCj5qdWVyZ2VuLmp1ZXMuc2NobWl0dEBzaWVtZW5zLmNv bTsgeHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbTsNCj50b2t0YW0ubWFobW9vZGlAa2NsLmFj LnVrOyBzcGlzQGludHJhY29tLXRlbGVjb20uY29tOw0KPnBldHJhLnZpemFycmV0YUBsa24uZWku dHVtLmRlOyBodWFuZy5ndWFuZ3BpbmdAenRlLmNvbS5jbjsgR2VuZ3h1ZXNvbmcNCj4oR2VuZyBY dWVzb25nKTsgZGllZ28uZHVqb3ZuZUBtYWlsLnVkcC5jbDsgbWFzZWV3YWxAY2lzY28uY29tDQo+ Q2M6IERldE5ldCBDaGFpcnM7IERldE5ldCBXRw0KPlN1YmplY3Q6IFJlZ2FyZGluZyBJUFIgb24g ZHJhZnQtaWV0Zi1kZXRuZXQtdXNlLWNhc2VzLTEzDQo+DQo+DQo+DQo+QXV0aG9ycywgQ29udHJp YnV0b3JzLCBXRywNCj4NCj5BcyBwYXJ0IG9mIHRoZSBwcmVwYXJhdGlvbiBmb3IgV0cgTEM6DQo+ DQo+QXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdHMgaWRlbnRp ZmllZCBhYm92ZT8NCj4NCj5QbGVhc2Ugc3RhdGUgZWl0aGVyOg0KPg0KPiJObywgSSdtIG5vdCBh d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KPm9yDQo+Illlcywg SSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCj4NCj5JZiBzbywg aGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBy dWxlcyAoc2VlIFJGQ3MNCj4zNjY5LCA1Mzc4IGFuZCA4MTc5IGZvciBtb3JlIGRldGFpbHMpPw0K Pg0KPklmIHllcyB0byB0aGUgYWJvdmUsIHBsZWFzZSBzdGF0ZSBlaXRoZXI6DQo+DQo+Illlcywg dGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1 bGVzIg0KPm9yDQo+Ik5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQo+DQo+SWYg eW91IGFuc3dlciBubywgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3Ug dGhpbmsgYXBwcm9wcmlhdGUuDQo+DQo+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVudCBh dXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUNCj5ieSByZXNwb25k aW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3 YXJlIG9mIGFueQ0KPnJlbGV2YW50IElQUi4gVGhpcyBkb2N1bWVudCB3aWxsIG5vdCBhZHZhbmNl IHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UNCj5oYXMgYmVlbiByZWNlaXZlZCBm cm9tIGVhY2ggYXV0aG9yIGFuZCBsaXN0ZWQgY29udHJpYnV0b3IuIE5PVEU6IFRISVMgQVBQTElF Uw0KPlRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KPg0K PklmIHlvdSBhcmUgb24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1 dCBhcmUgbm90IGxpc3RlZCBhcyBhbg0KPmF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5k IHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcw0KPndoaWNo IGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3YXJlIG9mIElQ UiBvZiBvdGhlcnMgb24gYW4NCj5JRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVmcmFpbiBmcm9t IHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvcg0KPmRpc2N1c3Npb24gcmVsYXRl ZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBz ZWUgdGhlDQo+UkZDcyBsaXN0ZWQgYWJvdmUgYW5kDQo+aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuDQo+DQo+VGhhbmsg eW91LA0KPkRldE5ldCBXRyBDaGFpcnMNCj4NCj5QUyBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVk IGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KPg== --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPiA8cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1m YW1pbHk6YXJpYWw7Ij5ObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIGFwcGx5aW5nIHRvIHRo aXMgZHJhZnQuPC9wPjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsi Pjxicj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJy PjwvcD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9w PjxwIHN0eWxlPSJmb250LXNpemU6MTRweDtmb250LWZhbWlseTphcmlhbDsiPjxicj48L3A+PHAg c3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwvcD48ZGl2IGNs YXNzPSJ6TWFpbFNpZ24iIHVub25hbWVjaD0i6buE5YWJ5bmzMTAwMzk3MTQiIHVub25hbWVlbj0i aHVhbmdndWFuZ3BpbmcxMDAzOTcxNCI+PHAgY2xhc3M9InpNYWlsU2lnblRpdGxlIiB1bm9uYW1l Y2g9Ium7hOWFieW5szEwMDM5NzE0IiB1bm9uYW1lZW49Imh1YW5nZ3VhbmdwaW5nMTAwMzk3MTQi IHN0eWxlPSJkaXNwbGF5OiBub25lOyI+PGxhYmVsIGNsYXNzPSJzaWduX25hbWVVbm8iPjwvbGFi ZWw+PHNwYW4gY2xhc3M9InNpZ25fYXJyb3ciPjwvc3Bhbj48L3A+PGRpdiBjbGFzcz0iek1haWxT aWduQ29udGVudCI+PGRpdj48ZGl2PjxkaXY+PHAgc3R5bGU9ImZvbnQtZmFtaWx5OiDlrovkvZM7 IGZvbnQtc2l6ZToxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjE0cHg7Y29sb3I6IzU4NTk1Qjtmb250LWZhbWlseTrlvq7ova/pm4Xp u5E7Zm9udC1zaXplOjE0cHg7Ij48c3BhbiBjbGFzcz0ic2lnbmVkaXQiPjxicj48L3NwYW4+PC9z cGFuPjwvcD48cCBzdHlsZT0iZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOjE0cHg7IGxp bmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRw eDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSI+PHNwYW4gY2xhc3M9InNp Z25lZGl0IiBpZD0ic2lnbl9uYW1lIj7pu4TlhYnlubM8L3NwYW4+IDxzcGFuIHN0eWxlPSJmb250 LWZhbWlseTpBcmlhbCI+PHNwYW4gY2xhc3M9InNpZ25lZGl0IiBpZD0ic2lnbl9uYW1lX2VuZyI+ aHVhbmdndWFuZ3Bpbmc8L3NwYW4+PC9zcGFuPjwvc3Bhbj48L3A+PHAgc3R5bGU9ImZvbnQtc2l6 ZToxNHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyB3aWRvd3M6IDE7Ij48YnI+PC9wPjxwIHN0eWxl PSJmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6MTRweDsgbGluZS1oZWlnaHQ6IG5vcm1h bDsgd2lkb3dzOiAxOyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7 Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWdu X2RlcHQiPumihOeglOagh+WHhumDqC/mnInnur/noJTnqbbpmaIv5pyJ57q/5Lqn5ZOB57uP6JCl 6YOoPC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6QXJpYWwiPiA8c3BhbiBjbGFzcz0i c2lnbmVkaXQiIGlkPSJzaWduX2RlcHRfZW5nIj5TdGFuZGFyZCBQcmVyZXNlYXJjaCBEZXB0Li9X aXJlbGluZSBQcm9kdWN0IE9wZXJhdGlvbiBEaXZpc2lvbjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czog MTsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTtmb250LXNpemU6MTRweDsiPjxzcGFuIHN0eWxlPSIiPjxzcGFuIGNsYXNz PSJzaWduZWRpdCI+PGJyPjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwvcD48cCBzdHlsZT0iZm9udC1z aXplOjE0cHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHdpZG93czogMTsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTRweDtjb2xvcjojNTg1OTVCO2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTtmb250 LXNpemU6MTRweDsiPjwvc3Bhbj48L3A+PHRhYmxlIHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDAp OyBmb250LWZhbWlseTog5a6L5L2TOyB3aWRvd3M6IDE7Ij48dGJvZHk+PHRyIGNsYXNzPSJmaXJz dFJvdyI+PHRkIHZhbGlnbj0idG9wIiB3aWR0aD0iMTAwIj48aW1nIGlkPSJzaWduLWljb24iIHNy Yz0iY2lkOjlhZTNlMjE0YzE3ZDQ5ZWQ5MzVkODdjNjc0YmEzZWUyIiB3aWR0aD0iMTMwIiBoZWln aHQ9IjEyMCI+PC90ZD48dGQgdmFsaWduPSJ0b3AiIHdpZHRoPSI1MDAiIHN0eWxlPSJ3b3JkLWJy ZWFrOiBicmVhay1hbGw7Ij48aW1nIGlkPSJzaWduLWxvZ28iIHNyYz0iY2lkOjI0MjQyZTU2Mzdh ZjQyODg5MWM0ZGI3MzFlNzc2NWFkIiB3aWR0aD0iMTE1IiBoZWlnaHQ9IjM4Ij48YnI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNHB4O2NvbG9yOiM1ODU5NUI7Zm9udC1mYW1pbHk65b6u6L2v6ZuF 6buRIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX2FkZHIiPuWNl+S6rOW4gumbqOiK seWMuui9r+S7tuWkp+mBkzUw5Y+35Lit5YW06YCa6K6vMeWPt+alvCZuYnNwOzwvc3Bhbj48YnI+ PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkFyaWFsIj48c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlk PSJzaWduX2FkZHJfZW5nXzEiPlImYW1wO0QgQnVpbGRpbmcsIFpURQpDb3Jwb3JhdGlvbiBTb2Z0 d2FyZSBSb2FkIE5vLjUwPC9zcGFuPiwgPGJyPjxzcGFuIGNsYXNzPSJzaWduZWRpdCIgaWQ9InNp Z25fYWRkcl9lbmdfMiI+WXVodWEgRGlzdHJpY3QsIE5hbmppbmcsIFAuLlIuQ2hpbmEsIDIxMDAx Mjwvc3Bhbj4mbmJzcDs8YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhGRDQiPk08L3NwYW4+OiA8 c3BhbiBjbGFzcz0ic2lnbmVkaXQiIGlkPSJzaWduX3Bob25lIj4rODYgMTM3NzAzMTEwNTI8L3Nw YW4+IDxicj48c3BhbiBzdHlsZT0iY29sb3I6IzAwOEZENCI+RTwvc3Bhbj46IDxzcGFuIGNsYXNz PSJzaWduZWRpdCIgaWQ9InNpZ25fZW1haWwiPmh1YW5nLmd1YW5ncGluZ0B6dGUuY29tLmNuPC9z cGFuPiA8YnI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDhGRDQiPjxhIGhyZWY9Imh0dHA6Ly93d3cu enRlLmNvbS5jbi8iIHRhcmdldD0iX2JsYW5rIj53d3cuenRlLmNvbS5jbjwvYT48L3NwYW4+PC9z cGFuPjwvc3Bhbj48L3RkPjwvdHI+PC90Ym9keT48L3RhYmxlPjxzcGFuIHN0eWxlPSJsaW5lLWhl aWdodDogbm9ybWFsOyB3aWRvd3M6IDE7IGZvbnQtc2l6ZToxNHB4Oztjb2xvcjojNTg1OTViO2Zv bnQtc2l6ZToxMHB4Ij48L3NwYW4+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PC9kaXY+PGRpdiBj bGFzcz0iek1haWxGcm9tIj48L2Rpdj48ZGl2PjxkaXYgY2xhc3M9InpoaXN0b3J5Um93IiBzdHls ZT0iZGlzcGxheTpibG9jayI+PGRpdiBjbGFzcz0iemhpc3RvcnlEZXMiIHN0eWxlPSJ3aWR0aDog MTAwJTsgaGVpZ2h0OiAyOHB4OyBsaW5lLWhlaWdodDogMjhweDsgYmFja2dyb3VuZC1jb2xvcjog I0UwRTVFOTsgY29sb3I6ICMxMzg4RkY7IHRleHQtYWxpZ246IGNlbnRlcjsiIGxhbmd1YWdlLWRh dGE9Ikhpc3RvcnlPcmdUeHQiPuWOn+Wni+mCruS7tjwvZGl2PjxkaXYgaWQ9Inp3cml0ZUhpc3Rv cnlDb250YWluZXIiPjxkaXYgY2xhc3M9InpoaXN0b3J5Q3VycmVudENvbnRlbnQiPjxkaXYgY2xh c3M9ImNvbnRyb2wtZ3JvdXAgemhpc3RvcnlQYW5lbCI+PGRpdiBjbGFzcz0iemhpc3RvcnlIZWFk ZXIiIHN0eWxlPSJwYWRkaW5nOiA4cHg7IGJhY2tncm91bmQtY29sb3I6ICNGNUY2Rjg7Ij48ZGl2 PjxzdHJvbmcgbGFuZ3VhZ2UtZGF0YT0iSGlzdG9yeVNlbmRlclR4dCI+5Y+R5Lu25Lq677yaPC9z dHJvbmc+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiPiAmbHQ7Z2VuZ3h1ZXNvbmdAaHVhd2Vp LmNvbSZndDs7PC9zcGFuPjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5 VE9UeHQiPuaUtuS7tuS6uu+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBz dHlsZT0iZGlzcGxheTogaW5saW5lOyI+ICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0Ozs8L3NwYW4+ PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0 O2V0aGFuLmdyb3NzbWFuQGRvbGJ5LmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVz ZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ICZsdDtjcmFpZy5ndW50aGVyQGhhcm1h bi5jb20mZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPiAmbHQ7cHRodWJlcnRAY2lzY28uY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xh c3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O3B3ZXR0ZXJ3 QGNpc2NvLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0i ZGlzcGxheTogaW5saW5lOyI+ICZsdDtyYXltb25kLmplYW5AaHlkcm8ucWMuY2EmZ3Q7Ozwvc3Bh bj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPiAm bHQ7am91bmkubm9zcGFtQGdtYWlsLmNvbSZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVz ZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ICZsdDt5dTEua2FuZWtvQHRvc2hpYmEu Y28uanAmZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3Bs YXk6IGlubGluZTsiPiAmbHQ7c2Rhc0BhcHBjb21zY2kuY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xh c3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O3poYXlpeW9u Z0BodWF3ZWkuY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxl PSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O2JhbGF6cy5hLnZhcmdhQGVyaWNzc29uLmNvbSZndDs7 PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVhZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5l OyI+ICZsdDtqYW5vcy5mYXJrYXNAZXJpY3Nzb24uY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9 InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O2ZyYW56LWpvc2Vm LmdvZXR6QHNpZW1lbnMuY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUi IHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O2p1ZXJnZW4uanVlcy5zY2htaXR0QHNpZW1l bnMuY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNw bGF5OiBpbmxpbmU7Ij4gJmx0O3h2aWxham9zYW5hQHdvcmxkc2Vuc2luZy5jb20mZ3Q7Ozwvc3Bh bj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPiAm bHQ7dG9rdGFtLm1haG1vb2RpQGtjbC5hYy51ayZndDs7PC9zcGFuPjxzcGFuIGNsYXNzPSJ6cmVh ZFVzZXJOYW1lIiBzdHlsZT0iZGlzcGxheTogaW5saW5lOyI+ICZsdDtzcGlzQGludHJhY29tLXRl bGVjb20uY29tJmd0Ozs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJk aXNwbGF5OiBpbmxpbmU7Ij4gJmx0O3BldHJhLnZpemFycmV0YUBsa24uZWkudHVtLmRlJmd0Ozs8 L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7 Ij7pu4TlhYnlubMxMDAzOTcxNDs8L3NwYW4+PHNwYW4gY2xhc3M9InpyZWFkVXNlck5hbWUiIHN0 eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O2RpZWdvLmR1am92bmVAbWFpbC51ZHAuY2wmZ3Q7 Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIgc3R5bGU9ImRpc3BsYXk6IGlubGlu ZTsiPiAmbHQ7bWFzZWV3YWxAY2lzY28uY29tJmd0Ozs8L3NwYW4+PC9kaXY+PGRpdj48c3Ryb25n IGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlDQ1R4dCI+5oqE6YCB5Lq677yaPC9zdHJvbmc+PHNwYW4g Y2xhc3M9InpyZWFkVXNlck5hbWUiIHN0eWxlPSJkaXNwbGF5OiBpbmxpbmU7Ij4gJmx0O2RldG5l dC1jaGFpcnNAaWV0Zi5vcmcmZ3Q7Ozwvc3Bhbj48c3BhbiBjbGFzcz0ienJlYWRVc2VyTmFtZSIg c3R5bGU9ImRpc3BsYXk6IGlubGluZTsiPiAmbHQ7ZGV0bmV0QGlldGYub3JnJmd0Ozs8L3NwYW4+ PC9kaXY+PGRpdj48c3Ryb25nIGxhbmd1YWdlLWRhdGE9Ikhpc3RvcnlEYXRlVHh0Ij7ml6Ug5pyf IO+8mjwvc3Ryb25nPjxzcGFuIGNsYXNzPSIiPjIwMTjlubQwMuaciDIy5pelIDEwOjA1PC9zcGFu PjwvZGl2PjxkaXY+PHN0cm9uZyBsYW5ndWFnZS1kYXRhPSJIaXN0b3J5U3ViamVjdFR4dCI+5Li7 IOmimCDvvJo8L3N0cm9uZz48c3BhbiBjbGFzcz0ienJlYWRUaXRsZSI+PHN0cm9uZz5SRTogUmVn YXJkaW5nIElQUiBvbiBkcmFmdC1pZXRmLWRldG5ldC11c2UtY2FzZXMtMTM8L3N0cm9uZz48L3Nw YW4+PC9kaXY+PC9kaXY+PHAgY2xhc3M9InpoaXN0b3J5Q29udGVudCI+PGJyPjwvcD48L2Rpdj48 ZGl2Pk5vLCZuYnNwO0knbSZuYnNwO25vdCZuYnNwO2F3YXJlJm5ic3A7b2YmbmJzcDthbnkmbmJz cDtJUFImbmJzcDt0aGF0Jm5ic3A7YXBwbGllcyZuYnNwO3RvJm5ic3A7dGhpcyZuYnNwO2RyYWZ0 Ljxicj48YnI+WHVlc29uZzxicj48YnI+PGJyPiZndDstLS0tLU9yaWdpbmFsJm5ic3A7TWVzc2Fn ZS0tLS0tPGJyPiZndDtGcm9tOiZuYnNwO0xvdSZuYnNwO0JlcmdlciZuYnNwO1ttYWlsdG86bGJl cmdlckBsYWJuLm5ldF08YnI+Jmd0O1NlbnQ6Jm5ic3A7VGh1cnNkYXksJm5ic3A7RmVicnVhcnkm bmJzcDsxNSwmbmJzcDsyMDE4Jm5ic3A7MjoyOCZuYnNwO0FNPGJyPiZndDtUbzombmJzcDtldGhh bi5ncm9zc21hbkBkb2xieS5jb207Jm5ic3A7Y3JhaWcuZ3VudGhlckBoYXJtYW4uY29tOzxicj4m Z3Q7cHRodWJlcnRAY2lzY28uY29tOyZuYnNwO3B3ZXR0ZXJ3QGNpc2NvLmNvbTsmbmJzcDtyYXlt b25kLmplYW5AaHlkcm8ucWMuY2E7PGJyPiZndDtqb3VuaS5ub3NwYW1AZ21haWwuY29tOyZuYnNw O3l1MS5rYW5la29AdG9zaGliYS5jby5qcDsmbmJzcDtzZGFzQGFwcGNvbXNjaS5jb207PGJyPiZn dDt6aGF5aXlvbmdAaHVhd2VpLmNvbTsmbmJzcDtiYWxhenMuYS52YXJnYUBlcmljc3Nvbi5jb207 PGJyPiZndDtqYW5vcy5mYXJrYXNAZXJpY3Nzb24uY29tOyZuYnNwO2ZyYW56LWpvc2VmLmdvZXR6 QHNpZW1lbnMuY29tOzxicj4mZ3Q7anVlcmdlbi5qdWVzLnNjaG1pdHRAc2llbWVucy5jb207Jm5i c3A7eHZpbGFqb3NhbmFAd29ybGRzZW5zaW5nLmNvbTs8YnI+Jmd0O3Rva3RhbS5tYWhtb29kaUBr Y2wuYWMudWs7Jm5ic3A7c3Bpc0BpbnRyYWNvbS10ZWxlY29tLmNvbTs8YnI+Jmd0O3BldHJhLnZp emFycmV0YUBsa24uZWkudHVtLmRlOyZuYnNwO2h1YW5nLmd1YW5ncGluZ0B6dGUuY29tLmNuOyZu YnNwO0dlbmd4dWVzb25nPGJyPiZndDsoR2VuZyZuYnNwO1h1ZXNvbmcpOyZuYnNwO2RpZWdvLmR1 am92bmVAbWFpbC51ZHAuY2w7Jm5ic3A7bWFzZWV3YWxAY2lzY28uY29tPGJyPiZndDtDYzombmJz cDtEZXROZXQmbmJzcDtDaGFpcnM7Jm5ic3A7RGV0TmV0Jm5ic3A7V0c8YnI+Jmd0O1N1YmplY3Q6 Jm5ic3A7UmVnYXJkaW5nJm5ic3A7SVBSJm5ic3A7b24mbmJzcDtkcmFmdC1pZXRmLWRldG5ldC11 c2UtY2FzZXMtMTM8YnI+Jmd0Ozxicj4mZ3Q7PGJyPiZndDs8YnI+Jmd0O0F1dGhvcnMsJm5ic3A7 Q29udHJpYnV0b3JzLCZuYnNwO1dHLDxicj4mZ3Q7PGJyPiZndDtBcyZuYnNwO3BhcnQmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO3ByZXBhcmF0aW9uJm5ic3A7Zm9yJm5ic3A7V0cmbmJzcDtMQzo8YnI+ Jmd0Ozxicj4mZ3Q7QXJlJm5ic3A7eW91Jm5ic3A7YXdhcmUmbmJzcDtvZiZuYnNwO2FueSZuYnNw O0lQUiZuYnNwO3RoYXQmbmJzcDthcHBsaWVzJm5ic3A7dG8mbmJzcDtkcmFmdHMmbmJzcDtpZGVu dGlmaWVkJm5ic3A7YWJvdmU/PGJyPiZndDs8YnI+Jmd0O1BsZWFzZSZuYnNwO3N0YXRlJm5ic3A7 ZWl0aGVyOjxicj4mZ3Q7PGJyPiZndDsiTm8sJm5ic3A7SSdtJm5ic3A7bm90Jm5ic3A7YXdhcmUm bmJzcDtvZiZuYnNwO2FueSZuYnNwO0lQUiZuYnNwO3RoYXQmbmJzcDthcHBsaWVzJm5ic3A7dG8m bmJzcDt0aGlzJm5ic3A7ZHJhZnQiPGJyPiZndDtvcjxicj4mZ3Q7IlllcywmbmJzcDtJJ20mbmJz cDthd2FyZSZuYnNwO29mJm5ic3A7SVBSJm5ic3A7dGhhdCZuYnNwO2FwcGxpZXMmbmJzcDt0byZu YnNwO3RoaXMmbmJzcDtkcmFmdCI8YnI+Jmd0Ozxicj4mZ3Q7SWYmbmJzcDtzbywmbmJzcDtoYXMm bmJzcDt0aGlzJm5ic3A7SVBSJm5ic3A7YmVlbiZuYnNwO2Rpc2Nsb3NlZCZuYnNwO2luJm5ic3A7 Y29tcGxpYW5jZSZuYnNwO3dpdGgmbmJzcDtJRVRGJm5ic3A7SVBSJm5ic3A7cnVsZXMmbmJzcDso c2VlJm5ic3A7UkZDczxicj4mZ3Q7MzY2OSwmbmJzcDs1Mzc4Jm5ic3A7YW5kJm5ic3A7ODE3OSZu YnNwO2ZvciZuYnNwO21vcmUmbmJzcDtkZXRhaWxzKT88YnI+Jmd0Ozxicj4mZ3Q7SWYmbmJzcDt5 ZXMmbmJzcDt0byZuYnNwO3RoZSZuYnNwO2Fib3ZlLCZuYnNwO3BsZWFzZSZuYnNwO3N0YXRlJm5i c3A7ZWl0aGVyOjxicj4mZ3Q7PGJyPiZndDsiWWVzLCZuYnNwO3RoZSZuYnNwO0lQUiZuYnNwO2hh cyZuYnNwO2JlZW4mbmJzcDtkaXNjbG9zZWQmbmJzcDtpbiZuYnNwO2NvbXBsaWFuY2UmbmJzcDt3 aXRoJm5ic3A7SUVURiZuYnNwO0lQUiZuYnNwO3J1bGVzIjxicj4mZ3Q7b3I8YnI+Jmd0OyJObywm bmJzcDt0aGUmbmJzcDtJUFImbmJzcDtoYXMmbmJzcDtub3QmbmJzcDtiZWVuJm5ic3A7ZGlzY2xv c2VkIjxicj4mZ3Q7PGJyPiZndDtJZiZuYnNwO3lvdSZuYnNwO2Fuc3dlciZuYnNwO25vLCZuYnNw O3BsZWFzZSZuYnNwO3Byb3ZpZGUmbmJzcDthbnkmbmJzcDthZGRpdGlvbmFsJm5ic3A7ZGV0YWls cyZuYnNwO3lvdSZuYnNwO3RoaW5rJm5ic3A7YXBwcm9wcmlhdGUuPGJyPiZndDs8YnI+Jmd0O0lm Jm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7bGlzdGVkJm5ic3A7YXMmbmJzcDthJm5ic3A7ZG9jdW1l bnQmbmJzcDthdXRob3ImbmJzcDtvciZuYnNwO2NvbnRyaWJ1dG9yJm5ic3A7cGxlYXNlJm5ic3A7 YW5zd2VyJm5ic3A7dGhlJm5ic3A7YWJvdmU8YnI+Jmd0O2J5Jm5ic3A7cmVzcG9uZGluZyZuYnNw O3RvJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7cmVnYXJkbGVzcyZuYnNwO29mJm5ic3A7d2hl dGhlciZuYnNwO29yJm5ic3A7bm90Jm5ic3A7eW91Jm5ic3A7YXJlJm5ic3A7YXdhcmUmbmJzcDtv ZiZuYnNwO2FueTxicj4mZ3Q7cmVsZXZhbnQmbmJzcDtJUFIuJm5ic3A7VGhpcyZuYnNwO2RvY3Vt ZW50Jm5ic3A7d2lsbCZuYnNwO25vdCZuYnNwO2FkdmFuY2UmbmJzcDt0byZuYnNwO3RoZSZuYnNw O25leHQmbmJzcDtzdGFnZSZuYnNwO3VudGlsJm5ic3A7YSZuYnNwO3Jlc3BvbnNlPGJyPiZndDto YXMmbmJzcDtiZWVuJm5ic3A7cmVjZWl2ZWQmbmJzcDtmcm9tJm5ic3A7ZWFjaCZuYnNwO2F1dGhv ciZuYnNwO2FuZCZuYnNwO2xpc3RlZCZuYnNwO2NvbnRyaWJ1dG9yLiZuYnNwO05PVEU6Jm5ic3A7 VEhJUyZuYnNwO0FQUExJRVM8YnI+Jmd0O1RPJm5ic3A7QUxMJm5ic3A7T0YmbmJzcDtZT1UmbmJz cDtMSVNURUQmbmJzcDtJTiZuYnNwO1RISVMmbmJzcDtNRVNTQUdFJ1MmbmJzcDtUTyZuYnNwO0xJ TkVTLjxicj4mZ3Q7PGJyPiZndDtJZiZuYnNwO3lvdSZuYnNwO2FyZSZuYnNwO29uJm5ic3A7dGhl Jm5ic3A7V0cmbmJzcDtlbWFpbCZuYnNwO2xpc3QmbmJzcDtvciZuYnNwO2F0dGVuZCZuYnNwO1dH Jm5ic3A7bWVldGluZ3MmbmJzcDtidXQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtsaXN0ZWQmbmJz cDthcyZuYnNwO2FuPGJyPiZndDthdXRob3ImbmJzcDtvciZuYnNwO2NvbnRyaWJ1dG9yLCZuYnNw O3dlJm5ic3A7cmVtaW5kJm5ic3A7eW91Jm5ic3A7b2YmbmJzcDt5b3VyJm5ic3A7b2JsaWdhdGlv bnMmbmJzcDt1bmRlciZuYnNwO3RoZSZuYnNwO0lFVEYmbmJzcDtJUFImbmJzcDtydWxlczxicj4m Z3Q7d2hpY2gmbmJzcDtlbmNvdXJhZ2VzJm5ic3A7eW91Jm5ic3A7dG8mbmJzcDtub3RpZnkmbmJz cDt0aGUmbmJzcDtJRVRGJm5ic3A7aWYmbmJzcDt5b3UmbmJzcDthcmUmbmJzcDthd2FyZSZuYnNw O29mJm5ic3A7SVBSJm5ic3A7b2YmbmJzcDtvdGhlcnMmbmJzcDtvbiZuYnNwO2FuPGJyPiZndDtJ RVRGJm5ic3A7Y29udHJpYnV0aW9uLCZuYnNwO29yJm5ic3A7dG8mbmJzcDtyZWZyYWluJm5ic3A7 ZnJvbSZuYnNwO3BhcnRpY2lwYXRpbmcmbmJzcDtpbiZuYnNwO2FueSZuYnNwO2NvbnRyaWJ1dGlv biZuYnNwO29yPGJyPiZndDtkaXNjdXNzaW9uJm5ic3A7cmVsYXRlZCZuYnNwO3RvJm5ic3A7eW91 ciZuYnNwO3VuZGlzY2xvc2VkJm5ic3A7SVBSLiZuYnNwO0ZvciZuYnNwO21vcmUmbmJzcDtpbmZv cm1hdGlvbiwmbmJzcDtwbGVhc2UmbmJzcDtzZWUmbmJzcDt0aGU8YnI+Jmd0O1JGQ3MmbmJzcDts aXN0ZWQmbmJzcDthYm92ZSZuYnNwO2FuZDxicj4mZ3Q7aHR0cDovL3RyYWMudG9vbHMuaWV0Zi5v cmcvZ3JvdXAvaWVzZy90cmFjL3dpa2kvSW50ZWxsZWN0dWFsUHJvcGVydHkuPGJyPiZndDs8YnI+ Jmd0O1RoYW5rJm5ic3A7eW91LDxicj4mZ3Q7RGV0TmV0Jm5ic3A7V0cmbmJzcDtDaGFpcnM8YnI+ Jmd0Ozxicj4mZ3Q7UFMmbmJzcDtQbGVhc2UmbmJzcDtpbmNsdWRlJm5ic3A7YWxsJm5ic3A7bGlz dGVkJm5ic3A7aW4mbmJzcDt0aGUmbmJzcDtoZWFkZXJzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7 bWVzc2FnZSZuYnNwO2luJm5ic3A7eW91ciZuYnNwO3Jlc3BvbnNlLjxicj4mZ3Q7PGJyPjxicj48 L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj48cD48YnI+PC9wPiA8L2Rpdj4= --=====_003_next=====-- --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?MjQyNDJlNTYzN2FmNDI4ODkxYzRkYjczMWU3NzY1YWQuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <24242e5637af428891c4db731e7765ad> R0lGODlhcwAmAPcAAAAAAP///wCP1QCP1Pf7/vL5/QCP1gWR1gqT1gyU2AyU1w6V1xWY2BeZ2R6c 2iGd2iyi3C6j3TOl3Tqo3kWt4Emv4Uyw4U2x4lOz4ly35F645GO65WW75me85m6/53XC6IHH64XJ 64bK7IzM7I/N7JXQ7ZfR7pnS7pzT7p3U76PW8KPW76XX8K7b8bDc8rff87vh9Lzh9L7i9cnn9tLr +Nnu+eDx+uf0++n1++33/PD4/PT6/fj8/gKQ1AWR1QeS1QiT1QmT1g+W1xCW1xOX1xia2Bub2Ryb 2R+d2SCd2SKe2iSf2iag2ymh2yqh2yui3DSm3Tio3Typ3j2q3j6q3kCr30Os30eu4Euw4U6x4U+y 4k+y4VGz4lCy4Va141W04li241q341245F+55GW75Ga85Wm95mi95Gq+5Wu+5m2/5m/A53HB6HDA 53HB5nLB53PC53XC53bD53nE6HvF6X3G6X/H6YHI6oHI6YLI6oLI6YbK64TJ6YnL64rM64zM65HP 7JPQ7ZbR7ZrT7qXX76bY8KfY76jZ8Kra8azb8a/c8bDc8bHd8rLd8rXe8rXe8bjg87zi9Lzh873i 88Dj9MPl9cXm9cfm9cnn9c3p9s/q987p9tHr99Lr99Xt+Nbt+Nrv+d/x+eDx+eX0++Tz+u/4/OHy +ePz+ur2+/b7/fr9/vz+/v7//////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAAK0ALAAAAABzACYA Rwj/AAMIHEiwoMGDCBMqXMiwoUOGiti0mUhxopcBAgZoHKAglcATFaVg3DgAC0U2hgKsKkJyiZqK FUV4bHijx4AHDFmN0BiJ4A2NRFYRJKAAo6WFKzJibOCQEclMB1WxxOgDUQEeqbKm2sEDoQaMhAqS sonE4B2MeQ7WmGlwj0YKCv0oHeDkIUGnAvJCNShVowA7dgXyyXKhsGEJG6kYNqxFUEImGSsQDJFR gOSClUj61cx5wAmEBKJk9JIwTefTaxzaGNnQxhIBex0WAUPwRZoOZnLr3q27Q6CBKXgL742mhUBW e3AP771HlcNSaDjQCVwwByQc1A2+9vtbodONsQn2/8UI2O6F03lP+/1QcEpeJgMbabwyMEzeOQuJ bBSAyC5ejeENNN5GQzBAxIEHNgAGAQZ9JQAlBvUggBIGlYDWQBtYoKGGW1yw4YZacPGhBVjsIRAB B4xEV3YCfZdRgAKNJ0ATLBo01gBlOXSIARgpohAEeQkgSo1EFmnkkUgmqeSSCKkxl3qaMRUBZ5V1 llcHAaQ40lxP+uXQWALkmB0HGplhECYHWADDQ24oJYAVClHilwCgRMVSXiYGhgIZG/TZZxlXaNTD F2X4+adxA+Fg0wBkEGTfACkQhNgAKzR0iop0MvQdgHZu5EdgXw0AYUE2UViQhQKkVdAcQZYSAA9D GP/xxQ4B1KHRFg1h4OYYDzHiJowBDKgiSZXlSZAGeYVFEJhiDnRHXnoM5EOXxO7HmQMGdRJkRtj5 txmwMqoRWBZPplftuXEkxIUJBj2CxUJSVPkGi5sOAO5UA6hqJCql2sVKEBilcRCyAxhQB0GFqEet X3IglAhJlxzEAwPoaSaABV+S1VAmQ+RlREOTBHkGkySXbPLJKKes8sosC6TJllCS9JshC8NsbSUB eFAzZ244FIpSNfrRxADsGoRKQS/ETCWWIShspSMBUGyteu82dGOzCr3AR0EyaESFQU4OAJdDcBC7 SEJjuJmuQTzg+0SSNmG7ECuQDZBAQUlo9AlBg2D/BMVDm2wpQA4KOUISJ53mpa9DJVRmLkZcUgv1 QDRjRMNAI2SUmkAzYDSEcw3xMVcEmj7VqUblPSRGRl2ooMIKK6hAh0Y/kMBC7K9PkBceBeGwUaUB gLKRc/xqZIpD7vkFR0Obwna6AGiAqlEhBY1iUxIG5YFRtAZh1IYOAh090AIY9cRQAUBALsBRzM91 734CICDEAvQvoMAQGNBaELICKDvQ1Wa5kEBi4IJGNMITmTCgAhvhgg8o5QsvMKALcHaQSKRHAAro SlO+ZafHQQ5mAuhDg8AiFo0VBAQCDAAIMWWuKlWGKQZJg5vg5C2/vI92LujKKna4CtAdRAwa8QIL 7YY4xLPErwREHGIVMMI7km0nL4CgjovsdboBiNAumbPYsKpkLUQZRAZ5+dtAOrEAAXwtITjgkiey U68bDiB1RSKARo4QmEOkR3wDOUNlMnCQQrgJPvQyHV+KUCwkAfAhYMjLD4RyECxUJhEESeRmBCAB mMCkBAlpnhsHwAQPWHIifWCQ1UzIEFAEqQsLwQEQ8gIBgWiBS0qbI0JeMJcaHGQV04plXr6kEbkp hBVTEkAPjtcQOWSEVwGQxBw+wMxmOvOZHxiEQnIAgj1o8JZ/gKY2SeDDhejgDW1YnEI+AUm7fIKR LUunOtfJThYFBAA7 --=====_002_next===== Content-Type: image/jpeg; name="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Disposition: inline; filename="=?UTF-8?B?OWFlM2UyMTRjMTdkNDllZDkzNWQ4N2M2NzRiYTNlZTIuanBn?=" Content-Transfer-Encoding: base64 Content-ID: <9ae3e214c17d49ed935d87c674ba3ee2> R0lGODlhggB4AHcAACH/C05FVFNDQVBFMi4wAwEAAAAh+QQICgAAACwAAAAAggB4AIcATr79vg2j x+twuSDo8tdNjNSk0mTQ57AojVB4uI7+1GPI3/P+6rKPxan9yjsBes4/gtD+34y61u9jm9rr9vva 7Pek0aolccv///8Baccki9Sj0FwSfM6DtOOAv2Wy1e9Mo92axurf78n9xisLacf+2XNwpN33+vE7 m9r9zkv+89Q0jNWMvebh7/nL5KPR5vbC3vP+5Jxks+NbpN10u+UDg9Gqzuyi0YLx9+aTvuYkhNF/ wDbZ7L0cjNQAdccAZMUlkta73Y0Ybsn+z1CUyk5LnNpiqd88k9f9whz+3YNNqt9EnNr0+/18vOaF weczm9oBjNQae879xzK426PV7fjc8vqIxCek0u79zEP+5qR8r+Cd0u5ss+O84vT+8Mlbqd8Le87M 6fdTnNrl8dMrg9G22e8BXcMKdMsrdcyUyuuMy+xtqd+s1vAsktb+9t3+1muy2Hqs1XTt+f1xsdvE 4/X9012BwQ3u9uIwjelDkteKxTTW6rr+23tTo939xCNEo91ro92DvPd7wOcchNKEwoQ8jNRtvOZN ltg8o90sm9qIvui02YOm0/kri9QLgM/m+f1dseIUg9EMjNQOZsZUqd8NW8I0k9cSdMv+4ZObzOwk fM/H6ff+6Ku24PN1wunV8frz+esyhNHN5quDvOZcnNrU6vczeM2bzVpxr+y/35R7viO73PLb7cOn 0mz++OTE4Z2s2vHj8/oSbsphpN6TyTwAbMmU0O6r05rb7vn9wRTN7PlDi9Ti8M1Dltj+7LvT6LRK ktaTxene+Pw3od2EyetbrOHL5fV0reAse86d2PF6vSlzteMCk9am2PEtldigz/Eckdaz1/Gt1IW6 3IRjreGz3PkBVMBNseEzltg8mOH9yC9sreFVrOBSltgcdMs9ltgkldmKwOdhueUeftAAddCMw+mB v+kNbcnn89ir0+6jzex6tOP90E/q9NyVyPBEqd7R56+k0nH9yTSz2/ILftB8w+mAvyP92G390VQK hNEBdMuEw+kAfdARftD+/v7///8I/wAxCBxIsKDBgwgTKlzIsKHDhxAJMimHAgaGckvoYNgHgg6T JktKMaFRpBSGZSBKyeECogIFLn1iYeDyxSW1LxRiFeMmh8kXarGq9KHGBNdPDLH6cImFC8QyDC9A 0MBABUQTJsaWNMFAZ8koDFn3MemyJBiGVX/SYJiHItNaFFsiLkwH4goTarXSYZihjw2GPvrSyQFx xiMKfRaPgFkV69slY7Es0aOCoVEkY1UaaYpValAkCnIG6SjVeQUFY5E0FAXTBtcmDnmYrHrwhKu+ IhTmnenDJJ0+EBg+1OJ9pdY2DMH0ycCQptayibW+ZvozT67BJrW4gFXXgusVmXS+c/9NR+HslfKr 0slMT0E2GyZr2bRf9YEJkw/RBKaLZj/aKgwUpFNdb/MwIUc6FgX4HwVX/BcLgkhd0QVS6mgUiw3G YICLOhnickWGpahTwUw1uGXdWcGU8kIaGp3o4oswMsSEEpKsUkoT1UVUzAMmxujjjz5SoUMtsFzx ADVyZfLFf0A26eRDxswTxhrArGJME/lBSUd5T3YZC3xdFtSUDuowBSYT8zC5EBMgaGBRmE3OM0sw XMKJQRP6RAemQKvkg8KeCTExgyUt2hkjE1xY0wguhlLRiD5PbFJQVto1xMSXhv54BQo01NnlRA/w eJB9Db3gUaY/XiqHobGAoI8zlBn/REEzOSokxiVZogrjKtzs4+mTqP0gw6oGrXJJHgzRgEKhup6I aAYrjAhnUhr4dVApXJi1UE6ANisXBcXU0kascFYhUqDdHmTMKr96CxEFkOiTCLldzgPJFQnFkkmu CYnhDb+6VlFPPYw6RMEXPzRi0kNXGMKsQhQYYY0l7fKpzxEMdSDGw6iyUUsGejnERDBkzCKTQ1UU Ys1xlqpDilgIlbJNOO5CtMouBXQRS8UHUdAJvQvF8skxppQD0SbEvkhHNDzbyUQYYawyAw0nF8QE FfPYUh0uIaRT1BZX0FF1QVfMEIwuW4q8yhqZpCtQLGlYq9Af+nxQ80Cj/KAP1QRV/wELSJHoA4S+ ZuiAyyj6PIANNVvoAmgzGphxBNBBI+zM2AStoo8lDIHEcbPzAFHLA50KVMoMD+SpzyW94ALDEUux EMUZqrehzkDz9FALGII0fVAslECK+UAVcGH03RGFro8+acQixxWa/NDDH4bYIilSq8YCSz3XgHPG D7MwQUEYooPBN0SxcKMPIr43tG77mc7TRiQg9EJDGKNQM0/SCDGhiyfcSFMf3gGNSPROLunTxzCG 97Z9MaQIl5Ab8qgShmVUQgfGIJVAVBCDJCShBAp4Ax8w4QWB2IcC67CGBmBxLgSqLxEMxEAZZIGs hYyiDxmaoOmoYIxllKNOWVCAA//8II8I4CMXSPADEkZQB04MZBViaB4V3MYQnfzAEjGsQBN6FCj4 xa8NjdgfmHyhgBH4YQQjkEcS+CCPETjAAW1EAj5KiJRYUIMM++DfQ9jQh2BQEQN/JAgd2BDDgP1h dLDYIB+kQEQ4ysMBUsBHDCJQhwjEoAR1SGMWTHiEH0Qikdapgh77tg98LaQIZ7Ab8iayPBnIxBUx wAIS5IEFB9QhCW9QQAmScA985DIFSYhAEmMgEHVEIgMgqEJEmHCFOVFRc5xbCAtmkcO7GaMNtYCV QDiByzfIEguYiEEddukANyoRCxHIAj4CMIJNMgESZwCDWt7VB2tgg2e4WAcXdZj/EDnsI3H7EIg6 bRmDN+AjAkI8IxbQSMs68OGhJXBAABzgBq4AIQN/oJxCZKPPQDZkFeK5G/B+0BoMeCEFSpRHCdLJ h1yMAB/4wEIJMBnOOsgDH5gogTxu6YqZZOCTEYmFRgcSi2CETCGHAeXd2ACCeSbBD1gYgjzkoYAy yuMenKCkF2KQgqrKAwkO4IMHIzACJ9JBDFxQ5kN00gs1GWQetYimQpoAgmq6KxZhUCsGFIAEEQ7x jG/AxBvekAIHYKKMSXRAYV+ahSTkogRvo0IVPEoQWOgjAzA7SPGOx0+FLIMDAcWAG/CBBD5koQ4p wIcCJimPRmKBD5eEIxZSIA8p/2BCmCmoaFZK4hCd1CISbjUIZcEyDy++qCcCkQMFllsFQFSCNwLh KxYGiwlOvAGODsBCLUeggDXyAR+0dAA7kmDVEqphEqaIhnJBAx8DYaAKm5AJBfZRA31Q4o8tCIYp bSWL2xlDHYxhQgX2EwtMuYgOf5ABBeighCcg4gnFUMcHCoWJJNIyBQ+VrXa164BcpCALb3CjTOvw RnkwAAO6SEMImoCIPyBiGGlgQibqwgXQrmR5PajVQVZBQ48GgxppuFIPuNEJY2QCGyCYxxWkdaIQ mOEMpQiBLDKgD73JQBgFeQMStjzR645gwxzuawzwoQ3tFvaN2tgkIGFBBr3V4v8HRfgEKczQhyWY YRmxEIMZejDPhFRgFLdb03rDAIstUQAX89CZgU9kjBlw4TTUWEIfvoCCfPRCx67IAghDSFgzErG1 KvUFJ1Lw5Vpmt5ybjMUyNJCIGdS5CJmQgzrEIKFyZGgV4VjFcD+aCeO6aGeRxUUskuGIWoSWIK5I thtU4AVu4mMEKSjBG9aYhDoQccMOWKIvuDIkQzCFCrho72QBOZDhtqAc+03IEs4QXF3RQQP6qIdD VJBV8mIBqhHgQznTmIKuVnQVjyJGkzSHAob82CP20WCmuqCBB8j7ISpAqRTayAdOhLAE+BArJgQC i4YLHEi42GJvq0ByybrbEvr/EEdEMHHGwmJBtZY0aApOjAE15AMMcanZKtJQigL7XFe4KMIPnlBI hPAhsQ7QhmIXGgAFDEQGP9CBjmN0uEAjVR/tRhUT1iGLPvhaIK7ggxmnasYA5KIOPRXIMkhQBL36 aB76+AZDylGMFyAvDPuYkHWCiIWpyoMdmEi7QIxhiHT7CBfm2Gf/9rRrH9knFlfw2omanQUGVLTc Si66ixSeEBikQWck/8S4DRXyfYTjHOMIg5OoEApjN94hVWeIGM7RNjkERfM+ioUMaqGDYjQCBbgP KggeIIkkD/xYDEkDFxamq1hA4gG1QAFkwkCHguXeGB7SQcIM/6JYqOGo6HLX/zpqUYsn6F0dOgBB 8BlysEbgKxxgEJdSdcWGclgfVZCoBTb0zoRRUPkqMbIPD/ADT0EBTQAGP3AEqhcjpbAMfZYQvVAL bRMUogcjuJAGnrAP+1APnjCBTfB5W6B3g4cNv5UGo2cdbDAI4sIkBsgBS+B2LgJXbcAQmXAMdGB7 VVCBCNQE1OAh8RcqeRIFXZAJP8ABzEcQufMAPQAC+mMdq+AM+pAP6TYrSrYN3BcR52Z1mRIGZ2AG mUAHRxAFGjCGUZAHhIYMCogQ9SAJoVJ+n6MQuLAEP0A66SIHS2ANS/B6LhINmbB+MTMPxrANVYIB m5AMsDAPsNAMGcIEzdAFVP/UBT1QA8xQAw/AWQ5RAUPiSj0zCrvAAnooJoDGECiQFy7SFP2QBnLw CJ84EMbQcFBQAzWgLQ0RC11AB2lwPqPyCauYObWAMQuRBpSwP0FRBX7IBP+UAQD4IojCAanTB0e4 EOWwG7sYERWwDzm3EDhIcroAg3B4GM6wgDAyXwn2jBs1CpWwAn4II5yHEPPQhyfSJw43jcJFVJgi B2pFASRXBbhAB13QBegGdB/IEIcgCwDzEFvwADUwfz8SC/vwBG3QNk0ABAXCBeCQCE/wBIPAAU4g j8lzDrGxEJmwDCZhe6vyeO1BRSMzOlMXI1XADWCQAT9ADVUADNZQDrHQCHr/szx6Yw7eoi+qtCZ0 0AlNYAlcUItXUARfMA/NwI0CMQ+RoE1N0gSpowFGoGuZAAgekQkz8AWGQAM04I6dZRDpsA/zUAXp sAyZIFl0MAq2ljajQgfkCCMVMIpPAAsncykmVGCgMUqZggvLIIvq1hcmxHgeFQtbIBhNEgYaQIDu sgevMAagwAup8As4gAOvkApjcAJj4AINQA7ZQINNEJcNoQ4/cAlZ5yIvcWnNcgKsEAcGIAKgsAdx 8Art0A5BAAesAAqsMA23EAwF6SSrUADdYHdNUgVhEAxr8B7pQAMDUw800AQZpA7Q+SKg8Au/wAt7 wAongAGg0A53IBB30A6g/8Cd7YADDpEOihAGBqJcfJkQxNglcpAHACADVXAEZrA8efIDo1AKoWAG AbWLr0AEogARVPCXDLEEtYCKOagLuthbadBrT9J/efAd20AGbXChjRAK6oALgFAIWzAPowCOEJEK qTCeD6EbNaQQ6nA/gMSeD5EJu3Oa6khUdFCj/Kie7yVUnTQVETEGvIBAaQB+geIsaaAPNSBBubcF LEJZYYBNxRARd+ACY2AdyDUX4XB/EJEJD5APK3lcMpAP+jAIlsiOPaAPlfIQonAKIiAXFbANY3oQ h3AOppRwL7qlXeoiVzAI/AAFm2NXBoEL8RIJircQe5AK7SAXq+CRDPEBNP9Qlgt6giCJkHd6IvtA D5L4AGE0V3lCCV+HAeFpHQ8ioxKxni7qEM2hDwoJI/PgijXQAzKQCUwpKGagASL4EHeQmXCSCTTA ZBFBB70gBrx6KGkwCOujBBwQBYjgCVtglzUHAgA2CqnaEL+wCFMaEaXwBV+xECQopBChC0OljDRg CQ3SCBlQC/oQCZqwDlWAAgAwA+3ZEC4QB9UKEXAnVwlxBSyApQ9BBTRgk0+CV/DRBSShA9DXdplA CuowjWPAAyaKPg7UEPZIjEHxrgWRCWZQC2/SJPi4J1ijBp6QI6pInQ3bJekwCl2Qg6JHBesHA2Iw A6L5IqNQCFr4JLzwCyP/6xAywwIMEYES9HrC8Ahdsg7IEAJ28gqtMK8PsQpnkKL3SjAncjh08q9U 0KkRcQBBcKhBdQWTKhEuAqOL8SSHxpEL0Q5I+y6UdQU0cIPD6IdFWgNbS6ng8Ax2wgoEYB3Xmq0K cQgkUHsk54dayqVPQgP54A5wkgpxgLXJcwa94FHpEAz66hB/+7Zy0Q434AFTcLM/0g6t8AonQgET 5jRpsKXV0CRjcApWYAWqEAeYS53YqZ2Gonzf+ou14AMWwAPfiQ6ikJu6eQDtcAJ3cAC5yZoHMKV3 8At7gAOgMAa/YAD2oAdEMAA7AA/tIAqQ+bt7MJ4iMLyeygPHiwFjIAo//xqblIkBv7ABQfCdLlIK lLAVC4GgtXd7+4oKcyANuBmbrXC17ZAKrZCbrHC/Y3AHrxAHooADrAAH1Dq9cKAHVkALp7ADypAK PNAKv9AOBTwNvADAAnwHIrAIi3DBomAALnCrixAHF2y1ZYuoDyB3CzEP5aC2OciU/RQLY8AK33kH PMALJxCZNOyprMALoJC8rHCod8AKsHkC7SACcKAMqkALqrADv2DDvYsDIsALOKCZQXwCBFzE7cAD vQsKIsAKVby635IOomo1dPoQL3AM65CODNEO8aAKdmAFiyDGYfmLInkiFlsLZTy5hIAACUDHE/QC s4C3gfmb7sMNS/EkjP+AB4FQxwVhLMDAEPUnEnJAkhDxCWxsMLhAsRNEAYUmIxT4CZ+wjVAyFJns EDDwAVSbKcvFECGwfIPZeGmQAWcguaG0C8jwhhNkDH9wpgkRp4acfEZqy9+yDD3oyHyytAyxCltw yhgQuWGyXLiQDi9bMwtGnOznOplQlhRABftBclQEzXASDEJwDMjsEOUAZHRgCJJwDfNgi+CACGyw BY/LBG0brUASDWLgFsLWWcZQBE+xEIeRBgumNcRYCsuKC6XAM5lAZXusjF9iDIVgBKu8wpAgA7Y8 G9jAENEQDM6saniGKsYQCjixClzgIGLzXl1QHlVwgxqSNvsIHzGNFFv/gA2hsgLVwUOmcyphkEEU wAYP/Wtd4Di6wgRwiQE0kAFfwQJkcDssgAx20QRkIAEnQQZ2sw6hoGt3lCGjwIyvaKYUsA2FMCJ9 UAjGIAeksAt2N1zBsA3YDBHBEAUzUNEvYtIawQIaigE5AAFeMwpTjQFYbTcdAAGrIAfbEApcHQUP 8IoPsAxhPdZ7kQcvIAcTAAyk0QfrIJDnQNUQYSAsMAmNELuZEgu6UB4UcC54lT1ThBRELVTtVdPL YwnVQdoCUQWrLcoYsAChMAMM0Y4Su1zOY0LEcik5QQflUCFq0AznfCLzQAkB1BC5ocsEoS/FUAwy IAPFwAVhQAHlwAUt/zARXyAD3AAEPxAFxLzcDNgH7KsQbPAH8bc80HcOTaALmmAG6RAGoZCT+nAG 0ofeqAIDUVAEDFEMZ9AGKJAIFgkNzqAebbIl3KDgT0AJmfC4/h2hdCCiCAFSKpuPuDBuTPE2uCBs dF3hEVGlMiK2JO4kuDALBVDNAxEMRzCzKa5DcTgIfooQTcABDzjj/LQuw1UBZWniPF4zsVAOo9Cp HOqJQ343jgIG0r1jF9ANJbnkWkcHkJEGTsDG+lJcmTAKMlFgtX0y75mjYS4Q/cwEY37mai4TRVEe V1MecoALbj61gLTah2badm7n4QYg49bN8BG2SLHnHx7oGFABK/CCMP9CBYWABmEQCzMw14JiBAU2 C8eBC0rBBC3QB45dCkWQ2f+c2Zx+Ff/8FavgFVyxBOUgG73gFmywBEQ7D9/QNumQB3qRCb1wO+rw Dfhi6/8RDL2QH8GwBAVSDr3A1d9gEaOwBDDQf0UQbtvwDS/QAt0wAxT+EBSQCUaDC2QQCrHwCBBQ CKWACxBQAFgxCLFRCqZwCLFAB8gwAWfhDWLAFWgw16uABoCAAVfgDfcuARewDc9zAR2AASHgDZmt Dt5wFSFwAWYxCt6gszngDak+ChcgABhwDN5wO1pw8UxwDGjwHzPgDVRtAt7gNYBgCgvABGIwDv9h e00yFqdSo/ZRo4BJVIsC0QUZNBaqRwFdoHo4DyCdYBKxYCM+Txk+A/TzQBmxMA+MkvQyUQVKjxTz 0PRRTxU6oyGdIBNYsyphUFxUXx6lwPWusYsBAQA7 --=====_002_next=====-- --=====_001_next=====-- From nobody Fri Feb 23 09:44:48 2018 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 A1BDB12008A; Fri, 23 Feb 2018 09:44:41 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: detnet@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151940788161.24159.11091964805464850486@ietfa.amsl.com> Date: Fri, 23 Feb 2018 09:44:41 -0800 Archived-At: Subject: [Detnet] I-D Action: draft-ietf-detnet-use-cases-14.txt X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 23 Feb 2018 17:44:42 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Deterministic Networking WG of the IETF. Title : Deterministic Networking Use Cases Author : Ethan Grossman Filename : draft-ietf-detnet-use-cases-14.txt Pages : 88 Date : 2018-02-23 Abstract: This draft documents requirements in several diverse industries to establish multi-hop paths for characterized flows with deterministic properties. In this context deterministic implies that streams can be established which provide guaranteed bandwidth and latency which can be established from either a Layer 2 or Layer 3 (IP) interface, and which can co-exist on an IP network with best-effort traffic. Additional requirements include optional redundant paths, very high reliability paths, time synchronization, and clock distribution. Industries considered include professional audio, electrical utilities, building automation systems, wireless for industrial, cellular radio, industrial machine-to-machine, mining, private blockchain, and network slicing. For each case, this document will identify the application, identify representative solutions used today, and the improvements IETF DetNet solutions may enable. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-detnet-use-cases/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-detnet-use-cases-14 https://datatracker.ietf.org/doc/html/draft-ietf-detnet-use-cases-14 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-detnet-use-cases-14 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 Sun Feb 25 18:56:26 2018 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 F06C8127275 for ; Sun, 25 Feb 2018 18:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 ZBFaCD2BGTrd for ; Sun, 25 Feb 2018 18:56:23 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 911C8120713 for ; Sun, 25 Feb 2018 18:56:23 -0800 (PST) Received: from cmgw2 (unknown [10.0.90.83]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 7AA2E175B04 for ; Sun, 25 Feb 2018 19:56:20 -0700 (MST) Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id FEwG1x00J2SSUrH01EwKBo; Sun, 25 Feb 2018 19:56:20 -0700 X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=BNPbgmet5s7P3IGJxxAA:9 a=QEXdDO2ut3YA:10 a=LSdyffb0k1MA:10 a=w1C3t2QeGrPiZgrLijVG:22 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:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ZTtmrbXMLbwXG3hpf5mMCjHwq/8rJwkteHDGvKqW75M=; b=HOH7/uYIn0Dk8jGoAXHvaTcbhJ HZsgh3lxRR5euk8BF0pi6aYS+7IpEwrs5sy4rhgo9v/u8N1mTuAZ2W8lc4P+9WlxX9JxLhFqwZaXn 4vCH/kTCZ7LX4HSNuePm7HCqb; Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:60258 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eq8xc-001rwG-DG; Sun, 25 Feb 2018 19:56:16 -0700 From: Lou Berger To: DetNet WG Cc: DetNet Chairs Message-ID: <59e5d0a9-f635-2900-114f-d0376f4a8699@labn.net> Date: Sun, 25 Feb 2018 21:56:14 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.86.101 X-Exim-ID: 1eq8xc-001rwG-DG X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:60258 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: [Detnet] IETF 101 -- Extended meeting and Slot Requests X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 26 Feb 2018 02:56:25 -0000 Hi, The IETF agenda has been posted:     https://datatracker.ietf.org/meeting/101/agenda.html We're scheduled to meet: FRIDAY, March 23, 2018    0930-1130  Morning Session I   1150-1430  Afternoon Session I The first session will start out as a fairly typical work group meeting.  Please send any slot requests to the chairs alias (see above) no later than March 5th.  Please include draft names(s), presenter and desired slot length.  Keep in mind priority is given to WG drafts and other drafts/topics discussed on the mailing list. As has been discussed in on the list and past interims, during the remaining (extended) time we will be focused on discussing and resolving data plane open issues.  Please let us know know if you have material to review during this part of the session. Please note the second session ends at 1430 which is 1:10 beyond the normal end time Also don't forget the draft cutoff date, see https://datatracker.ietf.org/meeting/important-dates/ Cheers, From nobody Tue Feb 27 15:19:49 2018 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 C0FE312E8E8; Tue, 27 Feb 2018 15:11:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: detnet@ietf.org, db3546@att.com X-Test-IDTracker: no X-IETF-IDTracker: 6.73.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151977308578.5200.10108835432324788465.idtracker@ietfa.amsl.com> Date: Tue, 27 Feb 2018 15:11:25 -0800 Archived-At: Subject: [Detnet] detnet - Requested sessions have been scheduled for IETF 101 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.22 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, 27 Feb 2018 23:11:27 -0000 Dear Lou Berger, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. detnet Session 1 (1:30:00) Friday, Afternoon Session I 1150-1320 Room Name: Blenheim size: 200 --------------------------------------------- detnet Session 2 (2:30:00) Friday, Morning Session I 0930-1130 Room Name: Blenheim size: 200 --------------------------------------------- Special Note: 1150 - 1430 Request Information: --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 2 Length of Session(s): 1.5 Hours, 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: pce teas ccamp netmod mpls Second Priority: rtgwg nvo3 tsvwg pals bess People who must be present: Lou Berger Deborah Brungard Jouni Korhonen Patricia Thaler Janos Farkas Resources Requested: Special Requests: Please schedule the longer session 2nd - Friday *is* acceptable. ---------------------------------------------------------