Maria, > Yakov, > > > > Maria, > > > > > EVPN complexity lies in the interaction with bridging. For instance > > if one = > > > connects two EVPN access circuits with a physical wire (or bridges > > two VMs = > > > over a tunnel) you get a multihomed bridged site. Only one of the > > access po= > > > rts can be active or otherwise loops will form. > > > > > > But let's step back and look at the problem we are trying to solve. > > If majo= > > > rity (if not all) of traffic is IP and if majority of it is routed, > > wouldn'= > > > t it be better to develop a networking solution that is optimized for > > this = > > > majority of traffic (and not the vice versa)? > > > > > > The question is what problem does EVPN solve? In the context of DC, > > EVPN can > > > only address packets bridged in the same VLAN. If most packets are > > routed > > > then EVPN, even if all the complexity problems are addressed, doesn't > > achieve > > > anything for the traffic that is routed. > > > > The claim you made in the last paragraph above is factually incorrect > > - in the context of DC, EVPN can address *not* "only packets bridged > > in the same VLAN", but *also* can be used to provide (optimal) routing > > among VMs in *different* VLANs (different IP subnets). For more details > > please read section 6.1 of draft-raggarwa-data-center-mobility-04.txt > > (please note that what is described in 6.1 is applicable both in the > > presence and in the absence of VM mobility). > > This re-invents l3vpn with using l2vpn route advertisements and introduces a > possibility of extending the reach of a broadcast domain beyond a single > subnet. The question is why to introduce a new paradigm for routing? > > When traffic crosses between CUGs this traffic is IP routed (naturally > and optimally addressed by L3VPNs). Within a CUG the traffic is handled > the same way whether one implements EVPN or L3VPN (no visible difference). > The only question remaining is how to address non-IP traffic (in DCs that > carry or care about non-IP traffic). A solution should use EVPN only > when necessary to handle non-IP traffic. As Kireeti described it: "route > if IP, bridge otherwise".
If we are to consider DC where we have a mix of IP and non-IP traffic, then *within the DC* there are (at least) the following two options: 1. Service provider deploys both E-VPN and L3VPN; E-VPN is used solely to implement L2-based CUGs for non-IP traffic, all the IP traffic is handled by L3VPN 2. Service provider deploys E-VPN, which handles both IP and non-IP traffic. > In addition, the reference above (section 6.1) does not address one > of the main requirements in a service provider's cloud computing > environment which is a seamless integration with MPLS/BGP layer 3 > VPNs in the WAN and the wireless acc ess networks (pointed out by > Robert). Section 6.2.2 describes integration between E-VPN and 2547 VPNs. Yakov. _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
