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 a > L3 > > > > interface. VM has L2 interface only. This is about to address VM > > > > communication in a single nvo3 virtual network. assumption is to > not > > > > change VM network function. > > > > > > Regarding the first statement, I don't see it this way at all. I > > > assume that even for L3 service, where all tenant traffic is > assumed > > > to be IP, the interface between the TS and the NVE will still be L2 > > > Ethernet. However, the only allowed packets would be IP and ARP > (and > > > maybe DHCP and small number of other IP-related protocols sent at > > > L2). Any others would simply be discarded. > > > [Lucy] you need to configure an IP interface first for the service. > > Who is configuring what interface on what device? > > If you are referring to the VM and one of its interfaces, what VMs do > on their interfaces is outside of the scope of NVO3 -- I don't think > it matters to us. Right? > > > > To be honest, I'm not sure I understand what it means to have an > "L3 > > > interface" between the TS and NVE in the case where the TS is > getting > > > L3 service only. Does that mean the TS is sending packets that DO > NOT > > > have an L2 header in front of them? I.e., between the TS and NVE? > > > Because that would presumably require changes to VMs, it would seem > to > > > be a non-starter. And what would be the point? > > > [Lucy] This is not what I mean. I mean for L3 service, you need to > > configure IP interface. All the frames from/to VM are Ethernet > > frames. > > Again, which IP interface? On what device? > > Thomas _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
