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. 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. Second, this also require both L2 and L3 interworking mechanism on TS mobility. 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. I also think that the provisioning topic is a red herring: [Lucy] what do you think about SDN? > 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. 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? 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
