> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 > Xuxiaohu > 发送时间: 2012年9月28日 10:25 > 收件人: Lucy yong; Kireeti Kompella; Thomas Narten > 抄送: [email protected] > 主题: Re: [nvo3] Push or pull? > > Besides push and pull, please don’t forget the data-plane MAC learning > mechanism is also a proven choice for Layer2 overlay approaches.
Most importantly, the data-plane MAC learning mechanism can work well in both the push mode and the pull mode. For instance, in a push mode, if local MAC addresses are learnt by NVEs with the data-plane MAC learning mechanism, once some local MAC addresses are aged out, their corresponding MAC routes would be withdrawn accordingly. In this way, the NVEs in the push mode also don't need to store all MAC addresses within each attached VN instance. Meanwhile, in the pull mode, if the ingress NVE receives an Ethernet frame and finds no matching forwarding entry for that frame, the frame could be flooded by the ingress NVE as a normal bridge does before received a mapping response from the mapping system. Best regards, Xiaohu > Best regards, > Xiaohu > > > -----邮件原件----- > > 发件人: [email protected] [mailto:[email protected]] 代表 Lucy > > yong > > 发送时间: 2012年9月27日 22:41 > > 收件人: Kireeti Kompella; Thomas Narten > > 抄送: [email protected] > > 主题: Re: [nvo3] Push or pull? > > > > Hi Kireeti, > > > > I guess another dimension is that a VM in NV does not need to communicate > > with all other VMs in CUG, why NVE need to have all the endpoint locations > > even hardware is afford. They are difference between host and switch. Will > > NVE on server behave more like a group of hosts or a switch? > > > > Lucy > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf Of > > Kireeti Kompella > > Sent: Wednesday, September 26, 2012 5:01 PM > > To: Thomas Narten > > Cc: Kireeti Kompella; [email protected] > > Subject: Re: [nvo3] Push or pull? > > > > Hi Thomas, > > > > I'd like to focus on the following couple of points. Note that the goal is > > not > > whether push is better than pull; the goal is to find a metric where doing > > the > > work to achieve pull is worthwhile. > > > > On Sep 26, 2012, at 11:04 , Thomas Narten <[email protected]> wrote: > > > > > And what about for very large VNs where there is a lot of VM mobility? > > > Should all NVEs be required to get update info even for destinations > > > they don't care about? > > > > > >> 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? > > > > > > Are you really arguing that the difference between 1MB and 100 bytes > > > is just noise? > > > > Yes. But see below. > > > > > And who says this is in conventional memory on a host? > > > I could see this being done in the ASIC... > > > > I helped build some of those ASICs: eminently doable, fairly cost effective, > > simpler than implementing a new encap. But in any case, I thought the > point > > of overlays was to shield VM scale from ASICs (whole separate conversation). > > > > So, here's my attempt to quantify the cost of push by normalizing the cost > > per > > VM. This is all very naive and preliminary (for now), but the numbers, such > as > > they are, may speak for themselves. > > > > Let's go back to the case of a VN with 10,000 VMs (each with 4GB RAM); as > the > > worst case, assume each VM is on a different hypervisor. > > > > 1) assuming 100 bytes per route, the memory cost per VM (as above) is 1MB > > for FIB space. For a 4GB VM, that's a "tax" of 0.025% > > > > 2) For VM motion, each VM moves needs an update to 10,000 NVEs. > Assume > > each update is ~1000 bytes; that's a total of 10MB sent. Moving the VM is > > 4GB (or more) sent. The "tax" is 0.25%. > > > > 3) Processing an update message is a very small number of cycles. I don't > > know enough to compute the "tax" for this, but I'd guess very small. > > > > Clearly, there are other dimensions to this problem; folks might have better > > numbers or estimates. But so far, push is looking pretty good. > > > > So, is there a metric whereby push really hurts, and considering pull > > becomes > a > > necessity? Or is the suggestion to explore pull models as due diligence, > > irrespective of the need? Or ...? > > > > Thanks, > > Kireeti. > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
