Tom:
My point was - don't legislate the BGP usage - let the market decide. Document what is as informational. Not going to debate your IHMO or my IHMO. Sue From: Thomas Nadeau [mailto:[email protected]] Sent: Tuesday, February 11, 2014 11:58 AM To: Susan Hares Cc: Thomas Morin; Giles Heron; Robert Raszuk; [email protected]; L3VPN Subject: 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 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]> 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/> 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 <mailto:[email protected]> [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 - so it vital to make your concerns known. Sue Hares From: Thomas Nadeau [ <mailto:[email protected]> mailto:[email protected]] Sent: Tuesday, February 11, 2014 9:28 AM To: Thomas Morin Cc: Giles Heron; Robert Raszuk; <mailto:[email protected]> [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 > < <mailto:[email protected]> [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 < <mailto:[email protected]> [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.
