Hi Sunny, On Sep 25, 2012, at 14:57, Sunny Rajagopalan <[email protected]> wrote:
> 3) Even though it's not called out explicitly, the model used in both > draft-drake-nvo3-evpn-control-plane and draft-marques-l3vpn-end-system > assumes that the PE forwarding plane is interested in having all of the > endpoint routes in their participating VNIDs. In my view, this puts an > unnecessary load on NVEs. 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. I could tell you about companies that staked all on Pull, and aren't here any more to implore us not to go there. I could ask you what happens to packets while the Pull is being responded to, or a bunch of related questions. I won't. > 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? Here's my back-of-the-envelop calculation for memory, normalized to a VM. Let's say a VM has 10,000 friends in the DC that it might possibly want to talk to, but only one that it really wants to talk to. Let's say that a FIB route entry takes 100 bytes. That adds up to a possible total of 1MB vs. an actual of 100 bytes. Is 1MB really something one should optimize, especially considering that the VM has probably been allocated 4GB? Maybe there is a dimension to this that really is an issue. I would love to know, especially with numbers backing it up. But let's first convince ourselves that this is a problem worth solving before spending cycles solving it. Thanks, Kireeti
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
