North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: routing meltdown
> Precisely my point. I think it's a neat solution. So do I, in the absence of ... > >route servers and a unified/recursive/realtime RADB. [...] > We're discussing this precisely because you're not sure, as you say, > what course of action is best. "I'm not sure" in this context is a euphemism for "that's a really bad idea." > Now, the folks at Sprint don't like the idea of a "unified" route > server, and I don't blaim them, since it does reduce one's independence > when it comes to setting a routing policy: the "unified" route server > only gives everyone one "view," the same view when we'd all rather be > able to make the decision ourselves of what "view" is best. Nope. As you're about to explain yourself, the RS architecture makes it possible to spout different truths out of each and every orifice. It is very definitely _not_ nec'y for every RS peer to have the same view, or that the Internet have a single great and context-insensitive "Truth". > Yes, the > route server would be configured from the RADB, and we'd all have the > right to register whatever policy for our ASes we think is best, but how > often would the route server be reconfigured to reflect updates to the > RADB? Right now, this is the thing that makes the RS unusable. At the RPS WG in Stockholm I heard Daniel talk about a way to improve RADB update times, and Bill Manning and I proposed a DNS-based RADB whose rollups could be done by anyone needing the information rather than by a central body. While I admit that the RS doesn't have realtime updates right now, I know that it's coming. Knowing Sean for who he is, I'm fairly sure that no RADB or RS will ever be suitable to him. In particular... > and should we really trust such a route server? its implementation? > its administrators? ...while I would trust those things if given sufficient reason to, I know of at least one network/routing engineer who wouldn't no matter how sufficient the reasons seem to the rest of us. So your point is valid on that score. > As for wether an interconnect can requiere everyone to collocate a route > server for their AS, I don't see why not. It's only a few inches of rack > space; the collocated route servers don't have to be connected to the > high speed (FDDI or ATM or whatever comes along) interconnect either, > because, as I've already pointed out, the collocated route servers could > be on a totally separate, parallel, low bandwidth network (say, > Ethernet). In legal terms, we cannot add contract terms now that a lot of peering points are in use. There is, quite literally, "no way to require" colo'd workstations at peering points. It doesn't matter how little rack space it takes, or that the BGP4 traffic would be on different media like Ethernet, or whether it is (I'm not going to take a position) a wonderful idea or not. Legally, we cannot require it. Practically, the peering points are "open" to the extent that folks are expected to use their GIGAhose "as they see fit." Requiring colo'd workstations, even if we gave them away, is as impossible as requiring that folks sign an MLPA. > Does anyone see a reason, political or technical, why collocating per-AS > route servers is not viable? Yes, the scalability does not improve as > opposed to what we have now, but PCs get better much faster than Cisco's > or Wellfleet's or NSC's or <fill in the blank>'s routers, meaning > scalability problems are pushed off far into the future ; but it is far > better, easier to handle and administrate than planning and > administrating proxy aggregation. I think this is a reasonable architecture and if I am asked to recommend an architecture to someone connected to a MAE or NAP, I will mention this one. I recommend that you do the same. Perhaps you can live to see your ideal done up in practice. But banish all expectations that either a peering point administrator will help enforce your ideology, or that you will ever get full voluntary buy-in from every peer. N**2 BGP4 sessions are bad for likely values of N (100, maybe.) That won't change just because we've got a 1GB-RAM DEC Alpha with a 300MHz processor instead of a Cisco to do our route processing. N**2 BGP4 sessions is a bad design no matter what you're implementing it with. In that sense, your idea is not "viable" since it doesn't solve some of the real problems coming up. > [A fast PC with 1GB of RAM should be able to handle any NAP for the next > year to two years, by which time IPv6 could be hitting the scene] I can't even begin to comment on that, I'm sure that I'd offend you.