Sorry Kireeti my spell checker hacked your name. Don
From: Fedyk, Donald (Don) Sent: Wednesday, September 26, 2012 3:45 PM To: 'Kireeti Kompella'; Sunny Rajagopalan Cc: [email protected] Subject: RE: [nvo3] Push or pull? Hi Kireeti I think what you are trying to say is. Push from an edge device what you know to a server/set of servers. Include your community of interests(route targets or whatever). Push from the server(s) to each edge device constrained by community of interests of that device. The second point is Community of interest granularity. That has to be at least as large as the set of devices that want to communicate. This is one push model that scales well. Don From: [email protected] [mailto:[email protected]] On Behalf Of Kireeti Kompella Sent: Wednesday, September 26, 2012 1:27 PM To: Sunny Rajagopalan Cc: [email protected] Subject: [nvo3] Push or pull? Hi Sunny, On Sep 25, 2012, at 14:57, Sunny Rajagopalan <[email protected]<mailto:[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
