Hi,
Again, please keep in mind the intended status and the content of the
document: adopting it and progressing it as an *informational* RFC does
not mean that there is consensus that this approach is the best way, or
even a right way, to address a particular use case. As currently
shaped, the document does a pretty good job of making this clear. This
is a place to document an approach, including its limitations.
My take is that we're better off documenting all this, rather than just
have this approach deployed with no documentation.
-Thomas
2014-02-11, Thomas Nadeau:
On Feb 11, 2014:9:22 AM, at 9:22 AM, Robert Raszuk <[email protected]
<mailto:[email protected]>> wrote:
Giles,
> Of course one may say that I can use L3VPN or L2VPN no need for
something in the middle - fair point. But in the same time this
is different from prohibiting one to inject some host routes and
do proxy arp for pair of VMs which like to talk on the same
subnet but happen to be sitting on different compute nodes.
but as you yourself have said - if there's no need for it then
why add it? There are many different ways those two VMs can
communicate already. I'm not sure we need to invent another
And that is reasonable discussion to have here rather then argue that
BGP does not scale without providing pain points or that routers
behind VM need to talk L2 to other routers behind VM (the latter is
in fact possible via overlay over overlay today anyway if someone
would desire so).
This is indeed the discussion we want to have here. I don't think
Giles or I were claiming BGP doesn't scale; again, its a matter of
whether or not you would want to send /32s around as prescribed.
--Tom
You may be of opinion that current EVPN or PBB EVPN solve the
problem. I agree they solve the problem, but the price is much higher
- new development and new protocol extensions are needed to support
it. Operating one more protocol is not free too.
Here we just have a informational draft illustrating much cheaper
option to allow hosts talk on the same subnet cross overlay boundary.
I do see this as interesting tool to some of VMs communication
requirements.
> And while some vendors do fight hard against overlays for
tenant virtualization and would rather see all smartness of the
networks in TOR I am afraid that this ship has already left the
harbor .... In the above VMs are virtualized in the compute's
node kernel eliminating any need for big fat and expensive PEs
acting as TOR.
thanks for putting words in my mouth Robert. I appreciate it ;)
You are more then welcome ;-)
r.
