OK, I see we have different interpretations on NVE to have all the endpoint route. My interpretation is that although an EVI provides the communication among the VMs in a closed use group, it is not necessary for a VM to communicate to all other VMs in the group at a time or all time, therefore having each NVE to maintain all the endpoint routes in an EVI is not necessary. This is the concern I got from Sunny's mail.
Seem that you have different interpretation. Lucy -----Original Message----- From: Luyuan Fang (lufang) [mailto:[email protected]] Sent: Wednesday, September 26, 2012 4:00 PM To: Lucy yong; Shah, Himanshu; Thomas Narten; Kireeti Kompella Cc: [email protected] Subject: RE: [nvo3] Push or pull? Why does the VM need to change RT when it moves? Is not the VM supposed to stay in the same VPN and only changing location? The VM should keep the same RT in order to maintain the membership of that VPN it belongs to. Luyuan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Lucy yong > Sent: Wednesday, September 26, 2012 4:48 PM > To: Luyuan Fang (lufang); Shah, Himanshu; Thomas Narten; Kireeti > Kompella > Cc: [email protected] > Subject: Re: [nvo3] Push or pull? > > > > Why do you want to change RT on the fly? Would not that create security > issues? (And peer group or ORF don't change RT on the fly anyway). > [[LY]] to support VM mobility. What is an interested endpoint moving > from one NVE to another? > lucy > > RT-rewrite can be done when inter-connecting the VPN across two ASes > which are (or were) administrated by different administrative domains, > but they are carefully controlled/designed and configured by the > operators on the ASBRs or RRs. No RT change on the fly as I know of. > > Luyuan > > > > -----Original Message----- > > From: Lucy yong [mailto:[email protected]] > > Sent: Wednesday, September 26, 2012 4:13 PM > > To: Luyuan Fang (lufang); Shah, Himanshu; Thomas Narten; Kireeti > > Kompella > > Cc: [email protected] > > Subject: RE: [nvo3] Push or pull? > > > > RT is easy to define different topology, but not flexible to changes > on > > fly. Peer group or ORF is more about filtering setting, it may better > > fit here. > > Lucy > > > > -----Original Message----- > > From: Luyuan Fang (lufang) [mailto:[email protected]] > > Sent: Wednesday, September 26, 2012 3:10 PM > > To: Lucy yong; Shah, Himanshu; Thomas Narten; Kireeti Kompella > > Cc: [email protected] > > Subject: RE: [nvo3] Push or pull? > > > > > in push model, BGP peer group or ORF may be used to avoid every NVE > > to have all endpoint routes; > > > > In BGP VPN case, it is most efficient to use RT Constraint [RFC 6484] > > for selective route distribution - only send the VPN routes to the > peer > > who has the relevant VPNs. > > Luyuan > > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of > > > Lucy yong > > > Sent: Wednesday, September 26, 2012 4:03 PM > > > To: Shah, Himanshu; Thomas Narten; Kireeti Kompella > > > Cc: [email protected] > > > Subject: Re: [nvo3] Push or pull? > > > > > > I agree with Thomas. Both "push" and "pull" models have their > > > application space. To add on two points, in push model, BGP peer > > group > > > or ORF may be used to avoid every NVE to have all endpoint routes; > in > > > the pull model, an NVE will have temporary caching to reduce the > > number > > > of queries. > > > > > > Lucy > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of > > > Shah, Himanshu > > > Sent: Wednesday, September 26, 2012 2:46 PM > > > To: Thomas Narten; Kireeti Kompella > > > Cc: [email protected] > > > Subject: Re: [nvo3] Push or pull? > > > > > > I kind of agree with Thomas. > > > > > > Cisco gave LISP (pull based) presentation which is a working model, > > > during NVO3 interim. > > > I believe there are several ways to skin a cat and we should not > > limit > > > our options. > > > Besides, I also got an impression from the chairs that discussing > > > preference of one solution over other is > > > rather premature based on where the NVO3 is. > > > > > > Regards, > > > himanshu > > > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > Behalf > > Of > > > Thomas Narten > > > Sent: Wednesday, September 26, 2012 2:04 PM > > > To: Kireeti Kompella > > > Cc: [email protected] > > > Subject: Re: [nvo3] Push or pull? > > > > > > 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? > > > > > > I do not think we should say "push is good, pull is bad". That is > > just > > > too categorical a statement. > > > > > > > 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. > > > > > > > > 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? > > > > > > 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? And who says this is in conventional memory on > a > > > host? > > > I could see this being done in the ASIC... > > > > > > > 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. > > > > > > 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. > > > > > > 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. > > > > > > 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 > > > _______________________________________________ > > > 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
