Well said! Just a few anecdotal data points and an opinion or two.... On Sep 18, 2012, at 11:46 PM, Robert Raszuk <[email protected]> wrote:
> 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. One result of the disconnect between the DC and WAN camps: requests from WAN customers to be able to detect and collect basic statistics on VXLAN/etc activity passing through is ever increasing. > >> 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. As long as the number of core per host increases, the number of VMs per host will also increase. No cap should be assumed. > >> 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. _yes_ > > >>> 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
