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
