From nobody Wed Jan 4 09:41:23 2017 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 F26A312969C; Wed, 4 Jan 2017 09:41:21 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148355168198.12949.16123724019108199484.idtracker@ietfa.amsl.com> Date: Wed, 04 Jan 2017 09:41:21 -0800 Archived-At: Cc: detnet@ietf.org, lberger@labn.net, db3546@att.com, detnet-chairs@ietf.org Subject: [Detnet] detnet - New Meeting Session Request for IETF 98 X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 17:41:22 -0000 A new meeting session request has just been submitted by Lou Berger, a Chair of the detnet working group. --------------------------------------------------------- Working Group Name: Deterministic Networking Area Name: Routing Area Session Requester: Lou Berger Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmm dime pce teas ccamp netmod mpls Second Priority: rtgwg nvo3 tsvwg pals bess Third Priority: aqm bier 6tisch Special Requests: --------------------------------------------------------- From nobody Wed Jan 4 11:54:21 2017 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 35C18129415 for ; Wed, 4 Jan 2017 11:54:19 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MekMET_amozV for ; Wed, 4 Jan 2017 11:54:17 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 5D9DF1293FE for ; Wed, 4 Jan 2017 11:54:17 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id u144so93133081wmu.0 for ; Wed, 04 Jan 2017 11:54:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=rhxk3A9Y/caEILAIZboeP3Ns5Tbp6HzPVGgvxLiA51M=; b=GfN2yZO+K4hcDxkgCuA+9wr85/LeEPFMVZaHu8V5gE18ZCMKRgrhIQj8o0eaBMVcgC Gm7rn4gDc+4up2/G2lc8KCIdeqm4i2pUUQsHvpM7vvPIFX+A+hJ4FTna8aceaCLaRDaZ fiErs9dvhTOvKdp1gWB6zSCKA4ri9zkeznn+u1P5MyFEOP0CWFB1ZeM+/bpapILNWUGG kydpOyeTxUEQI6Ft3pjAiP7ltPpYHYjxBObSSkkT2TyJK96YNMLRV0Mk+YW3QQWMBhHM wtUWIPlGn7/baGD8rdA1eMvH19667nQGwWCODTvWEmj+cKSeIv6t2JjZAofHlD10oSHy lKlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=rhxk3A9Y/caEILAIZboeP3Ns5Tbp6HzPVGgvxLiA51M=; b=MvXZd+tJo+YvWIS6/fw+5scS54Yp1GFxhy1Up9xBNSX6XDtXDpEtcHVPA3qDjOD/Zq wGNDiMd+EpmJMROcT6pqVdLPBt9yyfrefkNiNnuzx4kFDLQGAwXf4qeJ65tnS8u7XRn5 8GordRTUybFZxEUCGeVg9z/GGswRxqI8URU5ROtnCI59muueff5TKwQLyNhR5JYyIGve dhkxrEuExqAVOfhPKpuXsswHLVslXTZkxH4TDYv3AJcgpd+UxSZ5cCq3p1zNecWL0YIJ PBBNmRiejitPu1ihHP9BmeQ+QedGNy7uIkPSBLgRwzSTRoS6g4pKuQk9kucA8+35r4uE LRlA== X-Gm-Message-State: AIkVDXL9nffAszPG89DH3K/r7JoXlDBdSjbocS3OxDZGgNTDGXxwKDZfNGbf0/Oa4gH3+g== X-Received: by 10.28.143.68 with SMTP id r65mr60680184wmd.95.1483559655837; Wed, 04 Jan 2017 11:54:15 -0800 (PST) Received: from [192.168.0.11] (host109-148-112-20.range109-148.btcentralplus.com. [109.148.112.20]) by smtp.gmail.com with ESMTPSA id g184sm96437145wme.23.2017.01.04.11.54.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 11:54:14 -0800 (PST) From: John Dowdell Content-Type: multipart/alternative; boundary="Apple-Mail=_2EE25FC2-3E8A-4F78-9C75-25192A612093" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <5C00A58A-AED7-4306-B5ED-DA9663C417B5@gmail.com> Date: Wed, 4 Jan 2017 19:54:13 +0000 To: Kathleen.Moriarty.ietf@gmail.com, stephen.farrell@cs.tcd.ie X-Mailer: Apple Mail (2.3259) Archived-At: Cc: detnet@ietf.org Subject: [Detnet] Network security - purely technical? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 19:54:19 -0000 --Apple-Mail=_2EE25FC2-3E8A-4F78-9C75-25192A612093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Dear Sec ADs We in detnet are engaging in writing security-related text in our = drafts. As is normal, much is being or has been written about technical = methods of subverting the operation of detnets. I wonder if it is also time, given the uses to which detnets will be put = (factory and continuous process control, live entertainment and power = grid control to name but a few), that readers of security-related RFCs = should also be encouraged to consider the business cases of choosing to = mitigate against a set of threats or not. An extreme view may be that = the finance community in a particular organisation see such mitigation = as unaffordable, until that is the worst happens and the cost of = implementing the security pales into insignificance against the impact = not only to the organisations operations but to the reputation of their = brand. It is this reputational damage that I brought up at the detnet session = at IETF 97; a reputation can take years to build up, but can be torn = down so very quickly as the news, correct or otherwise, gets out. I = wondered if it would help the community who have to propose the = mitigation for security threats to have some appropriate guidelines or = advice to understand the potential business impact, so that they can = better build their case when applying for funds to design and build out = their detnet. I=E2=80=99m acutely aware that the IETF is a technical organisation, but = do you think there is a place for some guidelines that are mostly = already in the public domain, just not our public domain? Regards John --Apple-Mail=_2EE25FC2-3E8A-4F78-9C75-25192A612093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Dear Sec ADs

