Lucy, > 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.
No. I said that that this is unnecessary complication. > 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. Intra-subnet traffic can be also handled by a layer 3 overlay. Maria > > -----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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
