Hi Thomas,
2014-02-11, Thomas Nadeau:
I would echo Robert's questions below, and ask an additional
question: advertising non aggregated host routes (v4 /32 routes or v6
/128 routes) in BGP VPNv4 routes is not fundamentally different from
a scaling standpoint than advertising MAC addresses in E-VPN BGP routes.
What would be the reason to believe it would be an issue in one case
but not in the other ?
I think you are missing the point that was raised: its not that BGP
will not scale well;
(Giles initial point, that you supported, was a that he was unconvinced
it would scale.)
as a protocol its clearly shown that it can ship around millions of
routes and lots of other stuff as it has become the "dump truck" of
the protocol world. The question is more of the approach - do we want
to be shuffling around /32s (regardless of protocol) given that there
are other solutions that work well without doing so? I would also
question the use of BGP in a Data Center given past operational
feedback in NVO3 for example, but that is orthogonal to the question
of the mechanics of this solution.
This discussion about putting /32s in BGP is absolutely not specific to
draft-..-virtual-subnet (see E-VPN, end-system l3vpn).
-Thomas
2014-02-11, Robert Raszuk:
<changing subject to reflect more broader l3vpn related topic>
Hi,
Could those who claim that that sending /32 or /64 or /128 in BGP
mainly within contained DC zone environment will not scale be a bit
more precise and kindly indicate what the real problem is ?
* Which control or data plane element will not scale ?
or
* Which part of BGP state machine will not scale ?
Just curious ....
Cheers,
R.
>
On Tue, Feb 11, 2014 at 3:03 AM, Thomas Nadeau
>
<[email protected] <mailto:[email protected]>> wrote:
Thomas,
I too object to it's adoption based on the /32 point
Giles made.
On Feb 10, 2014:2:29 PM, at 2:29 PM, Giles Heron
<[email protected] <mailto:[email protected]>> wrote:
> I don't support adoption of this draft as a WG item (speaking
as a non-author but name-checked commenter).
>
> The draft has a major limitation (no support for
interconnecting routers, but only for interconnecting hosts),
and I'm unconvinced that passing /32 host routes around in BGP
will scale.
