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
