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. 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”. I also think that the provisioning topic is a red herring: > 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. 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. 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
