-----邮件原件-----
发件人: 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
