> 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.
Documentation is fine, but if it comes from a WG isn't it then an
endorsed approach unless some language is explicitly added to the draft?
--Tom
>
> -Thomas
>
>
> 2014-02-11, Thomas Nadeau:
>>
>> On Feb 11, 2014:9:22 AM, at 9:22 AM, Robert Raszuk <[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.
>>>
>>>
>>
>
signature.asc
Description: Message signed with OpenPGP using GPGMail
