Hi Lucy, More inline.
Thanks, --David From: [email protected] [mailto:[email protected]] On Behalf Of Lucy yong Sent: Wednesday, December 26, 2012 1:52 PM To: Black, David Cc: [email protected] Subject: Re: [nvo3] Multi-subnet VNs - should be a new service type? Hi David, Glad to see joining the discussion. I modify the subject a bit before we reach the consensus. Please see inline. From: Black, David [mailto:[email protected]] Sent: Wednesday, December 26, 2012 11:45 AM To: Lucy yong Cc: [email protected]<mailto:[email protected]> Subject: Multi-subnet VNs - not a new service type 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. 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. Second, this also require both L2 and L3 interworking mechanism on TS mobility. [David] What do you mean by “L3 interworking”? 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. 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. > 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. 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. 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
