Maria, It seems that you agree this is necessary for a tenant virtual network, i.e. a layer 2 overlay and layer 3 overlay in a single solution. However, I don't get if you want to have a new service type for the solution or not.
Without it, it means that, for creating a tenant virtual network that contains multiple subnets, operators have to create individual layer 2 overlays and layer 3 overlay and specify the interfaces to interconnect them, etc. I like to know your preference as an operator. Thanks, Lucy > -----Original Message----- > From: NAPIERALA, MARIA H [mailto:[email protected]] > Sent: Monday, December 17, 2012 11:41 AM > To: Lucy yong; Aldrin Isaac > Cc: [email protected] > Subject: RE: [nvo3] FW: New Version Notification for draft-yong-nvo3- > frwk-dpreq-addition-00.txt > > > 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
