> L2 NVE service type is about EVI, L3 NVE is about VRF. Would be good for us > to have a new type to differ from the two? From operator perspective, do you > agree?
IMO, this edge routing functionality can be formed by interconnecting an EVI (L2 forwarding instance) with a VRF (L3 forwarding instance) at the NVE. As others point out, this is just an implementation of IRB. However I'm not sure the current framework draft can represent such an IRB service since I don't see any mention of interfaces between forwarding instances (of same or different types) within the same NVE, but maybe I've missed something somewhere... Best -- aldrin On Mon, Dec 17, 2012 at 11:13 AM, Lucy yong <[email protected]> wrote: > Hi Aldrin, > > These (you and Yakov description) are exactly what I picture and think it is > better to represent this as a new NVE service type because this NVE not only > perform EVIes to attached TSes but also a router. > > L2 NVE service type is about EVI, L3 NVE is about VRF. Would be good for us > to have a new type to differ from the two? From operator perspective, do you > agree? > > > Thanks, > Lucy > >> -----Original Message----- >> From: Aldrin Isaac [mailto:[email protected]] >> Sent: Monday, December 17, 2012 9:07 AM >> To: Lucy yong >> Cc: [email protected] >> Subject: Re: FW: New Version Notification for draft-yong-nvo3-frwk- >> dpreq-addition-00.txt >> >> 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
