Re: Global BGP community values?

[Hank Nussbacher <hank () ibm net il>]

At 23:39 04/10/99 -0700, Vadim Antonov wrote:

The difference is your proposal requires changes to the BGP protocol (new
optional transitive attribute), whereas mine piggybacks on the existing
community attribute - thereby being able to be implemented tomorrow as
opposed to some months/years from now.

-Hank

> I proposed real metrics for BGP long time ago.  Back then
> the idea didn't find any support -- apparently few people
> felt it was needed.
>
> The mechanism described in the draft is stragightforward and significantly
> more powerful than the community attribute usage proposed by Hank - and
> also can do everything MED and LOCAL_PREF can do, so these can
> be retired.
>
> Here's the URL:  http://www.civd.com/~avg
>
> --vadim
>
> --------------------------------------------------
> Hank Nussbacher <hank () ibm net il> wrote:
>
> I think everyone at one point or another has tried to influence incoming
> data flows via BGP. About the only tool available to influence the BGP
> decisions in far away places is via AS-PATH length.  This turns out to be
> a fairly never-ending iterative process - that at best achieves 80% of its
> intention. It also doesn't allow for accurate decision making.  As an
> alternative, neighboring ISPs and their customers usually design some BGP
> community system which is then used to influence the BGP decision process.
>
> Why can't this be extended globally [if this has already been done and
> written up in some BCP RFC - just point it out to me]?  What if we all
> agreed that if some community value of say 1000000-2000000 [example] is
> seen, then those community values are to take precedence above all other
> metrics.  1000001 could mean - "this is the best path for me - always send
> pkts this way no matter what the other metrics might say".  We could build
> up a table of these global community strings.  ISPs that don't use it - no
> harm done.  But the more ISPs (tier 1 & 2) that do use it - the better the
> end customer and ISPs have on influencing data flow.
>
> Comments welcome.
>
> Hank Nussbacher