Brian.Dickson at concertia
Nov 2, 2009, 12:44 PM
Post #51 of 61
(626 views)
Permalink
|
(Apologies for top-replying, but hey, it makes it easier to ignore stuff you've already read.)
I think the main things to consider in identifying what things "belong" in a standardized community are:
- is it something that is really global, and not local, in behaviour and scope?
- is it something that is mostly a signalling-of-intent "flag", and not a modification of path-selection?
--> (because) It should not require universal adoption to be useful - if it is ignored by A, and passed to B, will it still be useful/semantically correct?
- is it something that will either be applied by the originator to all instances of a given prefix (i.e. sending X to neighbour A and neighbour B, with community M);
- or something that will be applied by the originator to some instances of a given prefix (i.e. sending X to A with N, and X to B without N)
- is the intent being signalled easily understood, ideally in an absolute sense?
The two things I can think of, which would benefit from such a community, and where nearly-universal adoption would be of significant benefit, are:
(1) Blackhole this prefix, and;
(2) Use this prefix as a last resort only.
(Please add to this list if you think of any other cases meeting the above criteria).
Comments on particular proposed-standard-community cases follows...
I bring up (2) because it is otherwise *very* difficult to signal (or achieve), and often leads to potential wedgies.
The existing mechanisms to achieve (2) are often indistinguishable from Traffic Engineering - but this is very much not TE.
TE is "reduce load on this instance". (2) is "Don't use this for traffic unless you have no paths not marked with this community".
TE will typically be observed with small numbers of AS-prepending. (2) will be observed with large numbers of AS-prepending.
And, my guess would be, 80% of the prepending would not be needed if (2) were standardized and in use.
It might even reduce significantly the observed instances of wedgies and/or persistent oscillations in the wild.
Brian
-----Original Message-----
From: Jack Bates [mailto:jbates [at] brightok]
Sent: November-02-09 4:03 PM
To: Joel Jaeggli
Cc: nanog [at] nanog
Subject: Re: Upstream BGP community support
Joel Jaeggli wrote:
> more accessible and therefore more likely to be used, I don't think
> traffic engineering is something I particularly want to encourage to
> excess but RTBH is a know that more people need access to quite frankly.
I think creating a standard or at least a template might push more
people to adopt communities support and to use them. There are
definitely times it is useful to redirect traffic 2 ASN's away through a
longer route. In some cases (like my small self, I try to adopt policies
that allow communities to me to also be rewritten to the corresponding
peers communities to alter things as far as 3 ASN's away from my customer.
Jack
|
