Yes, i agree (actually, the BGP with metrics per that document is compatible with currently deployed BGP) - but isn't it better to provide a real fix and get rid of several kludges at once? --vadim To: Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu From: Hank Nussbacher <hank@ibm.net.il> 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
Yes, i agree (actually, the BGP with metrics per that document is compatible with currently deployed BGP) - but isn't it better to provide a real fix and get rid of several kludges at once?
You sure you agree? Hank's suggestion requires no change to the BGP protocol in that use of communities which aren't known are ignored (i.e. won't break old speakers). But making speakers act on it requires changes to the implementation. In practice however, the fact inter-AS peerings do not normally have send-community enabled means that the information will often be dropped across the net without widescale changes. Your suggestion also requires no change to the BGP protocol in that use of optional transitive attributes which aren't known just results in them being ignored, so won't break old speakers. But making speakers act on it requires changes to the implementation. In practice however, the fact that non-fixed speakers may well drop the attribute means the information is likely to be dropped without widescale deployment of new code. Also, your scheme has another advantage over Hank's: The code changes to make Hank's scheme work are probably larger in various router vendor's code. Take Cisco: route-map handling of communities is really dumb. Let's say Hank's pref-prefix is (say) 1234:xxxx (where xxxx is the preference). You cannot easilly filter out 1234:anything and *just* drop that community from a string, and substitute in your own pref, nor do arithmetic operations (like add 5 to the pref). You can't even delete individual communities. I think better implement it properly. -- Alex Bligh GX Networks (formerly Xara Networks)
Hank's suggestion requires no change to the BGP protocol in that use of communities which aren't known are ignored (i.e. won't break old speakers). But making speakers act on it requires changes to the implementation. In practice however, the fact inter-AS peerings do not normally have send-community enabled means that the information will often be dropped across the net without widescale changes.
Your suggestion also requires no change to the BGP protocol in that use of optional transitive attributes which aren't known just results in them being ignored, so won't break old speakers. But making speakers act on it requires changes to the implementation. In practice however, the fact that non-fixed speakers may well drop the attribute means the information is likely to be dropped without widescale deployment of new code.
Also, your scheme has another advantage over Hank's: The code changes to make Hank's scheme work are probably larger in various router vendor's code. Take Cisco: route-map handling of communities is really dumb. Let's say Hank's pref-prefix is (say) 1234:xxxx (where xxxx is the preference). You cannot easilly filter out 1234:anything and *just* drop that community from a string, and substitute in your own pref, nor do arithmetic operations (like add 5 to the pref). You can't even delete individual communities.
I think better implement it properly.
what he said but there is an underlying problem. i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network. hence i am rather reluctant to allow them to influence my policies when those decisions my be costing me money, or my customers performance, or ... randy
Randy, randy@psg.com said:
i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network.
As usual you explicated my point better than I could. Just as you need reasonably powerful tools to filter route announcements, you need *at least* a binary setting to determine whether or not to propagate and/or act on these additional attributes, and preferably better tools to modify them too. While community handling is there, the tools to make it useful are not. Thus removing any of the "well it's here now" advantages. -- Alex Bligh GX Networks (formerly Xara Networks)
Randy. Everyone here is writing about different things. But look into the BGP tables, and you show a lot of _AS111_AS111_AS111_AS111_ like pathes (change 111 to some real values). Why it's so? It's so because A LOT OF CUSTOMERS want to prefere their first lint to their second link. They have two chancec only to do it: - use some communities declared by their provider to decrease the localpreferences of their announces by the second link (if such communities exists); - use _as-length_ as the control factor to force all routers by the _main_link-transit_ases-secondary_link paths to choose the path by the main link. What we are talking about is an attempts to standartise the first (short and simple) way over the global internet. This means that, if this behaviour became standard, this means that you can ALLOW this extra communiti and _if everything other are the same up to the as-path lengthes when router choose the paths, and if some paths have BETTER_PATHS community or some other paths have _WORSE_PATHS_ community, the router decrease localpref for the second paths or increase localpref for the first paths - and choose this _BETTER_PATHS_ over the _WORST_PATHS_. You can restrict this behaviour, but this only cause the customers to use this AS_PATH_LENGTH selection and waste internet by this _AS111_AS111_AS111_... attributes, and anyway they force your router to choose _BEST_PATHS_ over the _WORST_PATHS_. Or, if this community are not implemented into your router, you can realise route-map decreasing/increasing some preference (usialli localpreference) for this. It do not restrict your own control schema. You can prefere direct customers over the peering networks, or vice versa - simple use more than 1 as the difference in the localpref (in case if it's realised by this simple way - BEST_PATHS increase localpref to 1, and WORST_PATHS decrease it to 1); you can restrict this behaviour at all. Note - this should work INSTEAD of primitive as-length comparation, and make network controlling more predictable. We are not talking about some way of the _strong control_, it's an attempt to make existing control methods more compatible. Simple example: ... route-map XXX-out permit 40 ! 286:10, 2118:1 -> бэк-ап match as-path 90 match ip addr 191 match community 6 set community 702:80 1299:50 1833:50 8342:8 .... Do you like it? All this are THE SAME communities - it's the community WORST_PATHS. But all this providers have their own values, and I should learn all communities at the same time, to prevent some unpredictable paths selections over the world. On the other hand, you can use this days community NO_EXPORT but the simular way for all your peers who allow you this control. And I am talking about the same principle - everyone can allow or disallow some control; but why don't have the compatible control attributes? // Don't blame me for the too simple description, of course Internet is // more complex than I draw it here. Alex. On Tue, 5 Oct 1999, Randy Bush wrote:
Date: Tue, 05 Oct 1999 05:49:41 -0700 From: Randy Bush <randy@psg.com> To: Alex Bligh <amb@gxn.net> Cc: Vadim Antonov <avg@kotovnik.com>, hank@ibm.net.il, nanog@merit.edu Subject: Re: Global BGP community values?
Hank's suggestion requires no change to the BGP protocol in that use of communities which aren't known are ignored (i.e. won't break old speakers). But making speakers act on it requires changes to the implementation. In practice however, the fact inter-AS peerings do not normally have send-community enabled means that the information will often be dropped across the net without widescale changes.
Your suggestion also requires no change to the BGP protocol in that use of optional transitive attributes which aren't known just results in them being ignored, so won't break old speakers. But making speakers act on it requires changes to the implementation. In practice however, the fact that non-fixed speakers may well drop the attribute means the information is likely to be dropped without widescale deployment of new code.
Also, your scheme has another advantage over Hank's: The code changes to make Hank's scheme work are probably larger in various router vendor's code. Take Cisco: route-map handling of communities is really dumb. Let's say Hank's pref-prefix is (say) 1234:xxxx (where xxxx is the preference). You cannot easilly filter out 1234:anything and *just* drop that community from a string, and substitute in your own pref, nor do arithmetic operations (like add 5 to the pref). You can't even delete individual communities.
I think better implement it properly.
what he said
but there is an underlying problem. i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network. hence i am rather reluctant to allow them to influence my policies when those decisions my be costing me money, or my customers performance, or ...
randy
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)
Thus spake Randy Bush
but there is an underlying problem. i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network. hence i am rather reluctant to allow them to influence my policies when those decisions my be costing me money, or my customers performance, or ...
But you already do...unless you control your traffic patterns explicitely and completely with local-prefs and the like, as-path probably makes the decision for a large portion of your traffic...and as-path length certainly can be influenced by a "distant" network. I understand your point, but its really just a matter of degree. -- Jeff McAdams Email: jeffm@iglou.com Head Network Administrator Voice: (502) 966-3848 IgLou Internet Services (800) 436-4456
On Tue, Oct 05, 1999 at 05:49:41AM -0700, Randy Bush wrote:
but there is an underlying problem. i have a business relationship with my direct neighbors under which we can negotiate traffic patterns. i do not have a business relationship with a 'distant' network. hence i am rather reluctant to allow them to influence my policies when those decisions my be costing me money, or my customers performance, or ...
You don't have to. The original proposal was for a community value which *hinted* to the routeing policy that the originator would prefer that return traffic went "thata way" if poossible. Those of use who run simplistic networks (we only currently have one upstream, but clients we help manage networks for still only have 2 to 4 upstreams) would see this hint to the policy engine as "good enough" for most circumstances. Those with more complex network can just ignore (and transit on please) the communities proposed. That's my understaning anyhow. Regards, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/
At 01:16 05/10/99 -0700, Vadim Antonov wrote:
Yes, i agree (actually, the BGP with metrics per that document is compatible with currently deployed BGP) - but isn't it better to provide a real fix and get rid of several kludges at once?
I agree but then why didn't your draft make it to BCP or experimental RFC status? Perhaps if we do the community thing and demonstrate that there is a real world benefit, then we can revive your RFC draft and integrate the knowledge we gain into something that gets accepted and implemented a bit later on. -Hank
--vadim
To: Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu From: Hank Nussbacher <hank@ibm.net.il> 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
On Tue, Oct 05, 1999 at 10:32:02AM +0200, Hank Nussbacher wrote:
I agree but then why didn't your draft make it to BCP or experimental RFC status? Perhaps if we do the community thing and demonstrate that there is a real world benefit, then we can revive your RFC draft and integrate the knowledge we gain into something that gets accepted and implemented a bit later on.
Without wanting to enter into the pleasant politics that surround "correctness" versus "pragmatism", I woule like to fall down on the side of pragmatism in this case. It would take very little effort and no protocol change to document a proposal with some standard convenience values that can be seen as an informally agreed set of global community values. Apart from an "always prefer this route if found" set of known values, what others could be useful ? I know that some networks (EBONE from memory) uses communities to stop exports at borders to certain networks. Would there be any value is have a standardised way of saying things like "don't export outside country/continent please" - the request being understtod to be a courtesy request rather than a demand ? Regards, -- Peter Galbavy Knowledge Matters Ltd http://www.knowledge.com/
>From mthe side of PRAGMATIC, such communities should be very usefull if 50 - 70 % of the big ISP follow them. It's possible only if this can be realised by existing control schemas (such as route-maps in CISCO), and should be easily if router vendors (just the CISCO again -:)) incorporate it as the embedded rules (just as NO_EXPORT this days - you can realise this behaviour by route-map, but usially you use embedded rules). It's just this year when most big ISP began to use such communities inside their own networks (or may be - 2 years: TELIA - this year; UUnet - last year; MCI - a few years; most Russion ISP, for example - 2 pr 3 years). But until now it is LOCAL communities - you can't decrease localpref GLOBALLY; and it caused the trigger effect in some cases. The first step should be some _VERY SIMPLE_ draft proposing new GLOBAL communities. On Tue, 5 Oct 1999, Peter Galbavy wrote: > Date: Tue, 5 Oct 1999 10:15:06 +0100 > From: Peter Galbavy <Peter.Galbavy@knowledge.com> > To: Hank Nussbacher <hank@ibm.net.il> > Cc: Vadim Antonov <avg@kotovnik.com>, nanog@merit.edu > Subject: Re: Global BGP community values? > > > On Tue, Oct 05, 1999 at 10:32:02AM +0200, Hank Nussbacher wrote: > > I agree but then why didn't your draft make it to BCP or experimental RFC > > status? Perhaps if we do the community thing and demonstrate that there is > > a real world benefit, then we can revive your RFC draft and integrate the > > knowledge we gain into something that gets accepted and implemented a bit > > later on. > > Without wanting to enter into the pleasant politics that surround > "correctness" versus "pragmatism", I woule like to fall down on the > side of pragmatism in this case. It would take very little effort and > no protocol change to document a proposal with some standard > convenience values that can be seen as an informally agreed set of > global community values. > > Apart from an "always prefer this route if found" set of known values, > what others could be useful ? I know that some networks (EBONE from > memory) uses communities to stop exports at borders to certain > networks. Would there be any value is have a standardised way of > saying things like "don't export outside country/continent please" - > the request being understtod to be a courtesy request rather than a > demand ? > > Regards, > -- > Peter Galbavy > Knowledge Matters Ltd > http://www.knowledge.com/ > > 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 (7)
-
Alex Bligh
-
Alex P. Rudnev
-
Hank Nussbacher
-
Jeff Mcadams
-
Peter Galbavy
-
Randy Bush
-
Vadim Antonov