Re: [nvo3] Multi-subnet VNs [was Re: FW: New Version Notification for draft-yong-nvo3-frwk-dpreq-addition-00.txt]

[Yakov Rekhter <[e-mail]>]

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.