|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Global BGP community values?
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 <[email protected]> > To: Alex Bligh <[email protected]> > Cc: Vadim Antonov <[email protected]>, [email protected], [email protected] > 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)
|