[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                           Bruno Quoitin
INTERNET DRAFT                                                    FUNDP
                                                    Olivier Bonaventure
                                                                  FUNDP
                                                         February, 2002
                                                   Expires August, 2002


      A survey of the utilization of the BGP community  attribute
                 <draft-quoitin-bgp-comm-survey-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


Abstract

   In this document, we describe the two most common utilizations of the
   BGP community attribute, namely to tag routes and indicate how a
   route should be redistributed by external peers. We then discuss how
   often these two types of community attribute are used on the basis of
   the RIPE whois database and of BGP table dumps.

1   Introduction

   The BGP Community attribute defined in [TCL96] is a powerful
   mechanism that can be used to build more scalable BGP configurations.
   This attribute consists of a set of four octet values, each of which
   specifies a community. [TCL96] reserves the community values ranging
   from 0x0000000 through 0x0000ffff and 0xffff0000 through 0xffffffff.



Quoitin and Bonaventure                                         [Page 1]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


   Furthermore, three communities are defined with global significance:


     - NO_EXPORT (0xffffff01): routes with this community attached
     should not be advertised outside a BGP confederation;


     - NO_ADVERTISE (0xffffff02): routes with this community attached
     must not be advertised to other peers;


     - NO_EXPORT_SUBCONFED (0xffffff03): routes received with this com¡
     munity attached must not be advertised to peers outside the  bound¡
     ary of a subconfederation.

     Besides these reserved community values, [TCL96] proposed to divide
     the community space by using an AS number in the two high-order
     octets. This proposal can be considered as a delegation of 65536
     values of the community space to each AS.  Thus, ASx is free to use
     community values ranging from ASx:0 to ASx:0xffff. However, [TCL96]
     did not discuss how the community values corresponding to  the pri¡
     vate AS space [HB96] (i.e.  community values 64512:00 -
     65534:65535) could be used in the global Internet.In this document,
     we describe the most common utilizations of the BGP community
     attribute in the global Internet. We base our analysis on the
     information available in the RIPE whois database and the BGP table
     dumps collected by the RIPE RIS (R‰seaux IP Europ‰ens - Routing
     Information Service) [RIS02] and the Route Views projects [Mey02].
     This document is organised as follows. First, we discuss in  sec¡
     tion 2 utilizations of this attribute on the basis of the RIPE
     whois database. In section 3 we briefly discuss the communities
     found in the BGP tables in the global Internet and present our con¡
     clusions.

2   Common utilizations of the BGP Community attribute

     A classical application of the Community attribute is for multi-
     homing purposes as discussed in [CB96]. However, since the publica¡
     tion of [CB96], the Community attribute has been used for other
     purposes, including the support of VPNs [RFC2547]. We do not dis¡
     cuss this application to VPNs in this document.Two of the most com¡
     mon utilizations of the Community attribute in the global Internet
     are to tag the routes received from a specific peer or at a spe¡
     cific location and to influence the redistribution of specific
     routes in order to perform some kind of interdomain traffic engi¡
     neering.

 2.1   Route tagging communities



Quoitin and Bonaventure                                         [Page 2]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


     In this case, the community value is used by an Autonomous System
     to indicate the location where the route was received from an
     external peer. These community values are inserted by the BGP
     router that receives a route at a given location. Many AS rely on
     such communities in today's Internet. Based on the needs of each
     AS, different types of locations are used in practice today : geo¡
     graphic, interconnection point, autonomous system (AS). We provide
     in the following sections some examples based on the information
     found in the RIPE whois database in January 2002.

  2.1.1   Type of peer

      In this case, the AS defines a few types of BGP peers (typically
     customer, (national or international) peering partner and transit
     provider) and tags each received route with a community indicating
     the type of peer from which the route was received.

  2.1.2   Geographic location

      AS often need to know the geographic location where a given route
     was received. The types of geographic locations used by each AS
     depend on the AS size. A national AS might want to know the city
     where each route was learned, while an international AS would
     instead need to know the country or continent where a given route
     was learned. Often, an AS that utilizes such community values
     relies on an unstructured list of values and associates a location
     to each value. For example, AS13129 (Global Access Telecommunica¡
     tions, Inc.) defines in [RIW02] the values shown in table 1 to tag
     routes learned from specific cities.


                           +---------------------+
                           |13129:3010|Frankfurt |
                           +---------------------+
                           |13129:3020|Munich    |
                           +---------------------+
                           |13129:3030|Hamburg   |
                           +---------------------+
                           |13129:3040|Berlin    |
                           +---------------------+
                           |13129:3050|Dusseldorf|
                           +---------------------+
                           |13129:3210|London    |
                           +---------------------+
                           |13129:3220|Paris     |
                           +---------------------+
                           |13129:3610|New York  |
                           +---------------------+



Quoitin and Bonaventure                                         [Page 3]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


              Table 1: Tagging communities published by AS13129


     Some ASs have devised structured encodings of those route tagging
     community values such as the one of AS286 (EUnet) shown in table 2
     where the value used to tag a received route is based on the tele¡
     phone country code. These communities are documented in [RIW02].

         +------------------------------+--------------------------+
         |    286:1000 + countrycode    |Public peer routes        |
         +------------------------------+--------------------------+
         |    286:2000 + countrycode    |Private peer routes       |
         +------------------------------+--------------------------+
         |    286:3000 + countrycode    |Customer routes           |
         +------------------------------+--------------------------+
         |where countrycode is the E.164 international dial prefix.|
         +------------------------------+--------------------------+

               Table 2: Tagging communities published by AS286


     Another example is the encoding chosen by AS3561 (Cable & Wireless)
     shown in table 3 based on the ISO 3166 codes for countries. The
     resulting communities are documented in [CW02].


              +----------+------------------------------------+
              |3561:SRCCC|S   is the source (peer or customer)|
              |          |R   is the regional code            |
              |          |CCC is the ISO 3166 country code    |
              +----------+------------------------------------+

              Table 3: Tagging communities published by AS3561


  2.1.3   Interconnection point

      In some cases, AS also need to remember the interconnection point
     where a given route was received.  For instance, AS13129 defines
     communities used to tag routes learned at specific interconnection
     points. These communities, published in [RIW02], are shown in table
     4. We have not encountered structured encodings for the community
     values used to tag the interconnection point where routes where
     learned.

                             +----------+------+
                             |13129:2110|DE-CIX|
                             +----------+------+



Quoitin and Bonaventure                                         [Page 4]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


                             |13129:2120|INXS  |
                             +----------+------+
                             |13129:2130|SFINX |
                             +----------+------+
                             |13129:2140|LINX  |
                             +----------+------+

              Table 4: Tagging communities published by AS13129


  2.1.4   Autonomous system (AS)

      A few AS also use communities to remember the AS from which each
     route was learned. This utilization of the community attribute is
     redundant with the AS Path attribute, but could be useful in con¡
     federations or to simplify the configuration of some routers. For
     instance, AS8938 (Energis (Switzerland) AG) defines communities
     used to tag routes learned from specific autonomous systems. These
     communities [RIW02] are shown in table 5.

                       +---------+------------------+
                       |8938:2100|Genuity US (AS1)  |
                       +---------+------------------+
                       |8938:2200|Level3 US (AS3356)|
                       +---------+------------------+
                       |8938:2300|Ebone (AS1755)    |
                       +---------+------------------+
                       |8938:2400|Sprint (AS1239)   |
                       +---------+------------------+

                 Table 5: Tagging communities used by AS8938


     Another example is AS1899 (KPNQwest France) that has chosen to
     reuse community values in the private AS space (64512:0 -
     65534:65535) to tag routes received from other ASs as shown in
     table 6. These communities are documented in [RIW02].


              +--------+-------------------------------------+
              |64675:AS|Routes received from Peer AS on PARIS|
              +--------+-------------------------------------+

              Table 6: Tagging communities published by AS1899


 2.2   Communities affecting the redistribution of routes




Quoitin and Bonaventure                                         [Page 5]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


      Another important utilization of BGP Community attribute is for
     traffic engineering purposes. In this case, the community is typi¡
     cally inserted by the originator of the route in order to influence
     its redistribution by downstream routers.Three types of communities
     are often used today to influence the redistribution of routes
     towards specific peers or interconnection points:


     1.  Do not announce the route to a specified peer(s);


     2.  Prepend n times to the AS-Path (where we have found values
       for n generaly ranging from 1 to 3) when announcing the route
       to specified peer(s);


     3.  Set the LOCAL_PREF value in the AS receiving the route;

     We discuss these three types of communities in more details and
     show how often they are used based on the RIPE whois database in
     the following sections.

  2.2.1   ``Do not announce the route'' community

      In this case, the community is attached to a route to indicate
     that this route should not be announced to a specified peer or at a
     specified interconnection point.  This is the case in the example
     shown in figure 1, where AS10 and AS20 have a private peering con¡
     tract and AS20 does not want that the routes announced to AS10 be
     redistributed to AS10's upstream peers. For this, AS20 tags these
     routes with a community published by AS10 that will prevent the
     redistribution of such routes.


         Figure may be found in the postscript version of this draft

                 Figure 1: Do not announce to upstream peers

     A large number of AS have documented their support for this kind of
     community values. Table 7 summarizes the documented utilizations of
     those communities according to the RIPE whois database in October
     2001. This table shows that while many AS utilize community  values
     to indicate that a route should not be announced to a given AS or
     at a given  interconnection point, some also allow the utilizaton
     of such communities to indicate that a route should not be
     announced outside a given region or continent.

      +-----------+---------------------------------------------------+



Quoitin and Bonaventure                                         [Page 6]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


      | AS number | Do not announce to                                |
      +-----------+---------------------------------------------------+
      | AS1755    |US upstreams/peers, European peers, specified AS   |
      | AS8437    |All upstreams, all peerings, specified AS,         |
      |           |specified IX                                       |
      | AS2683    |Specified AS, specified IX                         |
      | AS13299   |Specified IX                                       |
      | AS13297   |Specified IX                                       |
      | AS3303    |any US peers/upstreams, specified AS               |
      | AS5571    |Specified IX                                       |
      | AS12458   |Specified IX                                       |
      | AS8918    |Specified AS, Specified IX                         |
      | AS8235    |All peers, specified AS                            |
      | AS13300   |Specified IX                                       |
      | AS2118    |Outside AS2118 country                             |
      | AS16186   |Specified transit, specified IX                    |
      | AS8627    |US-Upstream Peers, specified AS, private peers     |
      | AS6735    |Specified AS, specified IX                         |
      | AS1557    |Specified AS, specified IX                         |
      | AS15366   |Specified IX                                       |
      | AS9032    |Specified AS                                       |
      | AS8228    |US upstreams/peers, specified AS, peers in         |
      |           |country/continent                                  |
      | AS6705    |Specified AS, specified IX                         |
      | AS5400    |AS in specified continent, specified AS            |
      | AS5511    |AS in specified continent, specified AS            |
      | AS8472    |Specified IX, specified AS                         |
      | AS1901    |AS in continent, specified AS, specified IX        |
      | AS12329   |Specified AS                                       |
      | AS12306   |Specified IX                                       |
      | AS12976   |Specified AS                                       |
      | AS517     |Specified AS, specified IX                         |
      | AS3215    |Specified IX, specified AS                         |
      | AS286     |AS in specified continent, specified AS            |
      | AS8470    |Foreign AS, AS in country                          |
      | AS12541   |Specified IX, specified AS                         |
      | AS13129   |Specified AS, specified IX                         |
      | AS2820    |Inside and outside country                         |
      | AS8246    |Specified AS                                       |
      | AS1273    |Specified AS, specified IX                         |
      | AS8938    |Any upstream, specified AS                         |
      | AS8708    |Upstreams, peers                                   |
      | AS6728    |US, specified AS, specified IX                     |
      | AS8933    |Any commercial peer, specified AS                  |
      | AS3259    |Outside Continent                                  |
      | AS12779   |Upstreams, specified AS                            |
      | AS8210    |Upstreams in specified continent, specified AS     |
      | AS12832   |Downstream AS                                      |



Quoitin and Bonaventure                                         [Page 7]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


      | AS15444   |Specified IX                                       |
      | AS9057    |Customers but not peers, specified AS              |
      | AS5430    |Specified peering                                  |
      | AS12359   |Transit providers, customers, specified IX, AS in  |
      |           |country                                            |
      | AS702     |Only within AS702 and customers, outside continent |
      +-----------+---------------------------------------------------+

     Table 7: ``Do not announce'' communities documented in the RIPE database
                               in October 2001


     Most of the AS that support this type of community values rely on
     an structured list of community values for this purpose. For exam¡
     ple,  table 8 shows some of the community values used by AS1755
     (OpenTransit) and documented in [RIW02].

            +---------+----------------------------------------+
            |  Value  |Meaning                                 |
            +---------+----------------------------------------+
            |1755:1000|Do not announce to US upstreams/peers   |
            |1755:1101|Do not announce to Sprintlink(US)/AS1239|
            |1755:1102|Do not announce to UUNET(US)/AS701      |
            |1755:1103|Do not announce to Abovenet(US)/AS6461  |
            |   ...   |                                        |
            |1755:2000|No announcement to european peers       |
            |   ...   |                                        |
            +---------+----------------------------------------+

           Table 8: ``Do not announce'' communities used by AS1755


     However, a few AS rely on a more structured enconding of the commu¡
     nity values used for this purpose. For example, AS9057 (Level3) has
     chosen to reuse a range community values of the private AS space as
     ``do not announce'' community values as shown in table 9.


      +---------+----------------------------------------------------+
      |  Value  |Meaning                                             |
      +---------+----------------------------------------------------+
      |65000:XXX|do not announce on peerings to AS XXX               |
      |64970:XXX|do not announce on Asian/Pacific peerings to AS XXX |
      |64980:XXX|do not announce on European peerings to AS XXX      |
      |64990:XXX|do not announce on North American peerings to AS XXX|
      +---------+----------------------------------------------------+

           Table 9: ``Do not announce'' communities used by AS9057



Quoitin and Bonaventure                                         [Page 8]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


  2.2.2   Prepend to AS-Path

      AS-Path prepending is a manipulation that makes the AS-Path arti¡
     ficially longer when announcing a route to specific peers.  The
     announced route will not be preferred but can still be used as a
     backup route. Although in theory AS-Path prepending is considered
     as a  rough solution because ``it is virtually impossible to com¡
     pute the AS-Path length needed to induce the upstream to make the
     desired choice'' [CAI02], this is a popular solution to control the
     interdomain traffic received by stub ISPs. The analysis of the BGP
     table dumps [Hus02] shows that AS-Path prepending is  very fre¡
     quently used in the Internet today.For instance, in the ridiculous
     network shown in figure 2, AS10 could provide limited backup tran¡
     sit service to its peer AS20 by announcing routes learned from AS1
     and prepending 3 times AS10 to the AS-Path. So, in a normal state,
     the path from AS1 to AS20 is shorter via AS2. If this path is not
     available anymore, then the path through AS10 can be used.

         Figure may be found in the postscript version of this draft

                      Figure 2: Providing a backup path


     Another use of AS-Path prepending is to force some incoming traffic
     to follow a given path. In the example shown in figure 3, AS1
     offers the possibility to its peers to influence the redistribution
     of their routes by the use of the community attribute. Because AS2
     and AS3 carry a lot of traffic towards AS10, AS10 want to achieve
     some kind of load balancing by forcing the traffic coming from AS2
     to follow another path and ask AS1 to prepend two times to the AS-
     Path of routes announced by AS10 when they are forwarded to AS3.
     Without this change, all the traffic from both AS2 and AS3 would
     have come through AS1.  With the prepending, the path
     AS20:AS30:AS10 is shorter than AS1:AS1:AS1:AS10 and is then pre¡
     ferred.Based on the RIPE whois database in October 2001, many ISPs
     rely on communities to allow their peers (mainly customers) to
     request the utilization of AS-Path prepending when announcing some
     routes to specified external peers, at specified interconnection
     points or  in specified regions. A summary of the RIPE whois
     database may in found in table 10.

         Figure may be found in the postscript version of this draft

               Figure 3: Engineering routes to local prefixes


       +-----------+-------------------------------------------------+
       | AS number | Prepend when announcing to                      |



Quoitin and Bonaventure                                         [Page 9]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


       +-----------+-------------------------------------------------+
       | AS1755    |US upstreams/peers, European peers, specified AS |
       | AS8437    |All upstreams, specified AS, specified IX        |
       | AS2683    |Specified AS, specified IX                       |
       | AS13299   |Specified IX                                     |
       | AS13297   |Specified IX                                     |
       | AS3303    |All US peers/upstreams, specified AS             |
       | AS5571    |Specified IX                                     |
       | AS12458   |Specified IX                                     |
       | AS8918    |Specified AS, Specified IX                       |
       | AS8235    |Specified AS                                     |
       | AS13300   |Specified IX                                     |
       | AS8627    |All, specified AS, specified IX, private peers   |
       | AS6735    |Specified AS                                     |
       | AS1557    |Specified AS, specified IX                       |
       | AS15366   |Specified IX                                     |
       | AS9032    |Specified AS                                     |
       | AS8228    |Specified AS, peers inside given country or      |
       |           |continent                                        |
       | AS9109    |prepend as update crosses continent boundaries   |
       | AS12868   |All                                              |
       | AS6705    |Specified AS, specified IX                       |
       | AS5400    |AS in specified continent, specified AS          |
       | AS5511    |AS in specified continent, specified AS          |
       | AS8472    |Specified IX, specified AS                       |
       | AS1901    |AS in continent, specified AS, specified IX      |
       | AS12329   |Specified AS                                     |
       | AS12306   |Specified IX                                     |
       | AS12552   |All peers                                        |
       | AS12976   |All peers                                        |
       | AS517     |Specified AS, specified IX                       |
       | AS8582    |Specified AS                                     |
       | AS3215    |Specified IX, specified AS                       |
       | AS286     |AS in specified continent                        |
       | AS8470    |AS in country                                    |
       | AS12541   |Specified IX, specified AS                       |
       | AS3316    |All peers                                        |
       | AS13129   |Specified AS, specified IX                       |
       | AS8246    |Specified AS                                     |
       | AS1273    |Specified AS, specified IX                       |
       | AS8938    |Any upstream, specified AS                       |
       | AS8708    |Upstreams, peers                                 |
       | AS5568    |All peers                                        |
       | AS8933    |Specified AS                                     |
       | AS3259    |Peers                                            |
       | AS12779   |Upstreams, specified AS                          |
       | AS8210    |Upstreams in specified continent, specified AS   |
       | AS12832   |All                                              |



Quoitin and Bonaventure                                        [Page 10]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


       | AS3292    |US transit providers                             |
       | AS2116    |Specified AS                                     |
       | AS8503    |Peers                                            |
       | AS9057    |Specified AS                                     |
       | AS702     |All peers                                        |
       +-----------+-------------------------------------------------+

        Table 10: prepend communities documented in the RIPE database
                               in October 2001


     Usually, an AS that provides such communities relies on an unstruc¡
     tured set of communities. There are however a few exceptions.
     AS3561 (Cable & Wireless) has devised an interesting set of commu¡
     nities to allow peers to ask not to export or ask to prepend. This
     set can be found in table 11 (the list of peers to which these com¡
     munity values are supported may be found  in [CW02]).


                  +----------+---------------------------+
                  |3561:30PPN|PP is the peer code        |
                  |          |   = 1, prepend once       |
                  |          |   = 2, prepend twice      |
                  |          |   = 3, prepend three times|
                  +----------+---------------------------+

          Table 11: AS-Path prepend communities published by AS3561



     Some AS have gone one step further by reusing the community values
     in the private AS space. For example,  AS8235 (101)  has chosen to
     use  community values 6550N:AAAA to allow its customers to request
     AS8235 to prepend its AS number N times when the associated route
     is announced to AS AAAA.  AS9057 (102)
      relies even more on the community values in the private AS space.
     It uses community values from 20 different private AS numbers to
     allow its customers to indicate whether a route should or should
     not  request path prepending when a route is announced to a speci¡
     fied peer. For example,  community value 65001:XXX indicates that
     the associated route should be prepended once when announced to
     peer XXX.

  2.2.3   Setting of the local preference

     A final utilization of the communities is to set the LOCAL_PREF of
     the receiving router as documented [CB96].  This utilization of the
     BGP community attribute is still present in the RIPE whois database



Quoitin and Bonaventure                                        [Page 11]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


     and we have found that different  levels of preference are pro¡
     vided. For instance: low local preference for customer (backup),
     normal local preference for customer, high local preference for
     customer, reduced peering, normal peering, preferred interconnect
     (private peering), upstream peer and other specific preferences.In
     October 2001, 19 AS have documented their utilization of such com¡
     munities in the RIPE whois database. For example, AS702 (UUNET
     Europe) defines the 2 communities shown in table 12.


                  +-------+-------------------------------+
                  |702:80 |Set Local Pref 80 within AS702 |
                  +-------+-------------------------------+
                  |702:120|Set Local Pref 120 within AS702|
                  +-------+-------------------------------+

                   Table 12: Communities defined by AS702


3   Analysis of BGP routing tables

      Section 2 has described the most common utilizations of the BGP
     community attribute. From the description above, one could expect
     that community values should rarely appear in the global Internet
     routing tables since most communities are used to tag routes inside
     a given AS or to influence the redistribution of routes by a given
     AS.To verify this assumption, we have conducted an analysis of BGP
     routing tables collected by  RIPE RIS project [RIS02] and the Route
     Views project (University of Oregon, [Mey02]) during the period
     January 2001 - January 2002.  The detailed results of this analysis
     can be found in [QB02].A first observation of those BGP table dumps
     shows that the BGP community  attribute is widely used, even in the
     global Internet.  For instance, at RIPE NCC, Amsterdam, the number
     of communities has increased to more than 1000 distinct values at
     the beginning of the year 2002 while nearly 50% of the routes
     advertised to the test router maintained by RIPE  had at least one
     community attached ! We could see the same evolution at other sites
     except at Otemachi, Japan where no community appears. A short sum¡
     mary can be found in table 13.


                  +----------------------+-------+-------+
                  |Site                  |Percent|Number |
                  |                      |age of |of     |
                  |                      |routes |distinc|
                  |                      |contain|t commu|
                  |                      |ing    |nities |
                  |                      |communi|       |



Quoitin and Bonaventure                                        [Page 12]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


                  |                      |ties   |       |
                  +----------------------+-------+-------+
                  |RIPE NCC, Amsterdam   |41 %   |1233   |
                  +----------------------+-------+-------+
                  |LINX, London          |7 %    |668    |
                  +----------------------+-------+-------+
                  |SFINX, Paris          |19 %   |38     |
                  +----------------------+-------+-------+
                  |AMS-IX, Amsterdam     |0.4 %  |134    |
                  +----------------------+-------+-------+
                  |CIXP, Geneva          |2.3 %  |259    |
                  +----------------------+-------+-------+
                  |VIX, Vienna           |84 %   |529    |
                  +----------------------+-------+-------+
                  |JPIX, Otemachi (Japan)|0 %    |0      |
                  +----------------------+-------+-------+
                  |University of Oregon  |62.1 % |1774   |
                  +----------------------+-------+-------+

              Table 13: Utilization of communities (Jan 2002).


     While thuse numbers clearly indicate the widespread utilization of
     the  BGP community attribute, they do not distinguish between route
     tagging and redistribution communities. To understand the types of
     communities that are used, we have built a database with the commu¡
     nities documented in the RIPE whois database [RIW02] and various
     web sites of ISPs [TI02, JI02, NE02, CPL00, SPR02, CW02]. However,
     it should be noted that our database is far from complete since
     some ASs do publish the description of the communities that their
     peers can use. Despite of this, we can already find some interest¡
     ing results.In table 14, we have classified the communities in
     three classes. The ``Tagging'' class corresponds to the communities
     discussed in section 2.1 while the ``TE'' class corresponds to the
     the communities that affect the redistribution of the routes as
     discussed in section 2.2.  The unknown class contains the community
     values that are not in our database.  A graphical evolution of this
     classification can be found in [QB02] for the period January 2001
     to January 2002. Our analysis shows that the ``Tagging'' and ``TE''
     communities  represent a great large of fraction the total number
     of communities found in the studied BGP routing tables.


               +----------------------+------+-------+-------+
               |AS                    |TE    |Tagging|Unknown|
               +----------------------+------+-------+-------+
               |RIPE NCC, Amsterdam   |60345 |331316 |758089 |
               +----------------------+------+-------+-------+



Quoitin and Bonaventure                                        [Page 13]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


               |LINX, London          |14371 |16283  |13315  |
               +----------------------+------+-------+-------+
               |SFINX, Paris          |31    |8      |261    |
               +----------------------+------+-------+-------+
               |AMS-IX, Amsterdam     |462   |356    |1868   |
               +----------------------+------+-------+-------+
               |CIXP, Geneva          |11879 |5473   |3270   |
               +----------------------+------+-------+-------+
               |VIX, Vienna           |39626 |42056  |14006  |
               +----------------------+------+-------+-------+
               |JPIX, Otemachi (Japan)|0     |0      |0      |
               +----------------------+------+-------+-------+
               |University of Oregon  |314841|388406 |2125204|
               +----------------------+------+---------------+

              Table 14: Classification of routes on (Jan 2002).


     The large number of ``Unknown'' communities in table 14 is due to
     our incomplete database. However, a closer look at those
     ``Unknown'' communities reveals some interesting points. First,
     some AS using community values in the space considered as reserved
     (0x00000000 - 0x0000ffff and 0xffff0000 - 0xffffffff) by [TCL96].
     We have seen routes from multiple peers using community values in
     this range and one peer had announced more than 60k routes with
     such a community value. Second, we also see some utilization of
     community values in the private  AS space range (i.e. 64512:0 -
     65534:65534), but the number of routes with such communities is
     smaller than those with reserved community values.

4   Conclusion

      In this document, we have described two of the main utilizations
     of the BGP community attribute in the global Internet.  The first
     common utilization of this attribute is to tag the routes received
     through an eBGP session with an explicit indication of the location
     (city, country, interconnection point, ...) where the route was
     learned. The main reason to utilize route tagging communities is
     that when it is used on all border routers of a given AS, then all
     routers of the AS can be configured to make their routing decisions
     mainly on the basis of those communities. Our analysis of the BGP
     table dumps and the RIPE whois database shows that this type of BGP
     communities is often used in today's Internet.A second common uti¡
     lization is to affect the redistribution of the associated route by
     downstream routers. In this case, the community value is associated
     to a route by the router sending the router to indicate to the
     remote eBGP peer how the route should be redistributed. We have
     seen several types of such communities.  The two most common cases



Quoitin and Bonaventure                                        [Page 14]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


     are used to request that a route should not be announced to a spec¡
     ified (set of) peer(s)  and to request the route to be prepended
     when announced to a specified (set of) peer(s). Our analysis of the
     RIPE whois database has shown that a large number of AS are using
     such communities today.  Furthermore, some AS have chosen to rely
     on BGP community values in the private in order to have more struc¡
     tured community values. If this utilization of the BGP community
     values in the private space would become a widely used  solution
     since there is no coordination between the AS about the utilization
     of those communities. A much better solution would be to define a
     set  of ``well-known'' structured community values to support the
     needs of those AS. A proposal based on the utilization of the
     extended communities attribute may be found in [BCH^+02].

Acknowledgments

      This work was partially funded by the European Commission within
     the IST ATRIUM project.

      This work would not have been possible without the very useful
     information provided by the RIPE RIS project, the RIPE WHOIS
     database and the RouteViews project.

Author's Addresses

   Bruno Quoitin and Olivier Bonaventure
   Infonet group (FUNDP)
   Rue Grandgagnage 21, B-5000 Namur, Belgium
   Email: Olivier.Bonaventure@info.fundp.ac.be, Bruno.Quoitin@info.fundp.ac.be
   URL  : http://www.infonet.fundp.ac.be


References

   [BCH^+02]  O. Bonaventure, S. De Cnodder, J. Haas, B. Quoitin, and R.
   White. Controlling the redistribution of bgp routes. Internet draft,
   draft-bonaventure-bgp-redistribution-02.txt, work in  progress (to
   appear), February 2002.

   [CAI02]  Cooperative Association for Internet Data Analysis CAIDA.
   Analysis of BGP data from Oregon Route Views. available from
   http://www.caida.org/ broido/bgp/bgp.html, January  2002.

   [CB96]  E. Chen and T. Bates. An Application of the BGP Community
   Attribute in  Multi-home Routing. Internet Engineering Task Force,
   RFC1998, August 1996.

   [CPL00]  Connect.com.au Pty Ltd. FAQ on Multi-homing and BGP.



Quoitin and Bonaventure                                        [Page 15]


draft-quoitin-bgp-comm-survey-00.txt                       February 2002


   available from http://info.connect.com.au/docs/routing/general/multi-
   faq.shtml, June 2000.

   [CW02]  Communities defined by Cable & Wireless. available from
   http://infopage.cary.cw.net/Routing_Registry/communities.htm, January
   2002.

   [HB96]  J. Hawkinson and T. Bates. Guidelines for creation, selec¡
   tion, and registration of an  Autonomous System (AS). Internet Engi¡
   neering Task Force, RFC1930, March 1996.

   [Hus02]  G. Huston. Telstra Internet Network Performance Reports -
   BGP  Table size. available from http://www.telstra.net/ops/bgp, Jan¡
   uary 2002.

   [JI02]  Communities defined by Jippii. available from http://www.jip¡
   pii.net/communities.html, January 2002.

   [Mey02]  D. Meyer. Route Views Archive project. University of Oregon,
   http://archive.routeviews.org, January 2002.

   [NE02]  Communities defined by Nescalibur. available from
   http://www.noc.esib.net/bgp_communities, January  2002.

   [QB02]  B. Quoitin and O. Bonaventure. Utilization of the BGP Commu¡
   nities attribute. Infonet Group, University of Namur,
   http://alpha.infonet.fundp.ac.be/anabgp, January 2002.

   [RIS02]  Routing Information Service project. R‰seaux IP Europ‰ens,
   http://www.ripe.net/ripencc/pub-services/np/ris-index.html, January
   2002.

   [RIW02]  Whois database. RIPE NCC, http://abcoude.ripe.net/ris/raw¡
   data, January 2002.

   [SPR02]  Sprintlink BGP FAQ. available from
   http://www.sprint.net/faq/bgp.html#control, January  2002.

   [TCL96]  P. Traina, R. Chandrasekeran, and T. Li. BGP Communities
   Attribute. Internet Engineering Task Force, RFC1997, August 1996.

   [TI02]  Communities defined by Tiscali Intl Network. available from
   http://www.as3257.net/html/communities.htm, January 2002.








Quoitin and Bonaventure                                        [Page 16]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/