AW: [Teas] 答复: VPN security vs SD-WAN security

<Ruediger.Geib@telekom.de> Tue, 07 August 2018 07:27 UTC

Return-Path: <Ruediger.Geib@telekom.de>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30387130DDE; Tue, 7 Aug 2018 00:27:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.309
X-Spam-Level:
X-Spam-Status: No, score=-4.309 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, T_DKIMWL_WL_HIGH=-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=telekom.de header.b=8pYtaz1k; dkim=pass (1024-bit key) header.d=telekom.onmicrosoft.de header.b=fiKt+ASa
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 g8IvXXh27yRd; Tue, 7 Aug 2018 00:27:38 -0700 (PDT)
Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 EF8F3130E02; Tue, 7 Aug 2018 00:27:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1533626858; x=1565162858; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=9z/u7VXgMv0Jb4uzVSkHjZfa/iKBSMmc4ilTMu6SSrI=; b=8pYtaz1ktEFLptd/3FenMB4vV1e/w/d4W8BGFLk0de7tGblIbDNzvBQU zQRjHgUWFAgKTQ/wESKjsYExWsRHElTjA7e8SbengL8NQ29LR4AI0y3Hr E04YSjQgPgPC7oiLAZQz5h9pdRt9rI6Td0h55dfBs8AoQQKWLFPN7AEBH QC5R5UwPVXdAmT6EmDtQlxVShgsRYvYZ1Hr3G3tOLEbdWqunvixI5Pboz H1/I2gnw87EypGvMlg32LMzR+mWz98WoJpiK5l+W1fZH/FPIL0CiELtM6 /4ZOBR0GB7y2BCdcUQ76jVcEa/Y3KfzkexRFcYrkOr273iNqcSi4ZkNPW A==;
Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Aug 2018 09:26:26 +0200
X-IronPort-AV: E=Sophos;i="5.51,454,1526335200"; d="scan'208";a="309745088"
Received: from he105665.emea1.cds.t-internal.com ([10.169.118.62]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 07 Aug 2018 09:26:26 +0200
Received: from HE101949.EMEA1.cds.t-internal.com (10.169.118.76) by HE105665.emea1.cds.t-internal.com (10.169.118.62) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 7 Aug 2018 09:26:13 +0200
Received: from HE106564.emea1.cds.t-internal.com (10.171.40.16) by HE101949.EMEA1.cds.t-internal.com (10.169.118.76) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 7 Aug 2018 09:26:13 +0200
Received: from GER01-LEJ-obe.outbound.protection.outlook.de (51.5.80.22) by O365mail01.telekom.de (172.30.0.234) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Tue, 7 Aug 2018 09:25:57 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.onmicrosoft.de; s=selector1-telekom-onmicrosoft-de; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9z/u7VXgMv0Jb4uzVSkHjZfa/iKBSMmc4ilTMu6SSrI=; b=fiKt+ASa+qOr35pWBwDh3zM7viNUixjsm8Ks2gh/yQSF1AIBxfiUAg3OZb3uyTqMsW1Zb0uAOa5jQWd7yBZ9L9zz82rEViFLWQ2BoKk2OxMLpGMeQhrv3+vtspw7VAjT2xxkGIRldhW5bjCykoyQZ1KB/f5zEU/sKFm3hylOqrE=
Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.143) by FRAPR01MB0114.DEUPRD01.PROD.OUTLOOK.DE (10.158.130.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1017.14; Tue, 7 Aug 2018 07:26:05 +0000
Received: from FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2]) by FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE ([fe80::e8f7:3190:beb6:eee2%5]) with mapi id 15.20.1017.019; Tue, 7 Aug 2018 07:26:05 +0000
From: <Ruediger.Geib@telekom.de>
To: <stewart.bryant@gmail.com>
CC: <teas@ietf.org>, <rtgwg@ietf.org>
Subject: =?utf-8?B?QVc6IFtUZWFzXSDnrZTlpI06IFZQTiBzZWN1cml0eSB2cyBTRC1XQU4gc2Vj?= =?utf-8?Q?urity?=
Thread-Topic: =?utf-8?B?W1RlYXNdIOetlOWkjTogVlBOIHNlY3VyaXR5IHZzIFNELVdBTiBzZWN1cml0?= =?utf-8?Q?y?=
Thread-Index: AdQuH+T+7KMuzTAYSJGMSpltp2II8g==
Date: Tue, 7 Aug 2018 07:26:05 +0000
Message-ID: <FRAPR01MB011344D6BB848F0BABC5BCF29C270@FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE>
Accept-Language: en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Ruediger.Geib@telekom.de;
x-originating-ip: [164.19.3.156]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; FRAPR01MB0114; 6:vTKGw4AYzy4qQykJcVy4rpBJA6F28RACbh/49DlCCJJ8ZY6ug0nasix77rJh8nlW35mPn/O/1oAGdK0y55esyLLcHC6ayHhfR6IU9nzRRlCEqJTyUPbVSujl3WPkdnfK7lZuOyAnnSRnO6BOu/9znaqOFTJi3eWrBrVw27Kc8744On7cyxtbFf8a3bPiYc2+r89KAMMjmMe8EiWVifIXUmkCM7sGk2FPKhfRVCWDQCL4tJ7CT+9CNjTSLt5gw/oGl0WUan9qQPnGBIlvKI/ua2AYSDvQwx0Q6j31PxQ6nuEmT2+P/PJlZmIiPmFAONtn3nPF2RNSn8hgb1yOpVPLoMeGDrNBIoctozi0sdR5451ZV5QXAKJEePMAJFzSL4b6z4qFoxxgPjmZFp1xf/4DahvSBl53ACxqR+zio97eCmHaHl736G2cN2eHex4S1lVJXGSzlPPHCyOfdUIML8/VCA==; 5:omJLC8BbzPC4odklKAveJSDOfpFHek+pPtqW3pkeXa9HOLb4cfcORzHGUufQE2Ne/ZKLMuTqrgJvKLKbIGJ400fxCdjvQBQXo1u6/ILcVf6cr5PpduVcY4EIeDmf072udrVypLZgUXS8C/CZEQi7CS6PX5eGWJa6rL2EZuf29mE=; 7:TXGn+4Y9KDf9NFPYr4w/z/m09s3VRarZhMMVIezLtX0OgRzIvHaKcqtvjH6BeymcT5Dk+CHnu1MJoaIHtSlab8D0y/XVPU2EbTLCjn6lPFvHaY3PId4JG5+XaextIWPln5r2ZkMh0eWyE6DvVI1xzpBssAcVzDc0uSharKwjVFyx1HxZ7SeaQoL6ucWOC1G3Sdo/8OoDsp3P22+ZXgGcm1wz6GOEnXLSVWQr1AJ/VRyu3v9g7KzNxggAV2zbuWLB
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: f5457bd8-c07c-4f26-9329-08d5fc370943
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:FRAPR01MB0114;
x-ms-traffictypediagnostic: FRAPR01MB0114:
x-microsoft-antispam-prvs: <FRAPR01MB01149E50DCEBDCBCD85BD23A9C270@FRAPR01MB0114.DEUPRD01.PROD.OUTLOOK.DE>
x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(192374486261705)(50582790962513)(85827821059158)(260130700054247)(95692535739014)(12901024606220);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231311)(944501410)(52105095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:FRAPR01MB0114; BCL:0; PCL:0; RULEID:; SRVR:FRAPR01MB0114;
x-forefront-prvs: 0757EEBDCA
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(136003)(396003)(366004)(37854004)(199004)(189003)(51444003)(72206003)(81166006)(81156014)(966005)(7696005)(53946003)(52396003)(14454004)(478600001)(75402003)(3846002)(6116002)(7736002)(8936002)(305945005)(33656002)(68736007)(15650500001)(86362001)(2900100001)(54906003)(316002)(55016002)(66066001)(6916009)(6306002)(74482002)(9686003)(97736004)(224303003)(106356001)(85202003)(105586002)(5660300001)(85182001)(53546011)(2906002)(102836004)(486006)(476003)(186003)(256004)(4326008)(39060400002)(14444005)(26005)(53936002)(5250100002)(777600001)(579004); DIR:OUT; SFP:1101; SCL:1; SRVR:FRAPR01MB0114; H:FRAPR01MB0113.DEUPRD01.PROD.OUTLOOK.DE; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: telekom.de does not designate permitted sender hosts)
x-microsoft-antispam-message-info: b4ppnQ4puafm8ojXbH3H/s0QxMbJXPCfM5qQ+TcYC1Auztpm4lhnMqVxYnrgGUWkFSIONi5bllKTo+M2IAwU8ulcLP8ElAm3U2+0YqfP1P73J4ux0K0T73YHKTENL18QbxbmV9/3KjFPFnHeO2q3SORj5U5wohncCCOKOOXeJuuNDFbyfMJR4mj0wzx2bF5TqYX7tCyu9PvinupdlUTnkZLNjMe/BKpI0Rv3quVnEiXqiBbvzOsyiCHGJWynnaE4Dqcmcrw78z8tdGSdV42ent/XTAu1hKunvfwTa2shNe4jTmVoxjxHoktU2ERg0gOhsAeKIcYCkeoDm3s35NGg/YFn8exegztVttfj9jTRmxQ=
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: f5457bd8-c07c-4f26-9329-08d5fc370943
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Aug 2018 07:26:05.0367 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bde4dffc-4b60-4cf6-8b04-a5eeb25f5c4f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: FRAPR01MB0114
X-OriginatorOrg: telekom.de
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/C_T2IkW9EEckhMXXjO8sfcYuvz8>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Aug 2018 07:27:43 -0000

