Hi Patrick,
> Somewhat true, it depends on the DC. Many enterprise DC and hosting
providers DC are disconnected from the WAN - the ISP offers the WAN
connections and the DC uses a different "signalling mechanism for
their network, such as STP ;.)
To clarify ... by integration with WAN I meant a case of service
provider who already offers VPN service for enterprise X to also offer
DC services for the same enterprise X.
One could be very correct to ask if such enterprise X will not be better
to use DC services outside of their VPN SP, but they are free to do that
today anyway.
Not that many uses MPLS inside their DCs, a few though.
There is huge not widely recognized difference between using MPLS for
forwarding and using MPLS for applications as a demux tag.
While I can agree that the former is pretty much over .. too many
architectural scaling and overhead protocol issues the latter is clearly
IMHO as good as using any other value for demux .. be it GRE key in
NVGRE or VXLAN.
Also the WAN
network and DC network are usually in different management domains.
Very true .. that's why the right interconnect model must consider such
separation. And among most VPN interconnect models it seems that option
B (with its A's flavor when needed) is gaining momentum today in DC
interface to the WAN.
But the liveness detection of the path must be handled somehow by the
encapsulation scheme, right?
Well .. not by the encapsulation itself. It could be control plane or
data plane based. Encapsulation scheme is orthogonal.
For control plane there are number of solutions already today.
For data plane to be fair in practice there is only one - LISP.
If that is the case, should that be taking care of the network or the
endpoints? By locating the NVE as far at the edge the tunneling scheme
will scale quite well depending on how many VMs you are allocating per
NVE (x86 platform) - 10, 50, 100?
Agree 100%. So while some still trying to see NVE in the network IMHO
and maybe not so humble it seems clear that NVE should be on the host.
Is 100 max number of VMs you can squeeze out of the host .. I think it
really depends on your host.
My background is also from BGP/LDP based L3VPN and L2VPN and I have
some experience with SIP, trying to think out of the box
That's always great. And while I admit I do not have any SIP experience
other then playing with my SIP phone to get connected to the SIP gateway
I think thinking out of the box is the most valuable feature.
Agree. SIP would only keep track of where the VMs are located. Turning
this around, what new services would a BGP based L3VPN and L2VPN offer
in the DC? We have been on this path for the last 10-15 years on the
WAN side and some experience with a few DCs.
Ahhh you are touching very sensitive space on what new services model
will be .. I think we do not know. We do not even know if new services
will use traditional/legacy network model or new emerging one be it
openflow based or forces based.
One thing is clear .. the NVO3 architecture should be compatible with
any service virtualization mechanism. And again putting virtualization
to the end hosts for tenants or for appliances seems like the easiest
way to accomplish the compatibility with the future.
As said above I am not sure the "rushing" is right term. If you look at your
requirements from operators point of view we have customers interconnected
with L3 or L2 VPNs. Adding seamless DC to their services is a very important
service.
Which operators do you refer to - enterprises, ISP, telcos, cloud,
hosting providers?
I mean SPs/ISPs/Telcos with both VPN and internal cloud services.
Rgs,
R.
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3
