Re: Global BGP community values?
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
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
I don't think it's real to change BGP protocol this days. But it's absolutely free to use some global communities, just as add some embedded communities into an existing BGP machines such as CISCO IOS or GATED (you can use it or turn it off or use equivalent route-map matching instead). On Tue, 5 Oct 1999, Hank Nussbacher wrote:
Date: Tue, 05 Oct 1999 08:53:53 +0200 From: Hank Nussbacher <hank@ibm.net.il> To: Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu Subject: Re: Global BGP community values?
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
Aleksei Roudnev, Network Operations Center, Relcom, Moscow (+7 095) 194-19-95 (Network Operations Center Hot Line),(+7 095) 230-41-41, N 13729 (pager) (+7 095) 196-72-12 (Support), (+7 095) 194-33-28 (Fax)
participants (3)
-
Alex P. Rudnev -
Hank Nussbacher -
Vadim Antonov