> > Scenario-1 doesn¹t require any DCI solution and doesn¹t require any > > interop to IP-VPN > > Scenario-2 requires a DCI solution w/o maintaing an IP-VRF at the GW > > Scenario-3 requires a DCI solution that needs an IP-VRF at the GW > > Scenario-4 requires inter-op between EVPN and IP-VPN
Let me try to clarify a bit on what I'm asking, perhaps -- - Scenario-1 is essentially using eVPNs as a DCI solution across the "WAN." This is simple, just extend the eVPN domain, and is a natural progression from a "within the DC" eVPN devployment, so I'm not really certain why it needs to be discussed (?). I think maybe the point here is to bring out the "aggregated" and "not aggregated" cases, but those could occur within a data center -- and there are problems with the way these are described (IMHO, anyway -- but that's a separate discussion). - Scenerio-2 and Scenerio-3 seem to be a layer 2 connection other than eVPNs connecting the eVPN deployments; both require some sort of interop between the two layer 2 domains, generally speaking some sort of gateway that will interconnect them. This is identical to the case where you have VLANs and eVPNs running within the same data center, and need a "gateway" between the two. - Scenerio-4 appears to be "there is only a layer 3 IP-VPN connection (L3VPN?) between two eVPN segments." This could easily arise within a single data center -- there's no reason to postulate a "WAN gateway," in this case. There's the default gateway, after which the packet is routed -- there might be ways to optimize the routing, but that seems to be outside the scope of eVPNs (?). So -- I don't really know why all of this needs to be put in the context of inter-DC connectivity (or DCI). Each of these situations would/could also arise in the context of a single data center. Russ _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
