Hi Joe, My original point is that NVO3 aims on the capability to provider multi tenant virtual networks on a common infrastructure, where a tenant virtual network may contain one or more subnets. To support a multi-subnet tenant virtual network, one way to do is to integrate both bridging and routing on every NVE that has the membership of the network virtual instance. Somehow, I don't see either L2 NVE service type or L3 NVE service type fit into this, so suggest a new type.
What you describe is correct. If you plug a host into an Ethernet switch, the host connects a network via a layer 2 service and the host can reach a different subnet via a L3 service. In this case, the layer 2 service has local significant as if Ethernet switch. To construct a multi-subnet tenant virtual network, operator has to construct many layer 2 service instances and L3 service instance for the tenant. When both L2/L3 service functions resides on a NVE, if we just create a L2/3 virtual network instance with multi-subnets for a tenant, will it be much simpler for an operator? Regards, Lucy > -----Original Message----- > From: Joel M. Halpern [mailto:[email protected]] > Sent: Thursday, December 27, 2012 3:08 PM > To: Lucy yong > Cc: [email protected] > Subject: Re: [nvo3] Multi-subnet VNs - should be a new service type? > > Lucy, I wonder if I am misunderstanding your point. (Or maybe I am > missing something basic about NVO3.) > > If I take a host, and plug it into an Ethernet switch, te "service" it > gets is a layer 2 interconnect service. That is still the case even if > there is also a router attached to that Ethernet switch. And it > remains > the case even if the router happens to reside in the same device, and > use the same physical ports, as the Ethernet switch. (The router logic > provides an L3 service. The Ethernet switch provides an L2 service. > Where the router resides is network and implementation dependent.) > I don't understand why NVO3 would change this logic. > > I do not think that anyone who has discussed L2 service for datacenters > (inside or outside NVO3) has ever asserted that an L2 service can not > be > interconnected at L3. > > Yours, > Joel > > On 12/27/2012 1:10 PM, Lucy yong wrote: > > David, > > > > *From:*Black, David [mailto:[email protected]] > > *Sent:* Thursday, December 27, 2012 11:42 AM > > *To:* Lucy yong > > *Cc:* [email protected] > > *Subject:* RE: Multi-subnet VNs - should be a new service type? > > > > Lucy, > > > > The core of our disagreement is here: > > > > */[Lucy] We have either L2 overlay network or L3 overlay network. But > > sometime a tenant network needs both L2 and L3 functions to > accomplish > > the needs, where neither L2 overlay nor L3 overlay fit it well. /* > > > > I strongly disagree with the statement that an L2 overlay is a poor > fit > > for carrying tenant IP traffic that needs to cross L2 (virtual) > network > > boundaries. That sort of IP traffic that needs to cross L2 network > > boundaries works fine on VLANs and it works fine on L2 overlays. > > > > */[Lucy] I did not say it is poor fit, and just express if you > integrate > > L2 function and L3 function on the same NVE, it is better to give a > new > > NVE service type. Obviously, we have disagreement here. /* > > > > I would agree that there are ways to implement routing support for > > traffic that exits an L2 virtual network that are poor fits to some > > situations (e.g., lengthy discussions here and elsewhere on trombone > and > > triangle routing), but I do not see the need for a new hybrid L2-3 > > service definition to enable better implementations of routing > > integration with L2 networking. > > > > And my answer to this question: > > > > */[Lucy1] For this service capability, do you see it as a L2 service > or > > L3 service? IMO: neither of them fits./* > > > > is that it's still an L2 service, in part because it makes no sense > to > > me to restrict an L2 service (at least for nvo3) by forbidding the > > attachment of IP routing functionality to L2 (virtual) networks. > > > > */[Lucy] No, such restriction is not good. L2 switches have been used > to > > bridge IP traffic between router and hosts for long time. We are on > the > > same page here./* > > > > *//* > > > > */Thanks,/* > > > > */Lucy/* > > > > Thanks, > > --David > > > > *From:*Lucy yong [mailto:[email protected]] > > *Sent:* Thursday, December 27, 2012 11:55 AM > > *To:* Black, David > > *Cc:* [email protected] > > *Subject:* RE: Multi-subnet VNs - should be a new service type? > > > > David, > > > > Please see in-line with [lucy1] > > > > Hi Lucy, > > > > I'm going back to the original question of whether we need a new > service > > type, and starting from a couple of comments from you on how the > > proposed new L2-3 service works ... > > > >> 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. > > > >> 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. > > > > I observe that these describe exactly how the currently-defined L2 > > service works - bridge the frame to the L2 destination, and route it > > beyond there if the L2 destination happens to be an L3 router. > > > > */[Lucy] Yes, you state correct. How does a tenant system to know the > > MAC of a router? It uses arp protocol and L2 service is transparent > to > > arp protocol. What this lead to that even two TSes in the different > > subnets attaches the same NVE, the traffic between two has to be > routed > > via an L3 router./**//* > > > > [David] For clarity - it has to be routed via a **logical** L3 router, > > which could be part of an NVE. That logical routing functionality > has > > to be provisioned and configured independent of whether the two > subnets > > are in different service instances or the same service instance in > the > > architecture. > > > > */[Lucy1]OK, I understand. For this service capability, do you see it > as > > a L2 service or L3 service? IMO: neither of them fits./* > > > > */If you choose to have a lot of routers and push the router function > > close to NVE for a tenant network, this problem is not a problem. > > However, this will make operator nightmare because you have to > configure > > many L2 and L3 services. /**//* > > > > [David] I think you've missed the point. If there are multiple > subnets > > across which traffic has to be forwarded, the routing functionality > to > > forward that traffic has to be configured. > > > > */[Lucy1] If this is the case, you may want to choose few router > > locations to avoid massive configuration. This is the case where > routing > > function is outside hypervisor and on some routers. /* > > > > */Second, this also require both L2 and L3 interworking mechanism on > TS > > mobility./* > > > > [David] What do you mean by "L3 interworking"? > > > > */[Lucy1] If your case is that the L2/L3 are paired and co-exist on > the > > same NVE, this does not apply to your case. do you think it would be > > more clear to express this case with a new NVE service type? /* > > > > Beyond that, the discussion around where the router is located and > > whether it's distributed among multiple nodes, e.g., NVEs, is an > > implementation discussion, not a service definition discussion. To be > > specific, just spreading such a router (e.g., default gateway) across > > the NVEs need change the service that is provided; please see VRRP > for a > > worked example of this sort of distribution, and VRRP does not change > > the service definition in the sense that nvo3 is using the term > "service". > > > > */[Lucy] Do you say "need change" or "not need change" here? IMO: if > > using distributed routing, it is very different from designated > routers > > design. Both are very useful for the operator, and it would be nice > to > > distinguish two in overlay./* > > > > [David] "need not change" was intended, sorry for the typo. I agree > > that solutions will have to spell out the router structure in detail, > > but I'm at a loss for why the service definition has to care. > > > > */[Lucy1] IMO: we are working on overlay networking. We have either > L2 > > overlay network or L3 overlay network. But sometime a tenant network > > needs both L2 and L3 functions to accomplish the needs, where neither > L2 > > overlay nor L3 overlay fit it well. We can let operators to combine > two > > overlay networks to accomplish the task. But this is not help in > > positioning these functions in standard development and causing some > > confusion here and there. Furthermore, IMO: it brings a complexity > for > > operators. /* > > > > I also think that the provisioning topic is a red herring: > > > > */[Lucy] what do you think about SDN?/* > > > > [David] I think it's orthogonal to this thread of discussion about > > whether provisioning provides a rationale for defining a new service > > type in the framework. > > > > */[Lucy1] This is not what I mean. I agree that SDN is not the reason > > for the new service. Let's stop here./* > > > >> Without it [new service type], 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. > > > > That really does not require a new service type. Rather, a single > > sentence ought to suffice to state that orchestration functionality > > (e.g., software) may provision multiple virtual networks as part of a > > single larger provisioning operation. > > > > */[Lucy] optimizing operation is attractive for operators. /* > > > > [David] and that optimization can be done via provisioning software > that > > iterates over the virtual networks that need to be provisioned. > > > > */[Lucy1] you mean planning tool. I do not think this will work well > for > > the dynamics in DC, i.e. TS mobility in real time./* > > > > In contrast, there may be a new service type in the discussion of > "route > > before bridge" because when traffic can be bridged at L2, routing > that > > traffic at L3 may remove L2 adjacency information, and the discussion > of > > use of EVPN for traffic that suffers from that removal then follows. > I > > would hope that this topic can be deferred in the same fashion that > (I > > hope) non-transitive L2 connectivity (e.g., L2 stations A and B are > in > > VN 1, stations B and C are in VN 2, A can talk to B, B can talk to C, > > but A can't talk directly to C at L2) has been deferred. > > > > */[Lucy] this is the hub-spoke. Why do we need to defer this? /* > > > > [David] I'm concerned that it will lead to a long discussion about > > redefining exactly what an L2 Ethernet service is and how it differs > > from various IEEE 802 definitions. > > > > */[Lucy1] Thank you to bring this point. If we have a new service > type, > > that will be different from L2 Ethernet service. We can keep the L2 > > overlay service is exactly same as the L2 Ethernet service defined in > > IEEE. If not, for the scenarios you picture here, it does not belong > to > > the L2 Ethernet service nor IETF defined L3VPN service. You either > > change these services or distinguish it from these two./* > > > > */Thanks,/* > > > > */Lucy/* > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Distinguished Engineer > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > [email protected] Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > > > > > > > > _______________________________________________ > > nvo3 mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/nvo3 > > _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
