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
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
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,
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.
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. 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.
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.
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,