On 28/07/2018 20:34, Greg Mirsky 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;
I agree up to here.
* "hard" slices would span within a single access and/or metro domain.
I agree that this is likely to be the majority case, but would not rule
out a larger network
for some applications.
* Networking solutions likely will be coupled with architecture and
interfaces developed in Multi-access Edge Computing (MEC).
That is true, but may not be exclusively true.
- Stewart
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
<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
