Here's some perspective from Yakov on another thread.... "In the context of DC each NVE could provide router functionality (e.g. EVI+IRB). So, each NVE, in addition to acting as an EVI, can act as a router for VMs behind this NVE."
Best regards -- aldrin On Fri, Dec 14, 2012 at 10:16 PM, Aldrin Isaac <[email protected]> wrote: > Lucy, pardon me for using IPVPN and EVPN language, but can the bridging with > edge routing functionality that you are describing be implemented on an > access PE as a localized L3 VRF with interfaces to one or more local L2 EVI? > This would require that all L2VN to which edge routing is desired would need > corresponding local EVI (and all associated MACs) on the PE even if these > L2VN have no local VM. Is this the functionality you want to see > represented? Best -- aldrin > > > On Friday, December 14, 2012, Lucy yong wrote: >> >> Tom, >> >> The use case is simple. One tenant virtual network may contain more than >> one subnets. Each subnet presents a broadcast domain. The TS in the network >> can send traffic to another TSes that may be on the same or different >> network. A BD provides simple communication mechanism. Please look at >> Microsoft Hyper-v implementation. It is already implemented. NVo3 use case >> draft also describe it. >> >> Regarding your question on how NVE to know if it should use L2 or L3 info. >> on the frame, this is back to the basic communication rule TS uses. TS send >> a frame to the destination directly if it is on the same subnet and send a >> frame to the gateway if the destination of the frame is not on the same >> subnet. In this new service, NVE plays the gateway rule. TS uses the arp to >> know the gateway address. When a frame is designated to the gateway, thus >> NVE knows that it should perform IP lookup on it, otherwise, it forwards >> based on MAC address. This is like IRB feature. When NVE perform IP lookup >> and find the corresponding destination TS MAC as well as remote NVE IP >> address, NVE has to replace gateway MAC address with TS MAC address and put >> tunnel addresses before sending out. >> >> You say to forward both intra and inter subnet traffic by using L2. Yes, >> it is simple. But TS does not behave this way. It forwards inter subnet >> traffic to the gateway first. This is my understanding. If we use the L2 >> service, where is the gateway? >> >> The new service type is to allow ingress NVE performs some routing. It is >> the L2/3 gateway for the TSes. But from TS perspective, it attaches a LAN or >> VLAN, not router. >> >> Regards, >> Lucy >> >> > -----Original Message----- >> > From: Thomas Narten [mailto:[email protected]] >> > Sent: Friday, December 14, 2012 1:58 PM >> > To: Lucy yong >> > Cc: [email protected] >> > Subject: Re: [nvo3] FW: New Version Notification for draft-yong-nvo3- >> > frwk-dpreq-addition-00.txt >> > >> > Lucy, >> > >> > > Tom, >> > >> > > > >> > > > > [Lucy] No, this is not what I mean. I mean we need a new service >> > > > > type to be able to support a single NVo3 virtual network that >> > > > > contains both cases via a L2 interface. >> > > > >> > > > By "both cases", do you mean both L2 service and L3 service? >> > > > >> > > > That is, do you mean a single Virtual Network, where TSs are >> > > > sending/receiving L2 frames, but in some cases the NVE treats them >> > as >> > > > IP (forwarding them based on their TS IP header) while in other >> > cases >> > > > they are treated as L2 (where the NVE forwards them based on the TS >> > L2 >> > > > header and doesn't look at the IP header (if there is one)?) >> > >> > > [Lucy] Yes, this is what I mean. But I don't want to use two >> > > services to construct a tenant virtual network in some case. Can I >> > > just use one service to achieve it? >> > >> > I'm not at all sure it makes sense to mix and match L2 and IP service >> > on the same Virtual Network. Seems to me, that if you have some >> > traffic that needs to be forwarded at L2, just forward it all using >> > the VM's L2 addresses. This works. Doesn't matter if payload is IP or >> > not. Keep it simple. >> > >> > If you forward *some* traffic using L2 information, but other TSs >> > expect only L3, what is supposed to happen? This isn't going to work >> > right. Why would you even allow such a model? >> > >> > But before looking at the problems with such an approach, what I'd >> > really like to understand is what the use case is for such a mixed >> > model on a single VN. Not just "why not", but what is the real use >> > case. If there isn't one, I'd prefer that it just not be supported as >> > doing so will surely add complexity ... and if there is no real need >> > or benefit, then why? >> > >> > > > And can one TS send *both* types, or does a TS have to pick one >> > format >> > > > (always) with different TSs on the same VN possibly choosing >> > different >> > > > services? >> > >> > > [Lucy] Yes, one TS can send a frame to a TS that is on the same >> > > subnet, it can also send a frame to a TS that is on the different >> > > subnet. >> > >> > You didn't answer the question I'm trying to ask. The question I'm >> > asking is how does the NVE know (when it gets a packet) whether to >> > forward it using the L2 information or the L3. It has to pick one (for >> > each arriving packet). How does it know? Is the NVE supposed to know, >> > for example, what subnets look like from a VM's perspective (I would >> > argue that is not a good designe and has a bunch of issues). >> > >> > And per above, if you just always forward on L2 info, you can make the >> > intra- and inter-subnet case work. So why not just do that? >> > >> > > > If so, the WG has discussed this case before - and there are issues. >> > > > One issue is how does an NVE know whether to forward a packet >> > received >> > > > from the TS using the packets L2 header vs. its IP header? For an >> > IP >> > > > packet, it will have both headers, and depending on which choice is >> > > > made, you might get different forwarding behavior. That would >> > probably >> > > > not be good. >> > >> > > [Lucy] You get it. But a frame from TS have both Ethernet and IP >> > > header. From TS perspective, the frame to the TS on the same subnet >> > > will be bridged, the frame to the TS on the different subnet goes to >> > > the router. We need to a service to guarantee that. >> > >> > I am assuming that NVO3 networks providing IP service to tenants will >> > have to embed at least limited routing capability. Enough to handle >> > the "inter-subnet" case. But I can also imagine this being done on the >> > ingress NVE, in which case, there is no penalty or "extra hop". I.e., >> > the ingress NVE recognizes that a packet is being sent to a router, >> > and just forwards the packet directly to where its supposed to go. >> > >> > That is, although architecturally a Virtual Network MAY need to have >> > an internal router to handle inter-subnet forwarding with an VN, this >> > can be implemented at the ingress NVE and doesn't need to add much, if >> > any overhead. >> > >> > Is there a reason why that wouldn't be good enough? >> > >> > > > > [Lucy] L2 service assumes a L2 interface and L3 service assume _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
