Re: Global BGP community values?

["Alex P. Rudnev" <alex () Relcom EU net>]

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)