Kireeti,

How is the bridging and routing functionality you describe implemented on
say a hypervisor?  Would there be a routing instance (VRF) connected to one
or more bridging instances (EVI)?  I call this IRB, although I'm sure there
is a lot more involved with implementing it on dedicated hardware.

Also, given that (1) you want host specific routing because it gives
you the shortest path to anywhere, and (2) since IP is the Internet[work]
protocol (my networks, my partners networks, my services and the world in
general), it would seem to me that the NVE has a lot of /32 routing
information to bear.  What's the plan of aggregation, and then what of
shortest path?

Also, as I noted some time ago, currently IP routing is generally stable at
the expense of Ethernet since today router configuration is generally
static, whereas bridges have to deal with plug and play and lousy end
station software.  When the IP tables start churning, will IP still be the
good ole IP of yester year?

Best regards -- aldrin


On Monday, December 17, 2012, Kireeti Kompella wrote:

> On Dec 17, 2012, at 10:18 , "NAPIERALA, MARIA H" 
> <[email protected]<javascript:;>>
> wrote:
>
> > Intra-subnet traffic can be also handled by a layer 3 overlay.
>
> Let me expand.
>
> I see the need for E-VPN for non-IP traffic.  This is real, and is not met
> by IP VPNs (news flash!)
>
> For IP traffic, whether intra and inter-subnet, IP VPNs suffice.
>
> The solution is simple: route if IP, bridge if not.  Yes, one could do
> IRB, but why?  IRB brings in complications, especially for multicast.  I'm
> sure someone suggested this already, so put me down as supporting this view.
>
> A NVE that supports both E-VPN and IP VPN for a given tenant simply sends
> IP traffic to the IP VPN and sends the rest to E-VPN.  How this happens is
> implementation specific.  Note that this assumes that the NVE intercepts
> ARPs and responds to them with the same MAC.  Does anyone see a problem
> with this?
>
> If there is a case for _only_ intra-subnet traffic, one may create an
> E-VPN to handle both IP and non-IP; but I suspect this is a rare case.
>
> From that point of view, I would like to see E-VPNs in the data center
> *always* coupled with IP VPNs, and only dealing with non-IP traffic.
>
> This may appear drastic, but I think operationally, this is will simplify
> things.  As always, I am open to alternate suggestions, provided they are
> presented without religion or politics.  I'm especially keen to hear from
> those deploying.
>
> Kireeti.
>
>
_______________________________________________
nvo3 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nvo3

Reply via email to