Hi Thomas, On Sep 26, 2012, at 11:04 , Thomas Narten <[email protected]> wrote:
> Hi Kireeti. > > Kireeti Kompella <[email protected]> writes: > >> I'm glad you brought this up. Actually, this conversation has >> happened several times, to my knowledge, without a firm >> conclusion. I doubt we can close it, but at least, let's air it. > >> Push: send route updates to everyone (first see Aldrin's comment about >> RT Constraint) as soon as you (the AUTHORITY/ORACLE) get them. > >> Pull: sit on updates you get until someone asks for them. > >> I could try to convince you what a terrible idea Pull is. I could >> refer to the Internet, which is all Push, and scales reasonably >> well. > > You mean like DNS or ARP? DNS is not in the data path. ARP is, so good example. Another is Ethernet flooding to find MACs. Both are examples of Pull in the data plane, and I rest my case. :-) > I do not think we should say "push is good, pull is bad". That is just > too categorical a statement. 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: Is the savings (in whatever dimension) that Pull offers over Push worth the effort? If the answer (even theoretical) is Yes, sure, go for it. >> 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. >>> 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. <snipped, see next email> > I do not think we should today require that the NVO3 architecture (in > a MUST sense) support only push. I think we should allow for either > push or pull, or some combination. I can see benefits with both > approaches. No question. > 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? > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
