Global BGP community values?

Tue Oct 5 06:53:53 UTC 1999

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 at 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
>
>