What is the limit? (was RE: multi-homing fixes)

Wed Aug 29 01:20:09 UTC 2001

> I don't think filtering on RIR allocations has anything to do 
> with keeping the
> small  people down.  It is not a political problem, it is a 
> technology problem.

Indirectly it certainly does.  It is the small people who cannot justify the
host requirements to acquire an allocation from the RIRs.  Because the small
provider cannot acquire PI space, they must resort to route leaking of PA
space to the non-assigning upstream, who in turn must then announce this
PA-microallocation to its peers.  And, because, like it or not, the facts
show that large (forgive the coinage) tier-1s are doing very passive
filtering at the peering points, we see this explosion.  It is quite
enlightening to see what the big-8 exchange between each other.  This is
where the unobstructed growth is most dangerously occuring.  And please
don't tell me that we should force the smaller ASN to co-lo or multihome to
the same provider of whatever.  Any business that allows their suppliers to
drive their business requirements when better alternative solutions exist
shouldn't be in business.

Coming from someone who has on occasion, introduced superfluous information
into the GRS, there are limitations to BGP that force such leakage.  And it
is not a multihoming issue, but a traffic engineering one.  Geoff has
addressed this problem in his work on multihoming, but this thread is
addressing only the multihoming-for-redundancy issue.  This is half the
problem, and as suggested, is dependent on the RIR allocation policy.

What is also occuring (again, in a more dangerous sense) is the intentional
leakage of more specific routing information by the mid-size regional ISP
for the purposes of multi-provider TE.  downstream A has met the
requirements for an RIR allocation.  It purchases one OC-12 at rock-bottom
pricing from NSPA.  It then purchases and OC-3 for backup to NSPB, but at a
higher cost.  If NSPA and NSPB are mutually well-connected at the same level
in the AS hierarchy, then there will be an inbound load-distribution
problem.  So, the ISP breaks the /19 into 32 /24s, and announces them to
both providers, depreferencing 6 of them toward the OC-12 carrier using
communities.  This forces all traffic to flow exactly toward the NSP with
the best preference for the route if 1) the /24s are leaked between NSPA and
B, and 2) the providers prefer customer routes over peer routes over
customer backup routes (which nearly all providers do.).  Furthermore, all
peer ASNs of NSPA and B and their customers follow a non-deterministic path,
that can only be affected if the above requirements are again met.  However,
there is no method at the ISPs disposal to scope these announcements to only
these two NSPs (as the superfluous information does not need to flow beyond
them, only the aggregate.) 

The idr-wg has been working on a mechanism to scope this longer-prefix
leakage to the NSPs involved in this type of multihoming.  It is actually
derived from the dist-list-exclude and dist-list-include path attributes in
IDRP (see sections 7.12.5-6 of ISO 10747 for more info).  What this would
allow a downstream to do is responsibly leak information only to those
providers that are being paid to accept it.  Isn't that novel?  Instead of
oppressing our smaller brethren, lets empower them to contribute to the
solution. Attempting to squash them hasn't resolved anything, as we all seem
to be well aware.  

Talk to your vendors - encourage them to implement
draft-bonaventure-bgp-redistribution-01.txt as it matures.  Now if we can
only get the providers to upgrade their software...

Regards,
chris

> 
> It will ultimately be solved when core routers can handle an 
> Internet worth of
> /32's
> and an EGP is developed to efficiently propogate changes 
> (perhaps an open
> central
> registry with policy applied locally).  One has to wonder why 
> vendors don't
> satisfy the
> first requirement today.
> 
> Until that time, you can either satisfy the (fairly 
> reasonable) minimum
> allocation requirements,
> Implement any number of alternate kludges that have been 
> proposed, or go home.
> 
> KL
> 