Not clear what your interpretation has to do with change RT when VM moves... Anyway, if a NVE does not even know what RTs/VPNs he has, maybe he should be fired? :-) Luyuan
> -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Wednesday, September 26, 2012 5:22 PM > To: Luyuan Fang (lufang); Shah, Himanshu; Thomas Narten; Kireeti > Kompella > Cc: [email protected] > Subject: RE: [nvo3] Push or pull? > > 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
