This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg]Towards a better way to document BGP communities
- Previous message (by thread): [routing-wg]Towards a better way to document BGP communities
- Next message (by thread): [routing-wg]the RRG mailing list
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Olivier Bonaventure
Olivier.Bonaventure at uclouvain.be
Mon May 5 11:53:12 CEST 2008
Dear All, During the last ten years, more and more operators have configured their network with various types of BGP communities that are used for traffic engineering, blackholing, monitoring and other purposes. A recent survey of BGP communities in RIPE and RouteViews routing tables ( http://inl.info.ucl.ac.be/publications/bgp-communities ) shows that more than 1000 ASes have defined their own BGP communities (mostly for traffic engineering purposes ) and half of the BGP routes carry one or more BGP communities. These BGP communities are important tools for many operators. However, they are currently only documented on an adhoc basis, usually either as notes on web pages or as comments in RPSL specifications. Some BGP communities may interact in strange ways and debugging those interactions may be very difficult on the Internet. We believe that a more precise way of documenting BGP communities would be useful for both operators and their clients. This method should be vendor neutral but should allow one to express the policies that are supported by most router vendors. It should also be possible for a client to test how one of his route would be filtered by his provider in function of the BGP communities associated to that route. Doing such tests in the public Internet is cumbersome and difficult to debug. A classical example of this difficulty is that some combinations of BGP communities may lead to BGP wedgies as described in RFC4264. A better approach would be to have a simulation tool that allows operators to both define the BGP policies used by their network and also provide a model that allows their client to test how their routes would be filtered. The open-source CBGP simulator ( http://cbgp.info.ucl.ac.be/ ) could be easily used for this purpose and operators could define a CBGP model of their network that specifies clearly how routes containing BGP communities are filtered and give this model to their customers to aid them to tune their configurations. In the long term, a CBGP model of each network could be one of the elements of the RPSL specification of a network. If you have defined BGP communities in your network and are interested in developping a BGP model of your network to precisely document the BGP communities that you use, let us know. We would like to build a set of reference CBGP models that can be used as best current practices by other operators. Best regards, Olivier Bonaventure and Bruno Quoitin -- http://inl.info.ucl.ac.be , UCLouvain, Belgium
- Previous message (by thread): [routing-wg]Towards a better way to document BGP communities
- Next message (by thread): [routing-wg]the RRG mailing list
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]