> 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?
I assume that what is being discussed is a layer 2 overlay and a layer 3 overlay in a single solution, which is, I agree, different from a purely layer 2 overlay or purely layer 3 overlay. IMO, a solution that concurrently addresses both, layer 2 and layer 3 overlays, will introduce a lot of unnecessary complexity. This is because a layer 2 overlay does not just consists of carrying Ethernet headers end-to-end (about which end-hosts/IP applications don't care) but, by definition, includes the interoperability with IEEE bridged networks. Maria > > 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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