Stewart,

thanks. My replies to your mail are marked [RG] in line below.

Regards, Ruediger

---------------------
From: Stewart Bryant [mailto:stewart.bryant@gmail.com] 
.....
Ruediger

The work I am doing on VPN+ is not targetted at the big I Internet. It is targetted at mobile edge, access and the core of the mobile provider. These are the customers that are asking for the service, and that in turn is based on the output of SDOs that they are more comfortable associating with (3GPP and ITU-R).

[RG] That's fine with me. AFAIK, 3GPP architectures like LTE are connection oriented and 5G will be too. As long as these kind of solutions stay in the part of network which is part of the wireless domain, that's ok with me. I'd appreciate a statement in the related drafts. I can't recall having it perceived like that when you presented in London - but I also could have overheard something.

However, as we all know, a lot of traffic that users consider to go across the big I internet is between them and the PoP of the CDN provider supporting the service they are accessing. That is the model that the mobile operators want to propagate by pulling compute resources closer to the edge of their network than is currently the case.

[RG] My information on 5G is, if one aims on "remote" interaction between moving objects or humans, latencies must be small. So content or CPU cycles required to support these kind of specialized services must be close to interacting persons and objects. I'm not sure to which extent content in general will move from central cities to towns. 

I am sure there are commercial reasons why they want that to happen but there are also application reasons that drive architecture reasons, and if they align with commercial reasons it is more likely to get deployed.

