One document matched: draft-bonaventure-quoitin-bgp-communities-00.txt
Internet Engineering Task Force Olivier Bonaventure
INTERNET DRAFT UCL
Bruno Quoitin
FUNDP
June, 2003
Expires December, 2003
Common utilizations of the BGP community attribute
draft-bonaventure-quoitin-bgp-communities-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
Since its introduction in RFC1997, the BGP community attribute has
been used by many Autonomous Systems to build more scalable routing
policies. We describe here the most common utilizations of the BGP
community attribute and provide some examples.
1 Introduction
The BGP Community attribute is an optional transitive attribute
introduced in RFC1997 [TCL96] to help scale the management of routes
within an AS. This attribute consists of a set of four octet values,
each of which specifies a community value. [TCL96] reserves for
standard use the community values ranging from 0x0000000 through
0x0000ffff and 0xffff0000 through 0xffffffff. Among them, three
Bonaventure/Quoitin [Page 1]
draft-bq-bgp-communities-00.txt June 2003
communities are defined with global significance: NO_EXPORT
(0xffffff01) which mark routes that should not be advertised outside
a BGP confederation, NO_ADVERTISE (0xffffff02) which mark routes that
must not be advertised to other peers, and NO_EXPORT_SUBCONFED
(0xffffff03) which mark routes that must not be advertised to peers
outside the boundary of a subconfederation.
Besides those reserved community values, a lot of room is left for
experimentation, creativity and so on. [TCL96] proposed nevertheless
to equally delegate this remaining community space to all the ASes.
For this purpose, the remaining community values were divided by
using an AS number in the two high-order octets. Thus, each AS
received 65536 values of the community space, meaning that for
instance, ASx is free to use community values ranging from ASx:0 to
ASx:65535. However, [TCL96] did not specify whether the community
values corresponding to the private AS space (i.e. community values
64512:00 - 65534:65535 as defined in [HB96]) could be used in the
global Internet.
Since the introduction of the community attribute, it has been used
for various purposes by ISPs. A recent analysis of the BGP routing
tables [QUB02] revealed that, depending on the measurement point,
between 40% and 50% of the routes contained in those tables carried a
community attribute with up to several dozens of distinct community
values inside some routes. Despite this widespread utilization of
community values, there is, to our knowledge, no public document
describing the main utilizations of this attribute except [CB96], but
this document only covers a very limited utilization of the community
attribute.
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 on
discussions with ISPs. This document is organized as follows. First,
we discuss in section 2 the current utilizations of the BGP community
attribute and provide several examples. We discuss the problem of
documenting community values in section 3 and some operational issues
in section 4. Then, in section 5 we discuss the problem of encoding
those policies in a limited number of community values and provide
several examples from ISPs.
We do not discuss in the document the utilization of communities or
extended communities to support VPN services [RR99] or to block
denial of service attacks [Tur03].
2 Common utilizations of the BGP Community attribute
The operation of a BGP router can be summarized as a set of
Bonaventure/Quoitin [Page 2]
draft-bq-bgp-communities-00.txt June 2003
operations performed on each received BGP UPDATE message announcing
one or several prefixes. First, the received UPDATE messages are
placed unprocessed in the Adj-RIB-In of the BGP peer from which the
messages were received.
A per-peer import policy is applied by the BGP router to determine
which received messages will be placed in the Loc-RIB. The
application of the import policy may result in the modification of
some attributes of the selected messages (e.g. addition of local-
pref). The BGP-decision process is then applied to the content of the
Loc-RIB to select a best route toward each destination. The BGP
router will then use a per-peer export policy to determine which
routes of the Loc-RIB will be placed in the Adj-RIB-Out of each peer.
The application of the export policy may result in the modification
of some attributes of the message placed inside the Adj-RIB-Out. A
more detailed description of the operation of BGP may be found in
[RLH02].
+--------+ +---------+
| Prov1 | | Prov2 |
|[London]| | [Miami] |
| RD | | RC | +--------+
+-----\-+ +--//-----+ | Peer2 |
\ // | RB |
+-------+ +------\---//---------+ | // |
| | | RW1 RW2 | +//------+
| RA=========RX ASX RY===IX [Brussels]
|[Oslo] | | | \
|Peer1 | | RZ1 RZ2 | +-\-----+
+-------+ +------//-----\-------+ | RC |
// \ | |
+-----//-+ +--\-----+ | Peer3 |
| RH | | RI | +--------+
|[Paris] | |[Tokyo] |
| Cust1 | | Cust2 |
+--------+ +---------+
Figure 1: Reference configuration
In this document, we utilize the reference environment shown in
figure 1 and focus on ASX in the middle of the figure. This AS has
two upstream providers (Prov1 and Prov2, three peers (Peer1, Peer2
and Peer3) and two customers (Cust1 and Cust2). Note that the
examples given in the document may not include all the ASes that
appear in figure 1.
To better understand the utilization of the BGP community values, it
is useful to introduce a small classification that we will use
Bonaventure/Quoitin [Page 3]
draft-bq-bgp-communities-00.txt June 2003
throughout this document. We are conscious that such a classification
is somewhat approximate because communities were designed as an open-
ended attribute. This classification nevertheless helps to explain
today's common practices.
Although the BGP community values are defined as opaque values, most
utilizations of those values can be divided in a few subtypes. In the
remainder of this document, we will use the word local to indicate
that a community value was attached by a router belonging to the AS
to which this community has been delegated by [TCL96]. We will use
the word foreign for a community value attached by a router belonging
to a different AS. For example, in figure 1, community value ASX:123
would be considered as local if attached by router RX and foreign if
attached by router RA.
A second classification of the community values can be defined on the
basis of how they influence the processing of the BGP UPDATE
messages. We call informational a community value that only provides
information and does not directly affect the processing of BGP UPDATE
messages. Those community values are typically used to aid debugging
or to provide information to allow remote peers to determine which
remotely attached communities should be used to influence the
processing of the BGP UPDATEs by distant BGP routers.
We call coloring community a community value that is used to color
the routes sharing a given property. Those colors may influence the
processing of the BGP UPDATE messages by some routers. Finally, we
call signalling community a community value that is used to
explicitly request a downstream router or AS to perform a given
action when receiving a BGP UPDATE message with this community value
attached.
In this section, we will refer to the community values by using
symbolic names and examples. We discuss the encoding of those
symbolic community values inside 32 bits wide community values in
section 5.
2.1 Informational communities
Informational communities are usually attached by their owner. Those
values are used by an AS to indicate the location where the route was
originated or received from an external peer. Many ASes have
documented the utilization of such communities today. Based on the
needs of each AS, different types of locations are used in practice :
geographic location, interconnection point, or autonomous system
(AS).
Bonaventure/Quoitin [Page 4]
draft-bq-bgp-communities-00.txt June 2003
2.1.1 Geographic location
Network operators often want to tag routes with the geographic
location where they were learned. The types of geographic locations
used by each AS depend on the size of this AS. A national AS might
want to tag the city where each route was learned, while an
international AS would instead tag each route with the country or
continent where it was learned.
For example, in our reference configuration, ASX could define several
community values inside its community space to tag the city and the
continent where each route was learned. In this case, router RY would
append community values ASX:Brussels,ASX:Europe to the routes learned
from Peer2 and Peer3 while router RZ2 would attach community values
ASX:Tokyo,ASX:Asia.
This geographical information can be used for several purposes.
First, it can be useful for debugging purposes. Second, the
geographical information can be used by customers or possibly peers
to aid in the selection of their best route. For example, consider a
content provider with servers located in Paris, Tokyo, New-York and
San Francisco. Based on the informational communities advertised by
its peers, this content provider could configure its BGP routers in
Paris to prefer the routes originated in Europe or learned from
European peers, while the BGP routers in Tokyo could be configured
to prefer the routes learned from Asian peers, ....
2.1.2 Interconnection point
In some cases, ASes also utilize communities to indicate the
interconnection point where each route was learned. Knowing the
interconnection point where a route was learned can be useful for
debugging purposes or used by remote peers as discussed above.
For example, in our reference configuration, ASX could define one
distinct community value for each IX where it is present. If ASX
uses those community values, router RY would append community value
ASX:IX to the routes learned from Peer2 and Peer3.
A few ASes also use informational 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 to simplify the configuration of some routers.
2.2 Coloring communities
Bonaventure/Quoitin [Page 5]
draft-bq-bgp-communities-00.txt June 2003
A second type of BGP communities are those that are used to color
routes sharing the same property. Those community values are usually
local.
Coloring communities are typically used by large ISPs to build
scalable routing policies. In this case, the ISP defines a few types
of BGP peers (typically customer, peering partner and transit
provider) and tags each received route with a community indicating to
which types of peers the received route should or should not be
advertised. This tagging can be used to ensure that customers
receive all routes and that peers and providers only receive the
internal and customer routes.
For example, in our reference environment, ASX supports three types
of peers : customers, peers and providers. ASX could want to
configure its routers to ensure that the routes received from
customers are advertised to customers, peers and providers while the
routes learned from providers or peers are only advertised to
customers. This routing policy can be achieved by defining three
community values. ASX:ToCustomers would be used to tag a route that
needs to be announced to customers, ASX:ToProviders to providers and
ASX:ToPeers to peers. In this case, router RX would append
AS:ToCustomers to the routes learned from Peer1 while router RZ2
would append ASX:ToCustomers,ASX:ToPeers,ASX:ToProviders to the
routes learned from Cust2. Router RX would also be configured to only
advertise the routes with the AS:ToPeers community value on the eBGP
session with Peer1. Router RZ2 would be configured to only advertise
the routes with the AS:ToCustomers on the eBGP session with Cust2.
Coloring communities can also be used to provide different services
to different customers. For example, a provider could offer a cheaper
limited transit service in which only the customers and the peers of
this ISP are reachable. In our reference configuration, this can be
achieved by using two types of local coloring communities. First, the
routes learned from a customer with a limited transit service would
be tagged with only the ASX:ToCustomers community value. Second,
communities would be defined to tag the type of peer from which a
route has been learned. The export policies of the BGP sessions
attached to customers with a limited transit service would then be
configured to only announce the routes learned from customers.
By using additional community values, it is possible to support
different types of transit service, for example on a geographical
basis.
2.3 Signalling communities
In addition to the local coloring community values that are widely
Bonaventure/Quoitin [Page 6]
draft-bq-bgp-communities-00.txt June 2003
used by ISPs today, several ISPs have deployed signalling community
values that can be used by their customers to influence the
distribution of their routes to remote ASes. A first type of such
communities are the ``do not announce'' communities. In this case,
the community is attached to a route to indicate that this route
should not be announced to a specified peer, at a specified
interconnection point or to a given set of peers.
For example, in our reference environment, ASX could allow its
customers to indicate which routes should not be announced to each of
its upstream providers, peers or at the IX. This can be achieved by
defining several community values. For example, a route containing
the ASX:NotProv1 would not be announced to provider Prov1.
Several tens of ASes have documented their support for this kind of
community values [QB02]. Many ASes utilize community values to
indicate that a route should not be announced to a given AS or at a
given interconnection point. Some ASes also allow the utilization of
such communities to indicate that a route should not be announced
outside a given region or continent.
To support the utilization of those ``do not announce'' communities,
an ISP should rely on the appropriate informational communities. For
example, if an ISP wishes to allow its customers to utilize ``do not
announce'' communities targeted at a given interconnection point,
then it would be useful to also support informational communities
that allow its customers to determine at which interconnection point
each route was learned.
Besides requesting that a route should not be announced to a given
peer, remotely attached export communities are also often used to
request the utilization of AS-Path prepending when announcing a route
to a specified peer or set of peers. This can also be achieved by
defining several community values. For example, ASX could configure
its routers to prepend once (resp. three times) its own AS number
when advertising to Prov1 a route containting the ASX:Prepend1Prov1
(resp. ASX:Prepend3Prov1) community value.
Based on the content of the RIPE whois database in October 2001, many
ISPs rely on remotely attached export communities to allow their
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 [QB02].
A final utilization of the signalling communities is to influence the
BGP decision process by setting the LOCAL_PREF attribute of received
routes while applying the import policy as documented in [CB96].
This utilization of the BGP community attribute is still present in
Bonaventure/Quoitin [Page 7]
draft-bq-bgp-communities-00.txt June 2003
the RIPE whois database and [QB02] has found that different levels
of preference are provided. 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 our reference configuration, ASX could allow its
customers to set the value of the preference at 80 or 120 instead of
its default of 100 inside ASX by using community values
ASX:Pref80,ASX:Pref120.
3 Documenting community values
Autonomous Systems relying on BGP community values to implement
scalable routing policies will often need to document the chosen
community values. This documentation can be internal to the AS in the
case of local community values, but often it needs to be distributed
to peers and customers.
Since the RPSL language [AVG^+99] was defined to specify routing
policies, it would be normal to use it to precisely define the
utilization of the community values inside an AS. RPSL contains
several constructs that can be used to define this utilization of the
community values, but unfortunately, a precise RPSL specification of
a routing policy with several community values becomes quickly
difficult to read.
Due to the difficulty of documenting the utilization of community
values by using RPSL, many ASes have chosen to provide in their RPSL
policy, a set of remarks that informally describe the community
values supported by this AS. This textual information is often
sufficient to allow a human operator to determine the meaning of a
given community value, but unfortunately it cannot be processed by
tools that build or verify router configurations.
4 Operational issues
The BGP Community attribute is a transitive optional attribute. ASes
that do not utilize BGP community values in their router's
configurations usually do not change the content of the BGP community
attribute of received UPDATE messages.
An AS willing to utilize informational, coloring or signalling
community values should first install filters on its ingress and
egress BGP routers. Those filters will depend on the types of
community values that are used by the AS.
If the AS uses informational communities, then its ingress BGP router
should be configured to remove those community values from the UPDATE
Bonaventure/Quoitin [Page 8]
draft-bq-bgp-communities-00.txt June 2003
messages received over eBGP sessions. If those communities are only
used internally and are not documented, then they should also be
removed from the UPDATE messages sent to external peers since those
values do not carry information understandable by the global
Internet. If those communities are documented and are useful for
external peers, they may be left in the UPDATE messages sent to
external peers. In practice, it can be expected that few external
ASes will utilize the informational communities defined by other
ASes. To avoid polluting the BGP routing tables, an AS should only
send its local informational community values to interested BGP
peers, typically only to its own customers.
If the AS uses local coloring community values, then its ingress BGP
routers should be configured to remove those community values if they
are found inside UPDATE messages received from external peers.
Furthermore, since those community values have only a meaning inside
the AS, they should be removed from the UPDATE messages sent over
eBGP sessions to avoid polluting the BGP routing tables of the entire
Internet.
If the AS supports signalling community values, then it would
typically configure its ingress filters to only allow those community
values over eBGP sessions with customers and remove such communities
from UPDATE messages received over eBGP sessions with peers and
providers. Since those community values have only a local meaning,
they should be removed from the UPDATE messages sent to any external
peer.
Another problem that should be taken into account is the aggregation
of routes containing BGP community values. In [TCL96] the rule
proposed to aggregate such routes is to place inside the aggregated
route all the community values found in the individual routes. This
rule is applicable for information community values, but using it to
aggregate routes containing coloring or signalling community values
could cause problems. Unfortunately, the encoding of the community
values does not usually allow a router to determine the type of a
given community value.
5 Encodings of BGP communities
A practical issue that occurs when using community values to support
routing policies as described in the previous section is that each AS
needs to define the numerical values that it will support. In
practice, a constraint on this encoding is that each AS has only been
delegated a space of 65536 distinct community values [TCL96]. In this
section, we briefly describe several encodings found in the RIPE
whois database.
Bonaventure/Quoitin [Page 9]
draft-bq-bgp-communities-00.txt June 2003
5.1 Informational communities
As discussed in section 2.1, the informational communities can be
used to tag the geographical location, the AS and the IX at which
each route was learned.
5.1.1 Geographic location
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 Telecommunications, Inc.) defined
in [RIW02] the values shown in table 2 to tag routes learned in
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 |
-----------------------
Table 2: Tagging communities published by AS13129
Some ASes have devised structured encodings of those route tagging
community values such as the one documented by AS286 (EUnet) shown in
table 3. With this encoding, the value used to tag a received route
is based on the telephone country code. These communities are
documented in [RIW02]. For example, according to this community
setting, a route with community 286:3032 would have been learned by
EUnet from a customer located in Belgium.
-----------------------------------------------------------
| 286:1000 + countrycode |Public peer routes |
-----------------------------------------------------------
| 286:2000 + countrycode |Private peer routes |
-----------------------------------------------------------
| 286:3000 + countrycode |Customer routes |
-----------------------------------------------------------
Bonaventure/Quoitin [Page 10]
draft-bq-bgp-communities-00.txt June 2003
|where countrycode is the E.164 international dial prefix.|
-----------------------------------------------------------
Table 3: Tagging communities published by AS286
Another example is the encoding chosen by AS3561 (Cable & Wireless)
shown in table 4 that relies 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 4: Informational communities used by AS3561
5.1.2 Informational communities indicating IXes
Example of such informational communities, documented by AS13129 in
[RIW02], are shown in table 5. We have not encountered structured
encodings for the community values used to tag the interconnection
point where routes were learned.
-------------------
|13129:2110|DE-CIX|
-------------------
|13129:2120|INXS |
-------------------
|13129:2130|SFINX |
-------------------
|13129:2140|LINX |
-------------------
Table 5: Tagging communities published by AS13129
5.2 Signaling and coloring communities
In this section, we provide example encodings of signaling and
coloring communities based on information found in the RIPE whois
database [RIW02].
5.2.1 Coloring communities
In this case, those community values are only used inside the AS and
they are usually not documented.
5.2.2 Signalling communities
Most of the ASes that support signalling communities rely on a
Bonaventure/Quoitin [Page 11]
draft-bq-bgp-communities-00.txt June 2003
structured list of community values for this purpose. For example,
table 6 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 6: ``Do not announce'' communities used by AS1755
However, a few ASes rely on a more structured encoding of the
community values used for this purpose. For example, AS9057/AS3356
(Level3) has chosen to reuse a range of community values
corresponding to the private AS space as shown in table 7.
--------------------------------------------------
| Value |Meaning |
--------------------------------------------------
|65000:XXX |do not announce on peerings to AS XXX|
| 65001:0 |prepend once to all peers |
|65001:XXX |prepend once at peerings to AS XXX |
| 65002:0 |prepend twice to all peers |
|65002:XXX |prepend twice at peerings to AS XXX |
--------------------------------------------------
Table 7: ``Do not announce'' communities used by AS9057/AS3356
Similar encodings are used for signalling communities requesting AS-
Path prepending. For example, AS3561 (Cable & Wireless) has devised
an interesting set of communities to allow peers to ask not to export
or ask to prepend. This set can be found in table 8 (the list of
peers to which these community values are supported may be found in
[CW02]).
----------------------------------------
|3561:30PPN|PP is the peer code |
| |N = 0, do not export |
| | = 1, prepend once |
| | = 2, prepend twice |
| | = 3, prepend three times|
----------------------------------------
Table 8: Signalling communities supported by AS3561
Bonaventure/Quoitin [Page 12]
draft-bq-bgp-communities-00.txt June 2003
Before deploying signalling communities, ISPs should note that the
IETF is currently developing a new type of extended communities
[BCH^+03] called ``redistribution communities''. Those redistribution
communities can be used to influence the export policy of routers.
Compared to the signalling communities, the redistribution
communities have two advantages. First, ISPs willing to support them
do not have to configure complex policies on their routers. This
simplifies the configuration of routers and reduces the risk of
misconfiguration. Second, the redistribution communities are non-
transitive. This reduces the risk of polluting the BGP routing
tables.
Finally, the community values suggested in [CB96] are still used
today. A typical example of the encoding of those communities is the
one used by AS702 (UUNET Europe). This encoding is based on the 2
community values shown in table 9.
-----------------------------------------
|702:80 |Set Local Pref 80 within AS702 |
-----------------------------------------
|702:120|Set Local Pref 120 within AS702|
-----------------------------------------
Table 9: Signalling communities defined by AS702
6 Conclusion
In this document, we have described the main utilizations of the BGP
community attribute in the global Internet. We have shown that
several types of community values are used in practice.
Some community values are purely informational. Community values can
also be used to color routes sharing the same property. Other
community values are used for signalling purposes, for example by
setting the value of local-pref. We have also provided several
examples and discussed configuration guidelines.
Given the widespread utilization of community values in the global
Internet, it might be useful to define a few sets of standardized
community values to better support the common needs of various ISPs.
For example, if a single type of informational community value
indicating the geographical origin of a route could be defined, then
it could be used by any BGP router. Today, each AS defines its own
type of informational community.
ISPs willing to support signalling community values could consider
the utilization of the redistribution communities, a standardized
type of extended communities being defined by the IETF [BCH^+03].
Bonaventure/Quoitin [Page 13]
draft-bq-bgp-communities-00.txt June 2003
Another issue is that due to the utilization of community values, it
becomes cumbersome to precisely specify the routing policies used by
ISPs with RPSL. Most ISPs only document the community values used as
remarks in their RPSL policies. This implies that the RPSL policies
stored in the IRR do not reflect the deployed policies and it thus
becomes impossible to utilize tools to check the consistency of the
Internet routing policies.
Acknowledgements
This work was partially supported by the European Commission within
the IST ATRIUM project. We would like to thank RIPE for their whois
database and the RIPE RIS project. We thank Tim Griffin for his
comments.
References
[AVG^+99] C. Alaettinoglu, C. Villamizar, E. Gerich, D.
Kessens, D. Meyer, T. Bates, D. Karrenberg, and M. Terpstra.
Routing Policy Specification Language (RPSL). Internet
Engineering Task Force, RFC2622, June 1999.
[BCH^+03] O. Bonaventure, S. De Cnodder, J. Haas, B. Quoitin,
and R. White. Controlling the redistribution of BGP routes.
Internet draft, draft-ietf-grow-bgp-redistribution-00.txt,
work in progress, June 2003.
[CB96] E. Chen and T. Bates. An Application of the BGP
Community Attribute in Multi-home Routing. Internet
Engineering Task Force, RFC1998, August 1996.
[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,
selection, and registration of an Autonomous System (AS).
Internet Engineering Task Force, RFC1930, March 1996.
[QB02] B. Quoitin and O. Bonaventure. A survey of the
utilization of the BGP community attribute. Technical report
Infonet-TR-2002-02, http://www.infonet.fundp.ac.be/doc/tr/,
March 2002.
[QUB02] B. Quoitin, S. Uhlig, and O. Bonaventure. Using
redistribution communities for interdomain traffic
engineering. In COST263 Workshop of Quality of future
Internet Services, LNCS. Springer-Verlag, October 2002.
Bonaventure/Quoitin [Page 14]
draft-bq-bgp-communities-00.txt June 2003
[RIW02] Whois database. RIPE NCC,
http://abcoude.ripe.net/ris/rawdata, January 2002.
[RLH02] Y. Rekhter, T. Li, and S. Hares. A Border Gateway
Protocol 4 (BGP-4). Internet draft,
draft-ietf-idr-bgp4-18.txt, work in progress, October 2002.
[RR99] E. Rosen and Y. Rekhter. BGP/MPLS VPNs. Request for
Comments 2547, Internet Engineering Task Force, March 1999.
[TCL96] P. Traina, R. Chandrasekeran, and T. Li. BGP
Communities Attribute. Internet Engineering Task Force,
RFC1997, August 1996.
[Tur03] D. Turk. Configuring bgp to block denial-of-service
attacks. Internet draft, draft-turk-bgp-dos-04.txt, work in
progress, January 2003.
Authors' Addresses
Olivier Bonaventure
Universite catholique de Louvain (UCL), Belgium
URL : http://www.info.ucl.ac.be/people/OBO/
Bruno Quoitin
Infonet group, University of Namur (FUNDP)
Rue Grandgagnage 21, B-5000 Namur, Belgium
Email: Bruno.Quoitin@info.fundp.ac.be
Bonaventure/Quoitin [Page 15]
| PAFTECH AB 2003-2026 | 2026-04-23 11:26:26 |