We in detnet are engaging in writing security-related text in = our drafts. As is normal, much is being or has been written about = technical methods of subverting the operation of detnets.

I wonder if it is also = time, given the uses to which detnets will be put (factory and = continuous process control, live entertainment and power grid control to = name but a few), that readers of security-related RFCs should also be = encouraged to consider the business cases of choosing to mitigate = against a set of threats or not. An extreme view may be that the finance = community in a particular organisation see such mitigation as = unaffordable, until that is the worst happens and the cost of = implementing the security pales into insignificance against the impact = not only to the organisations operations but to the reputation of their = brand.

It is = this reputational damage that I brought up at the detnet session at IETF = 97; a reputation can take years to build up, but can be torn down so = very quickly as the news, correct or otherwise, gets out. I wondered if = it would help the community who have to propose the mitigation for = security threats to have some appropriate guidelines or advice to = understand the potential business impact, so that they can better build = their case when applying for funds to design and build out their = detnet.

I=E2=80=99= m acutely aware that the IETF is a technical organisation, but do you = think there is a place for some guidelines that are mostly already in = the public domain, just not our public domain?

Regards
John




= --Apple-Mail=_2EE25FC2-3E8A-4F78-9C75-25192A612093-- From nobody Sun Jan 8 04:07:12 2017 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 962D7128E19 for ; Sun, 8 Jan 2017 04:07:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.8 X-Spam-Level: X-Spam-Status: No, score=-4.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 rrmDtRWHGVvx for ; Sun, 8 Jan 2017 04:07:08 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8C26127735 for ; Sun, 8 Jan 2017 04:07:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A0376BE3E; Sun, 8 Jan 2017 12:07:05 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g6WlrccSzgt9; Sun, 8 Jan 2017 12:07:04 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DB6ECBE39; Sun, 8 Jan 2017 12:07:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483877224; bh=9sSyBV6NkjZjB/jlO3e+DbfD2JvA17pRK9IXPUQLfao=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=q9NBVw3cwmga5GWxUYw54DwjJ21V3qOJLfDqP+ES2iyr5Li0ngpB0aRuDHuEEZIru EbTXvoFEVu9/yX+SpUQql72XZqERS3Nc471CDJlmwWfGNiETIf8YHC2Tp7IioYPEr9 CMgym9iQRNH6RQplmBAzmy96wJZXtr6QIzVAkP+o= To: John Dowdell , Kathleen.Moriarty.ietf@gmail.com References: <5C00A58A-AED7-4306-B5ED-DA9663C417B5@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <40900a56-0d55-4bcd-f507-c1224f7ee3e7@cs.tcd.ie> Date: Sun, 8 Jan 2017 12:07:03 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <5C00A58A-AED7-4306-B5ED-DA9663C417B5@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010409010205070809080308" Archived-At: Cc: detnet@ietf.org Subject: Re: [Detnet] Network security - purely technical? X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Jan 2017 12:07:10 -0000 This is a cryptographically signed message in MIME format. --------------ms010409010205070809080308 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi John, Sorry for the slow response... On 04/01/17 19:54, John Dowdell wrote: > Dear Sec ADs >=20 > We in detnet are engaging in writing security-related text in our > drafts. As is normal, much is being or has been written about > technical methods of subverting the operation of detnets. >=20 > I wonder if it is also time, given the uses to which detnets will be > put (factory and continuous process control, live entertainment and > power grid control to name but a few), that readers of > security-related RFCs should also be encouraged to consider the > business cases of choosing to mitigate against a set of threats or > not. An extreme view may be that the finance community in a > particular organisation see such mitigation as unaffordable, until > that is the worst happens and the cost of implementing the security > pales into insignificance against the impact not only to the > organisations operations but to the reputation of their brand. >=20 > It is this reputational damage that I brought up at the detnet > session at IETF 97; a reputation can take years to build up, but can > be torn down so very quickly as the news, correct or otherwise, gets > out. I wondered if it would help the community who have to propose > the mitigation for security threats to have some appropriate > guidelines or advice to understand the potential business impact, so > that they can better build their case when applying for funds to > design and build out their detnet. >=20 > I=E2=80=99m acutely aware that the IETF is a technical organisation, bu= t do > you think there is a place for some guidelines that are mostly > already in the public domain, just not our public domain? Sorry, I'm not at all clear on what you're asking there. Can you elaborate? Thanks, S. >=20 > Regards John >=20 >=20 >=20 >=20 >=20 --------------ms010409010205070809080308 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAxMDgx MjA3MDNaMC8GCSqGSIb3DQEJBDEiBCAkmWeI9QOCiy7erfhqJHxEII8+v8QlAULkUnVEDTK5 QzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAM5MeFmB8xB0qaEBq+vNxH5A/ARP6ndyq93wBYPV/L9Yck/7jlYLW6 jzQdWWfyPvVhj0SvaR8NuJcmYLdXAoqgaCPGbfAI3WVRSUgIk23lDZ9N9d8mSagmZKk5gMun kNlbJl3NYeCQ4Syecj3oQpHBIs09GkjxyJAq4wMvmoOI47H7LZTQ2b6duFCufNSduHGb3rC3 YIgbMmJsYN5JfTaL1lk7fV5vr3fYKGPOAOo5moe26hvi+MeJBH6nMLr7v1Vz5GhzXpoTtknw lunnvR6t9B5ElAVWSH2AJ/xD2qm2Y/7FJpuxbWPzawgPL9Is8ZddgkYNGGICMXX4+NRjC0nT AAAAAAAA --------------ms010409010205070809080308-- From nobody Sun Jan 22 14:23:38 2017 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 C0F57129A4C; Sun, 22 Jan 2017 14:23:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 inqCLQmokoQA; Sun, 22 Jan 2017 14:23:34 -0800 (PST) Received: from asmtp5.iomartmail.com (asmtp5.iomartmail.com [62.128.201.176]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCA0D129A49; Sun, 22 Jan 2017 14:23:33 -0800 (PST) Received: from asmtp5.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MMNVrm032029; Sun, 22 Jan 2017 22:23:31 GMT Received: from 950129200 ([176.241.250.3]) (authenticated bits=0) by asmtp5.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0MMNPmP031958 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sun, 22 Jan 2017 22:23:28 GMT From: "Adrian Farrel" To: "'John Dowdell'" References: <86C8BF8E-7475-484F-89DD-62D428C96983@gmail.com> In-Reply-To: <86C8BF8E-7475-484F-89DD-62D428C96983@gmail.com> Date: Sun, 22 Jan 2017 22:23:27 -0000 Message-ID: <0a6d01d274fe$2a87e530$7f97af90$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0A6E_01D274FE.2AA0EB70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH2aMLSnUr04bXpaCJBKv8lx+37yqD9Jlvg Content-Language: en-gb X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22840.002 X-TM-AS-Result: No--13.118-10.0-31-10 X-imss-scan-details: No--13.118-10.0-31-10 X-TMASE-MatchedRID: yebcs53SkkCI0KPyMNrNUsrT39PoDNtWA3qzfR5DdMsXpkLLKLYrrNeu l29/x8ODB0OmVprnj8hSi2EweEhJsqzu4G+93oCZBEfU2vugRF382p2ebJNgc4eUNQK7Qj5cfJJ VqcZJmJLUn56zTDwAWAxHHMavlU4vn/m18ngarmvFlCgYxEaGExPlTZcBPlZFsp5O052MzLqBuL DzzkmS124btYJYPAJCdCcWUewSWKRPxIXOhlk+6eYAh37ZsBDCj0hFbSgsWhy1eX0jEQ9c6kghF UT1Eid0XRrFMKR5EDvlct82O1W2f6SbvL5QzJ6If598+KnsMOgBZBplMxI/ziDbJV2PcsBEXRAp ulKqWOoEpJEgN5m6+Y40IvbU6GdukU34HyglnlpCvapcIkxJX5rOgZfh4P32ExpsOtmUB6nv/72 zC4hJFVhUDZOPhwqIRHaihp8THGAxoJNALx/f4Z3bt4XlQMWjD+LwVja9M4EgOnjvjQ5gMSWdw9 Myj4ex9dMkDbqNTiWX7nDC+4gKenNQXkvyemjfXTK4OtPUfQSjuF41aTJRXZ/paSZmLhGje5bas ibx4KfyTo1GsSlyqhkigyII1PZ5MuPfXQm0MvCKC6Im4I1RF9Vj2MQh1a6nYB83633RxLeHNAeT lC/7tTOaljH5QqOHcLYrJin8fu9ZiostRfaYC7iMC5wdwKqddwX/SSKrKHgPGMG6AkHPPAhO7Hq RFugr823ldlTfC4t2QRPOro/h7RSF8L+KnNGTpYQ/SMviFcMiBAf19LYIBpU4cC9nAOhdUdfEKc 10rU44RDGbByRvWxESBRJlSEUWU6L1rmVqlpGeAiCmPx4NwGmRqNBHmBvevqq8s2MNhPB9j2Gwz TE3vbyah9aCYUCH2Tw9Cyyby+fmOV/uBZVGEJIHHtYJMPxIMEf6ARcPGffRED8cypuD19Sf6T5d 5Njlab2+6QNHA7rJc0galx9ch/CAvm9iRH53 Archived-At: Cc: mpls@ietf.org, detnet@ietf.org, teas@ietf.org Subject: Re: [Detnet] Help wanted in detnet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: adrian@olddog.co.uk 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, 22 Jan 2017 22:23:37 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0A6E_01D274FE.2AA0EB70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hey John, I realise that your email was two months ago, but I don't see any responses in the archive and so I thought I would try to understand why by re-reading your email. I think it is very probably completely unclear to everyone who is not following Detnet exactly what you're asking for. Reading your email (and none of the Detnet documents) I am not clear whether you plan to transport deterministic Ethernet over some as yet unspecified data plane (which you might choose or enhance based on its capabilities), whether you propose to map the features of the transported deterministic Ethernet to features of the transport, whether you hope to map the features of the deterministic Ethernet to features of the transport so that only the data is actually transported, or what. You could, for example, use a transport that has no scheduling and queueing support, but that is also non-blocking. Indeed, the word "transport" probably immediately made half of your audience think one thing (transport network) and the other half another thing (transport layer protocol). Of course, I went the extra mile ;-) and looked at your slide. Sadly no light was shed. I suspect the answer you're looking for is not "why not use deterministic Ethernet as your transport?" and similarly "have you thought of using a photonic network?" Can you better phrase your question for the audience? Thanks, Adrian From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Dowdell Sent: 15 November 2016 05:32 To: teas@ietf.org; mpls@ietf.org; detnet@ietf.org Subject: [Detnet] Help wanted in detnet Hi all in mpls and teas groups (consolidating earlier posting only on mpls) Over in detnet wg we are working on transporting deterministic Ethernet (e.g. from 802.1TSN LANs) across the wide area for applications such as industrial control and audio/video broadcast. One of the key assumptions is that the underlying transport already has sufficient scheduling and queueing support to allow proper extension of time-sensitive (or even time-critical) traffic over, for example, MPLS. To help us validate that assumption, please can someone volunteer to help us? Feel free to come over to the detnet list. Recommendations on exactly which flavour(s) of MPLS and/or configurations and/or gotchas would be most welcome. The slides in question are here https://www.ietf.org/proceedings/97/slides/slides-97-detnet-detnet-data-plane-02 .pptx, slide 4. Many thanks in anticipation. John ------=_NextPart_000_0A6E_01D274FE.2AA0EB70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hey = John,

 

