Hi Robert On Wed, Sep 19, 2012 at 9:46 AM, Robert Raszuk <[email protected]> wrote: > Hi Patrick, > There is huge not widely recognized difference between using MPLS for > forwarding and using MPLS for applications as a demux tag. >
Aah, I see - that would need to compatible with the customer WAN VPN and the DC VPN so the application tags matches. I find this useful but it most likely would require an upgrade of switches/routers at the branch offices. > >> 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. > Option AB is interesting, have used it. > >> 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. > Agree, LISP DDT as the control plane solution and LISP data plane as the liveness detection mechanism. However, it might become quite complicated With BGP we could use the same liveness detection mechanism as in MPLS L3VPN, which is to have the loopback of the PE (NVE) in the IGP of the underlying network. How many many NVE /32 routes can we have in the IGP of the underlying network, 8000, 16000? Aggregates at IGP ABRs is not an option, AFAIK. Or should you replace the IGP with Openflow and a centralized controller in order to preserve FIB entries at the ToRs or simple install ToRs with larger FIBs? (I prefer to use IGP and IP FRR mechanisms, I'll avoid Openflow solutions that are aiming to replace distributed routing protocols). Can we simplify these approaches somehow? Maybe, but it requires more research work and not sure if that work is suitable for this WG, perhaps it should be done at IRTF instead? The idea is to have a multipath transport protocol between the NVEs and treat the underlying network as resource pool; Mark's presentation changed my view on networking some time ago, see http://www.ietf.org/proceedings/72/slides/RRG-2.pdf Deploy SIP to keep track of where the VMs are attached to the NVO3 "fabric". The drawback is that you have more state information at the NVE, not for each tunnel but for each PR-SCTP association between the NVEs. Here is scalability issue but I think SDN can help here, see my next comment. > >> 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. > It depends on your host, your SLA and how much bandwidth you have on your private network to move your VMs to another host when the primary host fails. If you have a lot of DRAMs on your host it will take some time before e.g. VMs on a 512 GB DRAM host is moved to another host. The more VMs you put on your host to bigger pipe on your private network you need in case of a host failure, depending of course on your SLA. If you have a fat DRAM host, best effort SLA (don't care how long the VM migration takes) and a lot of VMs then you could end up with a lot of PR-SCTP tunnels to adjacent NVEs. Here should SDN kick-in. The SDN controller should keep track of VMs that are in the same CUG, optimize the the placement of the VMs so that they are located within the same rack. We might achieve the following: - within the rack deploy legacy L2 switching, 4000 VLANs should be enough inside the rack - if customers deploy the common web-app-db application architecture this traffic will stay within the rack, expensive backbone bandwidth is preserved - when the web-app-db traffic stays within the rack the end user should gain a better experience since the latency is lower than having the web-app-db resources scattered over the NVO3 backbone - we can minimize the amount of PR-SCTP associations for the NVE3, so having 100 VMs on the node do not necessarily mean 100 tunnels. - NVE/PR-SCTP leverages the underlying network as a resource pool This is an early idea, so there are a lot things to sort out. Patrick _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
