[7830] in North American Network Operators' Group
Re: BGP announcements and small providers
daemon@ATHENA.MIT.EDU (Matt Ranney)
Tue Feb 25 21:14:34 1997
From: "Matt Ranney" <mjr@ranney.com>
Date: Tue, 25 Feb 1997 18:11:53 -0800 (PST)
To: "Alex.Bligh" <amb@xara.net>
cc: nanog@merit.edu
In-Reply-To: <199702252204.WAA20208@diamond.xara.net>
On Tue, 25 Feb 1997, Alex.Bligh wrote:
[...]
> Swamp /24, or use most of a /18|/19 underutilized, or better use more
Given current address allocation policies, how are you supposed to go
about getting a /19 to waste in the first place?
> intelligence than "just" BGP - for instance Paul Vixie's stuff at the
> last NANOG.
Paul's solution certainly adds more reliability as long as the clients
doing the connecting do the right thing WRT rotating through the A
records for your servers. As far as I can tell, it still doesn't do
anything to solve the problem of choosing the "best" interface for the
connection to happen on. Obviously the definition of "best" is up for
debate, but if the squid machine was doing BGP, there would at least
be some path optimization done.
As it is, if the interface-defaulted squid machine was dual-homed to
providers X and Y that don't peer, a customer of X could get the A
record for the interface in Y's space. The client would then have to
take the transit path between X and Y, which for many X's and Y's,
sucks. If the dual-homed machine was doing BGP, the customer of X
would always use the interface on X's side, and vice versa.
Of course, we all know that we need to aggregate, shrink the routing
table, shrink peer lists, etc., and Paul's solution certainly wins
in that repect.
--
Matt Ranney - mjr@ranney.com
This is how I sign all my messages.
