> > > 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. > [Lizhong] Lucy, I don't think it is appropriate to name this as a new service type. The packets are still being processed by L2/3, no new processing happened on the packet. The only difference is the gateway location, on the local NVE or remote NVE. So I consider this as an implementation specific thing.
Regards Lizhong > 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