I realise that your email was = two months ago, but I don't see any responses in the archive and so I = thought I would try to understand why by re-reading your = email.

 

I think it is very probably = completely unclear to everyone who is not following Detnet exactly what = you're asking for.

 

Reading your email (and none = of the Detnet documents) I am not clear whether you plan to transport = deterministic Ethernet over some as yet unspecified data plane (which = you might choose or enhance based on its capabilities), whether you = propose to map the features of the transported deterministic Ethernet to = features of the transport, whether you hope to map the features of the = deterministic Ethernet to features of the transport so that only the = data is actually transported, or what. You could, for example, use a = transport that has no scheduling and queueing support, but that is also = non-blocking.

 

Indeed, the word = "transport" probably immediately made half of your audience = think one thing (transport network) and the other half another thing = (transport layer protocol).

 

Of course, I went the extra = mile ;-) and looked at your slide. Sadly no light was = shed.

 

I suspect the answer you're = looking for is not "why not use deterministic Ethernet as your = transport?" and similarly "have you thought of using a = photonic network?"

 

Can you better phrase your = question for the audience?

 

Thanks,

Adrian

 

From: detnet = [mailto:detnet-bounces@ietf.org] On Behalf Of John = Dowdell
Sent: 15 November 2016 05:32
To: = teas@ietf.org; mpls@ietf.org; detnet@ietf.org
Subject: = [Detnet] Help wanted in detnet

 

