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:[email protected]] > 发送时间: 2018年7月30日 23:05 > 收件人: Dongjie (Jimmy) <[email protected]> > 抄送: TEAS WG ([email protected]) <[email protected]>; [email protected] > 主题: 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:*[email protected] [mailto:[email protected]] *On Behalf Of > > *Robert Raszuk > > *Sent:* Sunday, July 29, 2018 6:11 AM > > *To:* Greg Mirsky <[email protected]> > > *Cc:* Dongjie (Jimmy) <[email protected]>; [email protected] > > *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 <[email protected] > > <mailto:[email protected]>> 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 <[email protected] > > <mailto:[email protected]>> 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) > > <[email protected] <mailto:[email protected]>> 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:[email protected] > > <mailto:[email protected]>] *On Behalf Of *Robert > Raszuk > > *Sent:* Wednesday, July 25, 2018 8:24 PM > > *To:* Acee Lindem (acee) <[email protected] > > <mailto:[email protected]>> > > *Cc:* [email protected] <mailto:[email protected]> > > > > > > *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) > > <[email protected] <mailto:[email protected]>> wrote: > > > > *From: *rtgwg <[email protected] > > <mailto:[email protected]>> on behalf of Stewart > > Bryant <[email protected] > > <mailto:[email protected]>> > > *Date: *Wednesday, July 25, 2018 at 5:55 AM > > *To: *Robert Raszuk <[email protected] > > <mailto:[email protected]>> > > *Cc: *Routing WG <[email protected] > <mailto:[email protected]>> > > *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 > > [email protected] <mailto:[email protected]> > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > > > _______________________________________________ > > rtgwg mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg > > _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
