a crude method of limiting long-prefix propagation

[Joe Abley]

On Thu, Mar 22, 2001 at 11:37:44PM -0700, mccreary at pch.net wrote:
> The real question is whether any ISP thinks this is compatible with their
> current traffic engineering efforts.  Any solution requiring significant
> amounts of inter-provider cooperation will need to demonstrate clear benefits
> for all parties involved, and I can't think of a compelling reason why an
> AS 2 or more hops from the origin AS would want to support remote manipulation
> of their transit traffic (in the general case, at least).

This is the main question; however, I think there is some hope.

 A --- B ---- C --- D

Suppose A is trying to influence policy at C. This requires cooperation
between A, B and C.

Between A and B there is a transit arrangement, and hence the lever of
money might induce cooperation. A transit arrangement between B and C
might be achievable similarly.

If B and C are peers, then there is a less-obvious motivation to play.
There is the mitigating factor that the config bits to provide the
support might already be there, assuming C has customers that have
similar requirements to A.

All this requires some useful subset of providers to decide to take
some action to reduce prefix bloat. However, at least the use of
these communities doesn't make the current bloat any worse; the
question is whether it makes a sufficient difference to be worth
doing. (or, another question: which ASes in the real network need
to support this for it to be generally useful?)

Ben's alternative implementation in a new bgp attribute might be
easier to get running around the network, since its deployment can be
driven by vendors rather than operators, and there are fewer vendors
who need to join in to make it a reality.


Joe