Hi Robert
I think that summarises the situation well.
Ultimately the market will decide how much it is prepared to pay for the
guarantee, and that will be based on a risk benefit analysis. That in
turn will determine the viability of the market as a whole.
I think that there are certain types of network that may be more
attracted to an NS system, for example safety of life services, or
services that need real-time low latency such as a distributed recording
studio, or services that fail safe but have wide impact such as a rail
network controller are more likely to want this. On the other hand, the
back end systems of Acme corp will largely be fine with parallel best
effort mitigated across multiple providers.
- Stewart
On 28/07/2018 08:51, Dongjie (Jimmy) 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]] *On Behalf Of *Robert Raszuk
*Sent:* Wednesday, July 25, 2018 8:24 PM
*To:* Acee Lindem (acee) <[email protected]>
*Cc:* [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]
https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
