> Okay. How about: Push is simple and known to work; but it costs. > Pull is harder, but may be cheaper. Still a very broad statement, > but it allows the following question:
I think it's not particularly useful to have a high-level discussion about whether something as general as "push" vs. "pull" will work or not. Push vs. pull are just two approaches. They both have plusses and minuses. To decide which makes sense (and in what context), you have to look at the overall problem, requirements, and a whole bunch of factors. And different folk may weigh various factors differently. I'm not saying push can't work. In fact, I'm sure it can. But just because it can work, doesn't mean other approaches should be ruled out. > Is the savings (in whatever dimension) that Pull offers over Push > worth the effort? I think so. At least, I don't want to see it ruled out up front. > >> I could ask you what happens to packets while the Pull is being > >> responded to, or a bunch of related questions. I won't. > > > > They get queued. Or dropped. Or possibly something else. Yes, there > > are implications to that. But not necessarily a show stopper either. > It was a show-stopper for Ipsilon. Now there is a soundbite. But I'm not sure exactly how that applies here... > >>> In my view, this puts an unnecessary load on NVEs. > > > >> Let's talk instead about the "unnecessary load". Can someone quantify > >> this? Is it CPU? memory? messaging? What's the bottleneck or pain > >> point? > > > > Some or all of the above. > > > > If typical VNs are smallish, I agree that an NVE can preload full > > tables with no problem. But what about for very large VNs? Should the > > architecture *force* such preloading of full tables, even if the > > working set of routes is actually very small? > I thought I picked a fairly large VN, with 10,000 members. Even if > you take a larger one, say 100,000 members, the memory cost is (imo) > small. It's not just memory, there is also the signalling cost. And if you have 10K VMs, no doubt at any one time some (more?) are moving around, with the corresponding signaling (using push), going out all the way to *all* NVEs. > <snipped, see next email> OK. > > Note also that we may be looking at the problem from different > > perspectives. For example, in a single data center, I can imagine a > > centralized directory service holding the complete address mapping > > information for all the VNs in the DC. An NVE in such cases can query > > such a mapping system with very very low latency. > Perhaps so (I would love to get more details.) But what did you gain? Um, some large data centers already have centralized components. Like the entire VM orchestration system. Adding more to that centralization doesn't necessarily change the single point of failure/risk factor in a substantial way. E.g., in the ARMD discussions, one large operator said they'd like to centralize more of that info, and reduce the signaling (which was effectively redundent). There was little benefit in dynamic use of ARP, for instance, when all addresses and their locations were already known centrally. Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
