Tom, It is common to have orchestration layer spreading given tenant VMs or appliances across different hosts.
To reach those you need to have a route to it. And that is an overlay route not a transport one. That's already an important distinction. I am not sure what is your definition of "shipping around" as it is pretty easy to divide your tenants into separate and disjoined control plane blocks. Then you do not need to carry it all in one basket. I think you are here not really arguing against virtual-subnet draft as this proposes just an enhancement. You are fighting against l3vpn-for-end-systems proposal which is based on carrying all /32s of all VMs within a DC zone. Please observe that this has nothing to do with FIBs .. each data plane will still use only what it needs to serve locally attached tenant resources. If you aggregate at the network in the PE sure you may summarize a bit, but then you will have all those folks asking for seamless and optimal VM mobility across such PEs which does require precise reachability. rgs, R. On Tue, Feb 11, 2014 at 5:57 PM, Thomas Nadeau <[email protected]>wrote: > > 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]<[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. > > >
