For VM there is no need to send AC (ESI) route since the notion of a VNIC LAG doesn't make sense. ESI route to indicate AC is used when there is a need for multi-homing. So specifically for a single VM there is only MAC route.
On Wed, Sep 26, 2012 at 6:11 PM, Shah, Himanshu <[email protected]> wrote: > Attachment Circuit to that EVPN instance may not exist either, when VM moves > to different host. > > The need to sprout AC was noted in the NVO3 interim meeting as part of gap > analysis on L2VPN based solution. > > > > /himanshu > > > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > Luyuan Fang (lufang) > Sent: Wednesday, September 26, 2012 5:51 PM > To: Sunny Rajagopalan; Lucy yong > Cc: Kireeti Kompella; [email protected] > > > Subject: Re: [nvo3] Push or pull? > > > > Ø The RT could change when the VM moves, in case the VM moves to an NVE > which wasn't previously subscribed to the VPN that the VM belongs to. > > > > Not correct. The RT does not change when VM moves, or it breaks VM mobility. > > When you move the VM to a new NVE which does not have the VPN the VM belongs > to, the VPN/VRF/RT… need to be configured on the new NVE. The RT of the VM > does not change. > > > > Don’t we need to config the relevant VN/VPN on the new NVE which does not > have it yet, regardless the model? > > > > Luyuan > > > > From: [email protected] [mailto:[email protected]] On Behalf Of > Sunny Rajagopalan > Sent: Wednesday, September 26, 2012 5:35 PM > To: Lucy yong > Cc: Luyuan Fang (lufang); Kireeti Kompella; [email protected] > Subject: Re: [nvo3] Push or pull? > > > > There's two different topics being talked about here: > Push, which can be optimized using RTs. RTs can be used to ensure that an > NVE only receives routes for the VPNs it participates in. The RT could > change when the VM moves, in case the VM moves to an NVE which wasn't > previously subscribed to the VPN that the VM belongs to. Due to the state > this creates in the route server, you would want to use it at a VPN-level > granularity. > > Pull, which works by the NVE requesting the route server to "please give me > endpoint information about address X in VPN Y". This doesn't result in > additional state at the route server, and the route server doesn't push > locators for any other end points in that VPN. > > I think we're reaching consensus that both are needed, right? > > -- > Sunny > > > > > From: Lucy yong <[email protected]> > To: "Luyuan Fang (lufang)" <[email protected]>, "Shah, Himanshu" > <[email protected]>, [email protected], Kireeti Kompella > <[email protected]>, > Cc: "[email protected]" <[email protected]> > Date: 09/26/2012 02:22 PM > Subject: Re: [nvo3] Push or pull? > Sent by: [email protected] > > ________________________________ > > > > > 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 > > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
