发件人: L3VPN [mailto:[email protected]] 代表 Thomas Nadeau
发送时间: 2014年2月12日 0:58
收件人: Susan Hares
抄送: Thomas Morin; [email protected]; L3VPN; Robert
Raszuk
主题: Re: /32s in DC and BGP
I am still not convinced that shipping around what effectively is the
entire FIB of a DC, is a good idea.
There just seem to be better alternatives that have been pointed out that scale
well. I also do not think it is
a purist idea to question routing /32s in a DC. Look at what big DCs are doing
today for routes, and its not
/32s. I will also point out that one of the advantages to routing protocols is
their aggregation/summarization
Hi Tom,
Would you please share us your knowledge about what big DC are doing today for
routes and how the route aggregation/summarization is performed? Thanks in
advance.
Best regards,
Xiaohu
abilities; in this case we are completely defeating that.
--Tom
On Feb 11, 2014:11:00 AM, at 11:00 AM, Susan Hares
<[email protected]<mailto:[email protected]>> wrote:
Tom:
The argument on /32 for IPv4 in BGP is an old one that was resolved with “what
makes business sense” (aka Shakespere in BGP) instead the “purist” mandate on
what BGP can do.
As to Data Center’s use of the BGP, I suggest you review the draft:
http://datatracker.ietf.org/doc/draft-lapukhov-bgp-routing-large-dc/
Some data centers pass host routes for a variety of purposes. Yakov indicates
host routes are being ship in EVPN. IMHO documenting on these deployed use
cases aids researchers and implementers.
The IDR WG has moved on from the “purist” view to allowing DCs private AS space
and allowing link-state information to be carried in BGP. These usage are
not Internet-wide usage, but adapt BGP to a portion of the Internet. If you
feel host routes should not be carried, please comment to
[email protected]<mailto:[email protected]> on draft-ietf-idr-ls-distribution solution
which passes LSP Info in BGP. It is being suggest for early allocation of
code points �C so it vital to make your concerns known.
Sue Hares
From: Thomas Nadeau [mailto:[email protected]]
Sent: Tuesday, February 11, 2014 9:28 AM
To: Thomas Morin
Cc: Giles Heron; Robert Raszuk;
[email protected]<mailto:[email protected]>;
L3VPN
Subject: Re: /32s in DC and BGP
Hi Giles, Thomas,
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; 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.
--Tom
-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.
