On Mon, Jul 16, 2007 at 10:00:28AM +0200, Teplov, Matvey wrote: > Hi, > > As you know BGP works on the 8th and 9th level of the OSI model (financial > and political) and process of influencing routing decisions is not > transparent to the another party at all. For example we can start sending > traffic over the local peering and return one will come back into our > network via transatlantic (SP A routing policies) or will have equal > advertisements all over the place (SP B), etc, etc, etc. This geographic > independency severely impacts routing decisions as the traffic crosses from > ISP to ISP. There is no way for the ISP to tell where the route has been > originated as it is completely hidden in the originator environment. > It will be possible to make alter if necessary routing decisions if some > attribute will be applied to the prefix at the moment it is originated. > Addition of such should be harmless to the routing tables and > vendor-software as it should utilize existing install base and be completely > optional. > > By adding one or more globally-defined community attributes to prefix we > will be simplifying traffic management decision by providing some > geographical link for the ISP's to work with. Special high-order two-byte > value can be allocated to be used universally, while two low-order bytes can > be used to provide more granular designation. In addition to this well > intra-provider defined policies will help in route oscillation as clear > intra-ISP preferences can be defined. > > Following additions can be considered as well: > - Values to describe the originator's continent (to prevent excessive use > of the community lists in order to determine the destination - will ease > implementation - can be considered as a short version of described above) > - Values to describe preferred continent to receive the traffic via (for > example African/Oceania ISP can prefer to receive it via States rather than > Asia or Europe). > > Policies itself can be purely ISP-specific and will stay beyond the scope of > this document. Impact will be zero as the values to be chosen will most > likely not be in use and if they will it will be as low as possible. > > Please let me know what your thought are.
Well, lets see. I wrote up a BCP on precisely this topic
some time ago (RFC 4384, "BGP Communities for Data
Collection"). The original idea there was to try to
standardize the meaning(s) of the various communities we
were getting from routeviews peers. It would also allow
us to have some standardization across collection
projects (e.g., RIPE/RIS).
Now, some folks have used the 4384 for their internal
use (generally in greenfield deployments), but AFAIK 4384
hasn't really caught on. One obvious reason is that it
does expose information that someone may rather not
expose. Another is that most folks have their community
encodings in place, so changing all of that (even if one
wanted to) would be a serious task.
Dave
signature.asc
Description: Digital signature
_______________________________________________ GROW mailing list [email protected] https://www1.ietf.org/mailman/listinfo/grow