[RG] I'd expect economic constraints to impact the architecture of the solution too.  

- Stewart


On 02/08/2018 13:06, Ruediger.Geib@telekom.de wrote:
> Stewart,
>
> I'd appreciate a discussion based on operational experience. In which Diffserv supported network did which application fail due to a lack of suitable scheduling or due to a lack of codepoints, which would have been working properly on the same network with Detnet and more codepoints? I'd be happy, if you were able to provide a link to a presentation.
>
> I've started my QoS career with ATM, a technology offering dedicated QoS network resources. Spare capacities with a network-fully-booked indication were the first lesson I learned, and this combination turned out to be bad whenever I encountered it from then on. My take on Diffserv is, that it is useful to protect certain traffic in the case of not foreseen networking conditions. That means, in 99,....% of the time, todays Diffserv isn't required, because there's no congestion.
>
> You seem to head for generic solutions, applicable in all parts of the Internet. I don't understand what the benefit of dedicated resources would be, given they are required end-to-end. I excuse if I missed a statement that the approach you propose is limited to specific instances or sections of the Internet.
>
> Regards,
>
> Ruediger
>
>
> -----Ursprüngliche Nachricht-----
> Von: rtgwg [mailto:rtgwg-bounces@ietf.org] Im Auftrag von Stewart 
> Bryant
> Gesendet: Donnerstag, 2. August 2018 13:19
> An: Joel M. Halpern <jmh@joelhalpern.com>;; Dongjie (Jimmy) 
> <jie.dong@huawei.com>;
> Cc: TEAS WG (teas@ietf.org) <teas@ietf.org>;; rtgwg@ietf.org
> Betreff: Re: [Teas] 答复: VPN security vs SD-WAN security
>
>
>
> On 01/08/2018 16:26, Joel M. Halpern wrote:
>> I am not disagreeing with a view that network resource allocation 
>> requires some visibility to those resources.
>> It is the assertion of a "deep integration" that seems to lack grounding.
>>
>> We know that one can use our existing VPN technologies and tools like 
>> diffserv, with suitable admission control and path computation, to 
>> provide strong service guarantees to meet SLAs. As others have noted 
>> in other presentations, when it comes to the data plane this seems to 
>> meet the articulated needs from various fora.
>>
> Hi Joel,
>
> We can certainly get a long way with those tools for "conventional"
> applications.
>
> However, as we support the sort of applications that look for a deterministic networking class of SLA, then I am concerned that we need to map the traffic to dedicated resources in more detail than we currently do through the diffserv mechanism.
>
> What we do at the moment with diffserv is a mapping of packets to resources, but in practise we limit those resources to ingress and egress queues with the queue management algorithm out of scope. I am not convinced this is adequate for the future, and think that we need to start to consider CPU/NPU cores, queue algorithms, and maybe other resources.
>
> I am also concerned that the number of diffserv code points available in MPLS is going to be insufficient.
>
> Of course what we know today from experience is based on the 
> applications that can run on the network infrastructure that we have 
> today. That is a self limiting situation. We are designing DETNET 
> because this model is inadequate for some classes of application that 
> would like to run over a more general network. What we are doing with
> VPN+ is to integrate DETNET into a VPN structure alongside classic VPNs.
>
> - Stewart
>
>
>> Yours,
>> Joel
>>
>> On 8/1/18 11:22 AM, Dongjie (Jimmy) wrote:
>>> This statement is based on the comparison between overlay VPNs and 
>>> network slices. The resource here refers to various data plane 
>>> resources that can be allocated to a particular slice (queues, 
>>> buffer, etc.). Some level of resource isolation is necessary to 
>>> ensure that service in one slice never interferes with service in 
>>> another slice.
>>>
>>> May I know what are the requirements you've got?
>>>
>>> Best regards,
>>> Jie
>>>
>>>> -----邮件原件-----
>>>> 发件人: Joel M. Halpern [mailto:jmh@joelhalpern.com]
>>>> 发送时间: 2018年7月30日 23:05
>>>> 收件人: Dongjie (Jimmy) <jie.dong@huawei.com>;
>>>> 抄送: TEAS WG (teas@ietf.org) <teas@ietf.org>;; rtgwg@ietf.org
>>>> 主题: Re: VPN security vs SD-WAN security
>>>>
>>>> Actually, assuming I understand the statement properly, "deep 
>>>> integration with the underlay resource would be necessary" does not 
>>>> appear to be an accurate statement derivable from the requirements 
>>>> that I have seen.
>>>>
>>>> Yours,
>>>> Joel
>>>>
>>>> On 7/30/18 8:23 AM, Dongjie (Jimmy) wrote:
>>>>> (Adding TEAS as it is where the VPN+ framework draft is discussed)
>>>>>
>>>>> Hi Robert and Greg,
>>>>>
>>>>> As discussed during the VPN+ presentation in TEAS at IETF 102, the 
>>>>> scope is not the internet, as we know it would quite difficult or 
>>>>> even impossible to achieve the required guarantee at the scope of internet.
>>>>>
>>>>> And clearly the VPN overlays cannot provide the required 
>>>>> guarantee, deep integration with the underlay resource would be necessary.
>>>>>
>>>>> Another aspect we may take into consideration is the factor of 
>>>>> overprovisioning. The current network only has one 
>>>>> overprovisioning factor, which may not meet the requirement of 
>>>>> different services/customers. With network slicing, it is possible 
>>>>> to have different overprovisioning policy and factor in different slices.
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Jie
>>>>>
>>>>> *From:*rraszuk@gmail.com [mailto:rraszuk@gmail.com] *On Behalf Of 
>>>>> *Robert Raszuk
>>>>> *Sent:* Sunday, July 29, 2018 6:11 AM
>>>>> *To:* Greg Mirsky <gregimirsky@gmail.com>;
>>>>> *Cc:* Dongjie (Jimmy) <jie.dong@huawei.com>;; rtgwg@ietf.org
>>>>> *Subject:* Re: VPN security vs SD-WAN security
>>>>>
>>>>> Hey Greg,
>>>>>
>>>>> would not require global transit and likely be contained within 
>>>>> access or, at most, metro domains.
>>>>>
>>>>> That's news to me, but perhaps on the positive side :) I always 
>>>>> think WAN .. really wide one !
>>>>>
>>>>> The separation on "soft" vs "hard" guarantees is eventually all 
>>>>> about amount of network robustness and level of over provisioning.
>>>>> I sincerely hope it will not be yet another EVPN overlay over IP 
>>>>> network just painted with different marketing colors.
>>>>>
>>>>> Besides if any customer is serious and actually counts on those 
>>>>> guarantees he better purchase two of such services coming from 
>>>>> independent operators. That means that to be attractive 
>>>>> financially cost of such premium service must not be higher then 
>>>>> half of the p2p local fiber or cost of local access to closest IX 
>>>>> ports + port subscription in a given MAN where non blocking IX 
>>>>> fabric spans given
>>>> geography.
>>>>> It seems to me that at the end of the day the space for those 
>>>>> operators wishing to offer hard network slicing is actually pretty 
>>>>> narrow, but time will tell ...
>>>>>
>>>>> Rgs,
>>>>>
>>>>> r.
>>>>>
>>>>> On Sat, Jul 28, 2018 at 9:34 PM, Greg Mirsky 
>>>>> <gregimirsky@gmail.com <mailto:gregimirsky@gmail.com>> wrote:
>>>>>
>>>>>       Hi Robert,
>>>>>
>>>>>       very much agree with all you're saying and find us in 
>>>>> violent
>>>>>       agreement on "C". Proactive performance monitoring, in my 
>>>>> view as
>>>>>       well, is the reasonable path to provide "soft" SLA and, to a 
>>>>> degree,
>>>>>       prevent oversubscription of the network. And that, as you've 
>>>>> said,
>>>>>       is one way to "assured/guaranteed global IP transit".
>>>>>
>>>>>       But I think that there will be demand for "hard" guarantees 
>>>>> for
>>>>>       URLLC applications. But these, in my view,
>>>>>
>>>>>       would not require global transit and likely be contained 
>>>>> within
>>>>>       access or, at most, metro domains. Because of the limited 
>>>>> size of
>>>>>       the domain, IntServ may work, though that may be not the 
>>>>> most
>>>>>       efficient technique. We shall find out.
>>>>>
>>>>>       Hence my view on slicing:
>>>>>
>>>>>         * different applications will have different requirements 
>>>>> and use
>>>>>           different degrees of isolation and guarantees;
>>>>>         * "soft" slices may not need much of additional 
>>>>> standardization
>>>>>           and use available VPN technologies in combination with 
>>>>> PM OAM
>>>>>           for SLA monitoring and assurance;
>>>>>         * "hard" slices would span within a single access and/or 
>>>>> metro
>>>>>           domain. Networking solutions likely will be coupled with
>>>>>           architecture and interfaces developed in Multi-access 
>>>>> Edge
>>>>>           Computing (MEC).
>>>>>
>>>>>       Regards,
>>>>>
>>>>>       Greg
>>>>>
>>>>>       On Sat, Jul 28, 2018 at 6:02 AM, Robert Raszuk 
>>>>> <robert@raszuk.net
>>>>>       <mailto:robert@raszuk.net>> wrote:
>>>>>
>>>>>           Hi Jie,
>>>>>
>>>>>           > (network slicing) is to provide the demanding services 
>>>>> with guaranteed performance in a converged network,
>>>>>
>>>>>           Foundation of converged IP network is based on 
>>>>> statistical
>>>>>           multiplexing of traffic demands. As such it is in its 
>>>>> principle
>>>>>           quite contradictory to "guaranteed" characteristics
>>>>>           (performance, delays, jitter, drops -- you name it).
>>>>>
>>>>>           Application layers usually deal very well with all of 
>>>>> the above
>>>>>           I would state - normal characteristics of IP networks..
>>>>>
>>>>>           No doubt there will be those trying to offer some 
>>>>> network
>>>>>           slicing with guarantees and even those who will buy it.
>>>>> Just
>>>>>           like today there are those who offer you L2 circuit 
>>>>> between
>>>>>           endpoints except such L2 circuit is an emulated one with 
>>>>> zero
>>>>>           OEM visibility to the IP infrastructure underneath.
>>>>>
>>>>>           Now the network slicing is clearly aiming for even more
>>>>>           complexity under the hood. And that is not the only 
>>>>> problem. The
>>>>>           issue is cost. When SP is building the IP network the 
>>>>> goal is to
>>>>>           mux as many services on it as it simply results in 
>>>>> given's SP
>>>>>           revenue. Network slicing is promising as potentially 
>>>>> just by
>>>>>           configuration of few knobs they will be claiming 
>>>>> guarantees as
>>>>>           RFC says - except RFC will not likely tell you to stop
>>>>>           over-provisioning.
>>>>>
>>>>>           Unless the idea is to use strict policing with dedicated 
>>>>> queuing
>>>>>           on active and back paths or do something like RSVP 
>>>>> IntServ also
>>>>>           on active and backup paths per customer - I really don't 
>>>>> think
>>>>>           you can really guarantee much. And if you do that the 
>>>>> cost would
>>>>>           likely grow really steep.
>>>>>
>>>>>           So what is IMO the solution for assured/guaranteed 
>>>>> global IP
>>>>>           transit:
>>>>>
>>>>>           *A*  get diversely routed  dark fiber paths between your 
>>>>> POPs
>>>>>           (can be unprotected) which btw today do not cost that 
>>>>> much anymore
>>>>>
>>>>>           *B* get diversely routed  optical channels alsol between 
>>>>> your
>>>>>           POPs (can be unprotected)
>>>>>
>>>>>           *C*  use N disjoined by design (single AS Internet 
>>>>> providers
>>>>>           between your end-points) + proper SD-WAN with active SLA 
>>>>> monitoring
>>>>>
>>>>>           Clearly I am big supporter of *C* model for reasons 
>>>>> discussed on
>>>>>           this and few other recent threads.
>>>>>
>>>>>           I assume network slicing will try to get into be 
>>>>> something
>>>>>           between A/B & C but it is bounded up front with the cost 
>>>>> of the
>>>>>           two.
>>>>>
>>>>>           Many thx,
>>>>>
>>>>>           Robert.
>>>>>
>>>>>           On Sat, Jul 28, 2018 at 9:51 AM, Dongjie (Jimmy)
>>>>>           <jie.dong@huawei.com <mailto:jie.dong@huawei.com>> wrote:
>>>>>
>>>>>               Hi Robert,
>>>>>
>>>>>               IMO the two approaches are targeting at different 
>>>>> use cases
>>>>>               and customers.
>>>>>
>>>>>               The former (network slicing) is to provide the 
>>>>> demanding
>>>>>               services with guaranteed performance in a converged
>>>> network,
>>>>>               while the latter (switching between multiple 
>>>>> paralleled
>>>>>               networks) provides the customer with the best 
>>>>> performance
>>>>>               that is available among those candidates. To me the 
>>>>> latter
>>>>>               is still some kind of best effort, and as Toerless 
>>>>> said, it
>>>>>               depends on the diversity you can have in the 
>>>>> multiple
>>>> networks.
>>>>>               And I agree with Stewart on “you always pay a price 
>>>>> for
>>>>>               better than best effort.”
>>>>>
>>>>>               Best regards,
>>>>>
>>>>>               Jie
>>>>>
>>>>>               *From:*rtgwg [mailto:rtgwg-bounces@ietf.org
>>>>>               <mailto:rtgwg-bounces@ietf.org>] *On Behalf Of 
>>>>> *Robert
>>>> Raszuk
>>>>>               *Sent:* Wednesday, July 25, 2018 8:24 PM
>>>>>               *To:* Acee Lindem (acee) <acee@cisco.com
>>>>>               <mailto:acee@cisco.com>>
>>>>>               *Cc:* rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>>>
>>>>>
>>>>>               *Subject:* Re: VPN security vs SD-WAN security
>>>>>
>>>>>               True network slicing for IP networks means either 
>>>>> waist of
>>>>>               resources or very strict multi-level queuing at each 
>>>>> hop and
>>>>>               100% ingress traffic policing. Yet while this has a 
>>>>> chance
>>>>>               to work during normal operation at the time of even 
>>>>> regular
>>>>>               failures this all pretty much melts like cheese on a 
>>>>> good
>>>>>               sandwich.
>>>>>
>>>>>               It is going to be very interesting to compare how 
>>>>> single
>>>>>               complex sliced network compares for any end to end 
>>>>> robust
>>>>>               transport from N normal simple IP backbones and end 
>>>>> to
>>>> end
>>>>>               SLA based millisecond switch over between one and 
>>>>> another
>>>> on
>>>>>               a per flow basis. Also let's note then while the 
>>>>> former is
>>>>>               still to the best of my knowledge a draft the latter 
>>>>> is
>>>>>               already deployed globally in 100s of networks.
>>>>>
>>>>>               Best,
>>>>>               R.
>>>>>
>>>>>               On Wed, Jul 25, 2018 at 1:21 PM, Acee Lindem (acee)
>>>>>               <acee@cisco.com <mailto:acee@cisco.com>> wrote:
>>>>>
>>>>>                   *From: *rtgwg <rtgwg-bounces@ietf.org
>>>>>                   <mailto:rtgwg-bounces@ietf.org>> on behalf of 
>>>>> Stewart
>>>>>                   Bryant <stewart.bryant@gmail.com
>>>>>                   <mailto:stewart.bryant@gmail.com>>
>>>>>                   *Date: *Wednesday, July 25, 2018 at 5:55 AM
>>>>>                   *To: *Robert Raszuk <robert@raszuk.net
>>>>>                   <mailto:robert@raszuk.net>>
>>>>>                   *Cc: *Routing WG <rtgwg@ietf.org
>>>> <mailto:rtgwg@ietf.org>>
>>>>>                   *Subject: *Re: VPN security vs SD-WAN security
>>>>>
>>>>>                   On 25/07/2018 10:40, Robert Raszuk wrote:
>>>>>
>>>>>                       /* Adjusting the subject ... */
>>>>>
>>>>>                       Hello
>>>>>
>>>>>                       Stewart,
>>>>>
>>>>>                       You have made the below comment in the other
>>>> thread
>>>>>                       we are having:
>>>>>
>>>>>                           Indeed, I would have expected this to be 
>>>>> on a
>>>>>                           secure network of some sort either 
>>>>> purely
>>>>>                           private or some form of VPN. However, I 
>>>>> am
>>>> sure
>>>>>                           I read in your text that you were
>>>>>                           considering using the Public Internet 
>>>>> much in
>>>>>                           the way of SD-WAN.
>>>>>
>>>>>                       Would you mind as extensively as you can 
>>>>> expand
>>>> on
>>>>>                       the above statement ?
>>>>>
>>>>>                       Specifically on what basis do you treat say 
>>>>> L2VPN
>>>> or
>>>>>                       L3VPN of naked unencrypted packets often
>>>> traveling
>>>>>                       on the very same links as this "bad" 
>>>>> Internet
>>>>>                       traffic to be even slightly more secure then 
>>>>> IPSEC
>>>>>                       or DTLS encrypted SD-WAN carried data with
>>>> endpoints
>>>>>                       being terminated in private systems ?
>>>>>
>>>>>                       Thx,
>>>>>
>>>>>                       Robert
>>>>>
>>>>>
>>>>>                   Robert, I think that you have to take it as read 
>>>>> that an
>>>>>                   air traffic control SoF system is encrypting its
>>>>>                   packets. If it is not, then it is clearly not 
>>>>> fit for
>>>>>                   purpose.
>>>>>
>>>>>                   What concerns me is that an air traffic system 
>>>>> is one of
>>>>>                   the most, if not the most, high profile targets 
>>>>> in civil
>>>>>                   society. You get reminded of this each time you 
>>>>> travel
>>>>>                   to IETF.
>>>>>
>>>>>                   The thing about safety of flight traffic is that 
>>>>> a
>>>>>                   sustained and effective DDoS attack has global 
>>>>> impact in
>>>>>                   a way that few other such attacks have.
>>>>>
>>>>>                   A VPN system ought to sustain resistance to such 
>>>>> an
>>>>>                   attack better than the proposed system which 
>>>>> treats
>>>> the
>>>>>                   SoF traffic the same as regular traffic.
>>>>>
>>>>>                   I guess you are making a case for your network 
>>>>> slicing
>>>>>                   work 😉
>>>>>
>>>>>                   Acee
>>>>>
>>>>>
>>>>>
>>>>>                   - Stewart
>>>>>
>>>>>           _______________________________________________
>>>>>           rtgwg mailing list
>>>>>           rtgwg@ietf.org <mailto:rtgwg@ietf.org>
>>>>>           https://www.ietf.org/mailman/listinfo/rtgwg
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rtgwg mailing list
>>>>> rtgwg@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/rtgwg
>>>>>
>> _______________________________________________
>> Teas mailing list
>> Teas@ietf.org
>> https://www.ietf.org/mailman/listinfo/teas
> _______________________________________________
> rtgwg mailing list
> rtgwg@ietf.org
> https://www.ietf.org/mailman/listinfo/rtgwg