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/
>
> 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] 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]]
> Sent: Tuesday, February 11, 2014 9:28 AM
> To: Thomas Morin
> Cc: Giles Heron; Robert Raszuk; [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]> 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]>
> 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.
signature.asc
Description: Message signed with OpenPGP using GPGMail