Hi all in mpls and = teas groups (consolidating earlier posting only on = mpls)

 

Over in detnet wg we are working on transporting deterministic = Ethernet (e.g. from 802.1TSN LANs) across the wide area for applications = such as industrial control and audio/video broadcast. One of the key = assumptions is that the underlying transport already has sufficient = scheduling and queueing support to allow proper extension of = time-sensitive (or even time-critical) traffic over, for example, = MPLS.

 

To help us validate that assumption, please can someone = volunteer to help us? Feel free to come over to the detnet list. = Recommendations on exactly which flavour(s) of MPLS and/or = configurations and/or gotchas would be most = welcome.

 

 

Many thanks in anticipation.

 

John

 

 

 

 

------=_NextPart_000_0A6E_01D274FE.2AA0EB70-- From nobody Sun Jan 22 15:25:45 2017 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 D7D0712948F for ; Sun, 22 Jan 2017 15:25:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.156 X-Spam-Level: X-Spam-Status: No, score=-3.156 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, RCVD_IN_MSPIKE_H2=-1.156, 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 qY65HvyQRMGd for ; Sun, 22 Jan 2017 15:25:42 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id C55EE12947B for ; Sun, 22 Jan 2017 15:25:41 -0800 (PST) Received: (qmail 950 invoked by uid 0); 22 Jan 2017 23:25:39 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy8.mail.unifiedlayer.com with SMTP; 22 Jan 2017 23:25:39 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id bbRZ1u00u2SSUrH01bRcu3; Sun, 22 Jan 2017 16:25:37 -0700 X-Authority-Analysis: v=2.1 cv=J7g5smXS c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IgFoBzBjUZAA:10 a=r77TgQKjGQsHNAKrUKIA:9 a=48vgC7mUAAAA:8 a=AEDFM0qtAAAA:8 a=oDAgVuGWUbNHv24R1X8A:9 a=7U8PblL76EH-Qy0r:21 a=TA6A2QWcWSgaaYax:21 a=CjuIK1q_8ugA:10 a=bAYZg8X5nFwA:10 a=UXQz2jJI57UA:10 a=un45IlilgiACyq7YEsAA:9 a=8-Zwe7KDYJyXcBPL:21 a=rWFxRt0EX17nccGa:21 a=BjBjrUqITmSQrCJq:21 a=UiCQ7L4-1S4A:10 a=6UIaq3Bcl8oA:10 a=_W_S_7VecoQA:10 a=frz4AuCg-hUA:10 a=w1C3t2QeGrPiZgrLijVG:22 a=NCq4FBG6EvGFEERSFaZp: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=trrLIj64nHBp9NS33aTjzwIy6/f4FX07jjJf/Ixi218=; b=az9trBTCNyhR0YF4t6LSSDnNQ1 NO6UNsyeG58wasYzhON0X3nYcJ9lteKDhRmr967x2jKO0AU8qaAE1rawrt0/gEIIZvAtaeprXs37p GOYPnlXrV4KH4FITMRJqSAcX3; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:41743 helo=[11.4.0.102]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.87) (envelope-from ) id 1cVRVv-0006UO-3N; Sun, 22 Jan 2017 16:25:35 -0700 From: Lou Berger To: , "'John Dowdell'" Date: Sun, 22 Jan 2017 18:25:34 -0500 Message-ID: <159c87f92e8.27fd.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <0a6d01d274fe$2a87e530$7f97af90$@olddog.co.uk> References: <86C8BF8E-7475-484F-89DD-62D428C96983@gmail.com> <0a6d01d274fe$2a87e530$7f97af90$@olddog.co.uk> User-Agent: AquaMail/1.7.2-121 (build: 100700200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------159c87fc6d01ac727fd439be388" 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.85.191 X-Exim-ID: 1cVRVv-0006UO-3N X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([11.4.0.102]) [100.15.85.191]:41743 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: mpls@ietf.org, detnet@ietf.org, teas@ietf.org Subject: Re: [Detnet] Help wanted in detnet X-BeenThere: detnet@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Discussions on Deterministic Networking BoF and Proposed WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Jan 2017 23:25:44 -0000 This is a multi-part message in MIME format. ------------159c87fc6d01ac727fd439be388 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi adrian. I think we have good synergy now happening on the participant and chair levels. Check out [1] as one example... Lou [1] https://www.ietf.org/mail-archive/web/detnet/current/msg00887.html On January 22, 2017 5:24:17 PM "Adrian Farrel" wrote: > Hey John, > > I realise that your email was two months ago, but I don't see any responses in > the archive and so I thought I would try to understand why by re-reading your > email. > > I think it is very probably completely unclear to everyone who is not following > Detnet exactly what you're asking for. > > Reading your email (and none of the Detnet documents) I am not clear > whether you > plan to transport deterministic Ethernet over some as yet unspecified data > plane > (which you might choose or enhance based on its capabilities), whether you > propose to map the features of the transported deterministic Ethernet to > features of the transport, whether you hope to map the features of the > deterministic Ethernet to features of the transport so that only the data is > actually transported, or what. You could, for example, use a transport that has > no scheduling and queueing support, but that is also non-blocking. > > Indeed, the word "transport" probably immediately made half of your audience > think one thing (transport network) and the other half another thing (transport > layer protocol). > > Of course, I went the extra mile ;-) and looked at your slide. Sadly no light > was shed. > > I suspect the answer you're looking for is not "why not use deterministic > Ethernet as your transport?" and similarly "have you thought of using a > photonic > network?" > > Can you better phrase your question for the audience? > > Thanks, > Adrian > > From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Dowdell > Sent: 15 November 2016 05:32 > To: teas@ietf.org; mpls@ietf.org; detnet@ietf.org > Subject: [Detnet] Help wanted in detnet > > Hi all in mpls and teas groups (consolidating earlier posting only on mpls) > > Over in detnet wg we are working on transporting deterministic Ethernet (e.g. > from 802.1TSN LANs) across the wide area for applications such as industrial > control and audio/video broadcast. One of the key assumptions is that the > underlying transport already has sufficient scheduling and queueing support to > allow proper extension of time-sensitive (or even time-critical) traffic over, > for example, MPLS. > > To help us validate that assumption, please can someone volunteer to help us? > Feel free to come over to the detnet list. Recommendations on exactly which > flavour(s) of MPLS and/or configurations and/or gotchas would be most welcome. > > The slides in question are here > https://www.ietf.org/proceedings/97/slides/slides-97-detnet-detnet-data-plane-02 > .pptx, slide 4. > > Many thanks in anticipation. > > John > > > > > > > > ---------- > _______________________________________________ > detnet mailing list > detnet@ietf.org > https://www.ietf.org/mailman/listinfo/detnet > ------------159c87fc6d01ac727fd439be388 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: 8bit

Hi  adrian. 

I think we have good synergy now happening on the participant and chair levels.  Check out [1] as one example...

Lou
[1] https://www.ietf.org/mail-archive/web/detnet/current/msg00887.html

On January 22, 2017 5:24:17 PM "Adrian Farrel" <adrian@olddog.co.uk> wrote:

Hey John,

 

I realise that your email was two months ago, but I don't see any responses in the archive and so I thought I would try to understand why by re-reading your email.

 

I think it is very probably completely unclear to everyone who is not following Detnet exactly what you're asking for.

 

Reading your email (and none of the Detnet documents) I am not clear whether you plan to transport deterministic Ethernet over some as yet unspecified data plane (which you might choose or enhance based on its capabilities), whether you propose to map the features of the transported deterministic Ethernet to features of the transport, whether you hope to map the features of the deterministic Ethernet to features of the transport so that only the data is actually transported, or what. You could, for example, use a transport that has no scheduling and queueing support, but that is also non-blocking.

 

Indeed, the word "transport" probably immediately made half of your audience think one thing (transport network) and the other half another thing (transport layer protocol).

 

Of course, I went the extra mile ;-) and looked at your slide. Sadly no light was shed.

 

I suspect the answer you're looking for is not "why not use deterministic Ethernet as your transport?" and similarly "have you thought of using a photonic network?"

 

Can you better phrase your question for the audience?

 

Thanks,

Adrian

 

From: detnet [mailto:detnet-bounces@ietf.org] On Behalf Of John Dowdell
Sent: 15 November 2016 05:32
To: teas@ietf.org; mpls@ietf.org; detnet@ietf.org
Subject: [Detnet] Help wanted in detnet

 

Hi all in mpls and teas groups (consolidating earlier posting only on mpls)

 

Over in detnet wg we are working on transporting deterministic Ethernet (e.g. from 802.1TSN LANs) across the wide area for applications such as industrial control and audio/video broadcast. One of the key assumptions is that the underlying transport already has sufficient scheduling and queueing support to allow proper extension of time-sensitive (or even time-critical) traffic over, for example, MPLS.

 

To help us validate that assumption, please can someone volunteer to help us? Feel free to come over to the detnet list. Recommendations on exactly which flavour(s) of MPLS and/or configurations and/or gotchas would be most welcome.

 

 

Many thanks in anticipation.

 

John

 

 

 

 

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

------------159c87fc6d01ac727fd439be388--