Joe, I share the same view, or confusion - what new service type is discussed here? Typically, service is determined at the service inter-connect point, - if L2, it's L2; if L3, it's L3. However you transport the packets beyond that point within the networks does not change the service type. I don't see a new service type in nvo3.
Thx, Luyuan -----Original Message----- From: "Joel M. Halpern" <[email protected]> Date: Thursday, December 27, 2012 1:08 PM To: Lucy yong <[email protected]> Cc: "[email protected]" <[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 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
