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] <javascript:;>] > > Sent: Friday, December 14, 2012 1:58 PM > > To: Lucy yong > > Cc: [email protected] <javascript:;> > > 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
