draft-ietf-ptomaine-bgp-redistribution-00.txt   draft-ietf-ptomaine-bgp-redistribution-01.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
Internet Engineering Task Force Olivier Bonaventure Internet Engineering Task Force Olivier Bonaventure
INTERNET DRAFT FUNDP INTERNET DRAFT FUNDP
Stefaan De Cnodder Stefaan De Cnodder
Alcatel Alcatel
Jeffrey Haas Jeffrey Haas
NextHop NextHop
Bruno Quoitin Bruno Quoitin
FUNDP FUNDP
Russ White Russ White
Cisco Cisco
April, 2002 August, 2002
Expires October, 2002 Expires February, 2002
Controlling the redistribution of BGP routes Controlling the redistribution of BGP routes
<draft-ietf-ptomaine-bgp-redistribution-00.txt> <draft-ietf-ptomaine-bgp-redistribution-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 47 skipping to change at page 1, line 47
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document proposes the redistribution extended community. This This document proposes the redistribution extended community. This
new extended community allows a router to influence how a specific new extended community allows a router to influence how a specific
route should be redistributed towards a specified set of eBGP route should be redistributed towards a specified set of eBGP
speakers. Several types of redistribution communities are proposed. speakers. Several types of redistribution communities are proposed.
The first type may be used to indicate that a specific route should The first type may be used to indicate that a specific route should
not be announced to the specified set of eBGP speakers. The second not be announced over a specified set of eBGP sessions. The second
type may be used to indicate that the attached route should only be type may be used to indicate that the attached route should only be
announced with the NO_EXPORT community to the specified set of eBGP announced with the NO_EXPORT community over the specified set of eBGP
speakers and the third type may be used to indicate that the attached sessions and the third type may be used to indicate that the attached
route should be prepended n times when announced to the specified set route should be prepended n times when announced over a specified set
of eBGP speakers. of eBGP sessions.
1 Introduction 1 Introduction
In today's commercial Internet, many ISPs need to have some control In today's commercial Internet, many ISPs need to have some control
on their interdomain traffic. In the outgoing direction, this control on their inter-domain traffic. In the outgoing direction, this
can be obtained by configuring the BGP routers of the ISP to favor control can be obtained by configuring the BGP routers of the ISP to
some routes over others by using the LOCAL-PREF attribute. However, favor some routes over others by using the LOCAL-PREF attribute.
due to the assymetry of Internet traffic, most ISPs also need to However, due to the asymetry of Internet traffic, most ISPs also need
control their incoming traffic. to control their incoming traffic.
+---------------+ +---------------+
| | | |
| AS22 | | AS22 |
| | | |
+---------------+ +---------------+
|| ||
+---------------+ +---------------+ +---------------+ +---------------+
| 13.0.0.0/8 | | AS21 | | 13.0.0.0/8 | | AS21 |
| 12.0.0.0/8 |===============| | | 12.0.0.0/8 |===============| |
| AS20 | +---------------+ | AS20 | +---------------+
+---------------+ +---------------+
|| ||
+---------------+ +---------------+
| | | |
| AS10 | | AS10 |
| | | |
+---------------+ +---------------+
Figure 1: Simple interdomain topology Figure 1: Simple inter-domain topology
In the incoming direction, the only way to influence the traffic flow In the incoming direction, the only way to influence the traffic flow
is to control the redistribution of its routes. Several methods exist is to control the redistribution of its routes. Several methods exist
and are used in practice [Hal97,QuB02]. In this case, the ISP needs and are used in practice [Halabi97,COM-SUR]. In this case, the ISP
to influence the redistribution and the selection of its own routes needs to influence the redistribution and the selection of its own
by remote ISPs. Since the default configuration of many BGP routers routes by remote ISPs. Since the default configuration of many BGP
is to select the route with the smallest AS path length, a common routers is to select the route with the smallest AS path length, a
technique is to artificially increase the length of the AS path for common technique is to artificially increase the length of the AS
some announced routes. For example, in figure 1, if AS20 wanted to path for some announced routes. For example, in figure 1, if AS20
indicate that it prefers to receive its traffic towards subnet wanted to indicate that it prefers to receive its traffic towards
13.0.0.0/8 through its link with AS22, then it would announce this subnet 13.0.0.0/8 through its link with AS22, then it would announce
prefix as usual on this link to AS22 and announce a prefix with the this prefix as usual on this link to AS22 and announce a prefix with
AS20:AS20:AS20:AS20 path to AS21 and AS10. If AS10 and AS21 rely only the AS20:AS20:AS20:AS20 path to AS21 and AS10. If AS10 and AS21 use
on the AS path length to select the best BGP route, they will prefer the AS path length to select the best BGP route, they will prefer the
the shorter route received by AS22. This requires a manual shorter route received by AS22. This requires manual configuration of
configuration of the BGP routers, but path prepending is very the BGP routers, but path prepending is very frequently used today on
frequently used today on the Internet [Hus01]. In some cases, the the Internet [Huston01]. In some cases, the configuration burden can
configuration burden can be reduced by using the BGP communities be reduced by using the BGP communities attribute.
attribute.
Recently, several large ISPs have gone one step further by defining Recently, several large ISPs have gone one step further by defining
BGP communities that allow their customers to influence the BGP communities that allow their customers to influence the
redistribution of their routes. For example, in figure 1, AS20 could redistribution of their routes. For example, in figure 1, AS20 could
configure its BGP routers to always prepend four times AS20 when they configure its BGP routers to always prepend AS20 four times when they
announce via eBGP a route received from one of AS20's customers with announce via eBGP a route received from one of AS20's customers with
a special community attribute. For this, AS20 needs to publish the a special community attribute. For this, AS20 needs to publish the
specific BGP communities that it supports and its customers need to specific BGP communities that it supports and its customers need to
configure their router appropriately. If AS20 needs to define a new configure their router appropriately. If AS20 needs to define a new
BGP community or change an existing one, it must inform all its BGP community or change an existing one, it must inform all its
customers would will then have to update the configuration of their customers may need to update the configuration of their routers.
routers. A more detailed survey of the utilization of the BGP
community attribute by ISPs may be found in [QuB02]. This survey A more detailed survey of the utilization of the BGP community
reveals the following : attribute by ISPs may be found in [COM-SUR]. This survey reveals the
- Many different AS define their own BGP community values following:
- Many different ASes define their own BGP community values
to allow their customers/peers to indicate that a to allow their customers/peers to indicate that a
particular route should not be propagated towards a specific AS, particular route should not be propagated towards a specific AS,
towards the routers attached to a specific IX, or towards AS towards the routers attached to a specific IX, or towards ASes
within a given geographical area (e.g. a European AS could want within a given geographical area (e.g. a European AS could want
to prohibit a route from being announced to US peers). to prohibit a route from being announced to US peers).
- Many AS define their own BGP community values - Many ASes define their own BGP community values
to allow their peers or customers to indicate that an to allow their peers or customers to indicate that an
announced route should be prepended when announced towards a announced route should be prepended when announced towards a
specific AS, IX or set of AS. specific AS, IX or set of ASes.
- Several AS define their own BGP community attribute to indicate - Several ASes define their own BGP community attribute to indicate
that a given route should only be redistributed towards a that a given route should only be redistributed towards a
specified AS. specified AS.
Furthermore, this survey also reveals that some AS have difficulties Furthermore, this survey also reveals that some ASes have difficulty
of providing all these facilities while still relying on their providing all these facilities while still relying on their assigned
assigned set of BGP community values. For example, some AS have set of BGP community values. For example, some ASes have chosen to
chosen to reuse several BGP community values corresponding to the reuse several BGP community values in the private AS space (i.e.
private AS space (i.e. community values 64512:00 - 65534:65535) to be community values 64512:00 - 65534:65535) to be able to define
able to define structured communities that allow their customers to structured communities that allow their customers to influence the
influence the redistribution of their routes and some of these redistribution of their routes. Some of these community values
community values appear in BGP tables on the global Internet. appear in BGP tables on the global Internet.
Although the survey shows that these BGP communities are widely used Although the survey shows that these BGP communities are widely used
today to provide such facilities, this is far from the best solution. today to provide such facilities, this is far from the best solution.
Requiring each AS to select its own values for the BGP communities Requiring each AS to select its own values for the BGP communities
and to document these values in the routing registries is not very and to document these values in the routing registries is not very
efficient because it forces the BGP routers to be configured manually efficient because it forces the BGP routers to be configured manually
based on information found in these registries or in peering based on information found in these registries, peering agreements,
agreements. or elsewhere.
In this document, we define a new type of BGP extended community. By In this document, we define a new type of BGP extended community. By
using a set BGP extended communities with a precise syntax, we using a set BGP extended communities with a precise syntax, we
support most of the current utilizations of the BGP community without support most of the current utilizations of the BGP community without
relying unnecessarily on manual configuration of the BGP routers. We relying unnecessarily on manual configuration of the BGP routers. We
believe that reducing the manual configuration of these routers would believe that reducing the manual configuration of these routers would
be very useful for the stability and the performance of the global be very useful for the stability and the performance of the global
Internet. Internet.
2 Controlled redistribution of BGP routes 2 Controlled redistribution of BGP routes
skipping to change at page 4, line 38 skipping to change at page 4, line 39
- the attached route should only be announced to the specified BGP - the attached route should only be announced to the specified BGP
speakers speakers
- the attached route should be announced with the NO_EXPORT - the attached route should be announced with the NO_EXPORT
attribute to the specified BGP speakers attribute to the specified BGP speakers
- the attached route should be prepended n times when announced to - the attached route should be prepended n times when announced to
to the specified BGP speakers to the specified BGP speakers
The redistribution policies are encoded in a special type of The redistribution policies are encoded in a special type of
extended community attribute called the redistribution community. extended community called the redistribution community. If a
If a redistribution policy applies to a long list of BGP speakers, redistribution policy applies to several of BGP speakers, then it
then it will be encoded in several redistribution communities. will be encoded in several redistribution communities.
2.1 The redistribution community 2.1 The redistribution community
The extended communities attribute is defined in [RTR01]. This The extended communities attribute is defined in [EXT-COM]. This
attribute allows a BGP router to attach a set of extended communi- attribute allows a BGP router to attach a set of extended communi-
ties to an UPDATE message. Each extended community value is encoded ties to an UPDATE message. Each extended community value is encoded
as an eight octets quantity with a two octets type field and a 6 as an eight octets quantity with a one or two octets type field and
octets value field. Several types of extended community values are a six or seven octet value field. Several types of extended commu-
defined in [RTR01]. This document proposes a new well-known nity values are defined in [EXT-COM]. This document proposes a new
extended community : the redistribution community. well-known extended community: the redistribution community.
The redistribution community is composed of a one octet type field The redistribution community is composed of a one octet type field
(regular type). It is encoded as defined in [RTR01]. The high-order (regular type). It is encoded as defined in [EXT-COM]. The high-
bit is cleared (type assigned by IANA). Since the redistribution order bit is cleared (type assigned by IANA). Since the redistribu-
community is used for signalling purposes between two AS's, the tion community is only used for signalling purposes between two
bit6 is set meaning that the extended community is non-transitive neighbor AS's, bit6 is set meaning that the extended community is
across ASes. This is important to ensure that communities used to non-transitive across ASes. This is important to ensure that com-
affect the redistribution of routes by a given AS are not unneces- munities used to affect the redistribution of routes by a given AS
sirally distributed over the entire Internet as it is often the are not unnecessarily distributed over the entire Internet as it is
case today [QuB02]. The remaining 6 lower-order bits are to be often the case today [COM-SUR]. The remaining 6 lower-order bits
defined by IANA (TBDTBD notation in figure 1). are to be defined by IANA (TBDTBD notation in figure 1).
1 octet 1 octet 6 octets 1 octet 1 octet 6 octets
+--------+--------+---------------------+ +--------+--------+---------------------+
|01TBDTBD| Action | BGP_Speakers_Filter | |01TBDTBD| Action | BGP_Speakers_Filter |
+--------+--------+---------------------+ +--------+--------+---------------------+
Figure 1 : Encoding of the redistribution community Figure 1 : Encoding of the redistribution community
The remaining 7 octets of the redistribution community indicate how The remaining 7 octets of the redistribution community indicate how
a router will advertise the received route to its peers. This a router will advertise the received route to its peers. This
requires two pieces of information: a filter to select a subset of requires two pieces of information: a filter to select a subset of
BGP speakers and an action that indicates how the attached route BGP speakers and an action that indicates how the attached route
should be redistributed to the selected peers. The high-order octet should be redistributed to the selected BGP speakers. The high-
indicates the action to be taken and the 6 remaining octets define order octet indicates the action to be taken and the 6 remaining
the filter. octets define the filter.
The Action octet is encoded as follow: The Action octet is encoded as follow:
- The high and the second order bits (Bit7 and Bit6) are reserved - The high and the second order bits (Bit7 and Bit6) are reserved
and set to zero in this document and set to zero in this document
- Bit5-3 are the Action type - Bit5-3 are the Action type
- Bit2-0 are the Action parameters - Bit2-0 are the Action parameters
Action types Action types
This document defines three types of actions (values 000b - 010b). This document defines three types of actions (values 000b - 010b).
Values 011b-111b are to be assigned by IANA. Values 011b-111b are reserved for future use and are to be assigned
by IANA by IETF consensus as defined in [RFC2434].
- 000b Prepend. This action means that the AS number of the - 000b Prepend. This action means that the AS number of the
announcing router should be prepended when announcing the attached announcing router should be prepended when announcing the attached
route to the BGP speakers covered by the redistribution policy. The route to the BGP speakers covered by the redistribution policy. The
action parameter indicates how many times the AS number should be action parameter indicates how many times the AS number should be
prepended. prepended. Using an action parameter of 000 with this type,
although legal, will not cause any additional prepending of the
route's AS PATH.
- 001b No_Export. This action means that the NO_EXPORT community - 001b No_Export. This action means that the NO_EXPORT community
should be inserted when announcing the attached route to the BGP should be inserted when announcing the attached route to the BGP
speakers covered by the redistribution policy. This action type speakers covered by the redistribution policy. This action type
does not require a parameter. The action parameter should be set to does not require a parameter. The action parameter should be set to
zero by the sender and ignored by the receiver. zero by the sender and ignored by the receiver.
- 010b Do not announce. This action means that the route should not - 010b Do not announce. This action means that the route should not
be announced to the BGP speakers covered by the redistribution pol- be announced to the BGP speakers covered by the redistribution pol-
icy. This action type does not require a parameter. The action icy. This action type does not require a parameter. The action
parameter should be set to zero by the sender and ignored by the parameter should be set to zero by the sender and ignored by the
receiver. receiver.
The BGP Speakers Filter The BGP Speakers Filter
The BGP_Speakers_Filter field is used to specify the eBGP speakers The BGP_Speakers_Filter field is used to specify the BGP speakers
that will be affected by the specified action. It is composed of a that will be affected by the specified action. It is composed of a
one octet type field and a five octets value field. one octet type field and a five octets value field.
+--------+--------------------------------------+ +--------+--------------------------------------+
| Type | BGP_Speakers_Filter Value (5 octets) | | Type | BGP_Speakers_Filter Value (5 octets) |
+--------+--------------------------------------+ +--------+--------------------------------------+
Figure 2 : Encoding of the BGP_Speakers_Filter field Figure 2 : Encoding of the BGP_Speakers_Filter field
The BGP_Speakers_Filter field is used to specify the eBGP speakers The BGP_Speakers_Filter field is used to specify the BGP speakers
that will be affected by the specified action. There are two meth- that will be affected by the specified action. There are two meth-
ods to specify the affected eBGP speakers. The first method is to ods to specify the affected BGP speakers. The first method is to
explicitly list all those speakers inside the BGP_Speakers_Filters explicitly list all those speakers inside the BGP_Speakers_Filters
field of redistribution communities. In this case, the high order field of the redistribution communities. In this case, the high
bit of the type field of the BGP_Speakers_Filter field is set to 1. order bit of the type field of the BGP_Speakers_Filter field is set
The second method is to explicitly list only the eBGP speakers that to 1. The second method is to explicitly list only the BGP speak-
will not be affected by the specified action. In this case, the ers that will not be affected by the specified action. In this
high order bit of the BGP_Speakers_Filter type field shall be set case, the high order bit of the BGP_Speakers_Filter type field
to 0. The 7 low order bits of the BGP_Speakers_Filter type field shall be set to 0. The 7 low order bits of the BGP_Speakers_Filter
are used to indicate the type of BGP speakers included in the five type field are used to indicate the type of BGP speakers included
low order octets of the BGP_Speakers_Filter field. This document in the five low order octets of the BGP_Speakers_Filter field.
defines four types of BGP_Speakers_Filters (values 0x01-0x04). This document defines four types of BGP_Speakers_Filters (values
Value 0x00 is reserved and values 0x05-0x3f are to be assigned by 0x01-0x04). Value 0x00 is reserved and values 0x05-0x3f are
IANA. Values 0x40-0x7f are vendor specific. reserved for future use and are to be assigned by IANA by IETF con-
sensus as defined in [RFC2434]. Values 0x40-0x7f are vendor spe-
cific and are assigned by IANA on a first come, first serve basis.
BGP_Speakers_Filter types BGP_Speakers_Filter types
- The BGP_Speakers_Filter value contains a two octets AS number - The BGP_Speakers_Filter value contains a two octet AS number
(type 0x01) (type 0x01)
- The BGP_Speakers_Filter value contains two two octets AS numbers - The BGP_Speakers_Filter value contains two two octet AS numbers
type 0x02) type 0x02)
- The BGP_Speakers_Filter value contains a CIDR prefix/length pair - The BGP_Speakers_Filter value contains a CIDR prefix/length pair
(type 0x03) (type 0x03)
- The BGP_Speakers_Filter value contains a four octets AS number - The BGP_Speakers_Filter value contains a four octets AS number
(type 0x04) (type 0x04)
The BGP_Speakers_Filter value shall be encoded as follows. If this The BGP_Speakers_Filter value shall be encoded as follows. If this
field contains a two octet AS number, the AS number shall be placed field contains a two octet AS number, the AS number shall be placed
in the two low order octets. The three high order octets shall be in the two low order octets. The three high order octets shall be
set to zero upon transmission and ignored upon reception. set to zero upon transmission and ignored upon reception.
+---------------------------+ +---------------------------+
| Must be Zero (3 octets)| | Must be Zero (3 octets)|
+---------------------------+ +---------------------------+
| AS number (2 octets) | | AS number (2 octets) |
+---------------------------+ +---------------------------+
Figure 3 : BGP speakers filter containing a single two octets AS number Figure 3: BGP speakers filter containing a single two octet AS number
If the BGP_Speakers_Filter value contains two two octets AS num- If the BGP_Speakers_Filter value contains two two octet AS numbers,
bers, one of the AS numbers should be placed in the two low order one of the AS numbers should be placed in the two low order octets.
octets. The other AS number should be placed in the next two higher The other AS number should be placed in the next two higher order
order octets and the last octet shall be set to zero upon transmis- octets and the last octet shall be set to zero upon transmission
sion and ignored upon reception. and ignored upon reception.
+---------------------------+ +---------------------------+
| Must be Zero (1 octet) | | Must be Zero (1 octet) |
+---------------------------+ +---------------------------+
| AS number A (2 octets) | | AS number A (2 octets) |
+---------------------------+ +---------------------------+
| AS number B (2 octets) | | AS number B (2 octets) |
+---------------------------+ +---------------------------+
Figure 4 : BGP speakers filter containing two distinct two octets AS number Figure 4: BGP speakers filter containing two distinct two octet AS number
If the BGP_Speakers_Filter value contains a four octet AS number, If the BGP_Speakers_Filter value contains a four octet AS number,
the AS number shall be placed in the four low order octets. The the AS number shall be placed in the four low order octets. The
high order octet shall be set to zero upon transmission and ignored high order octet shall be set to zero upon transmission and ignored
upon reception. upon reception.
+---------------------------+ +---------------------------+
| Must be Zero (1 octet) | | Must be Zero (1 octet) |
+---------------------------+ +---------------------------+
| AS number (4 octets) | | AS number (4 octets) |
+---------------------------+ +---------------------------+
skipping to change at page 8, line 30 skipping to change at page 8, line 34
Figure 6 : BGP speakers filter containing a CIDR prefix/length pair Figure 6 : BGP speakers filter containing a CIDR prefix/length pair
The Length field indicates the length in bits of the IP address The Length field indicates the length in bits of the IP address
prefix. A length of zero indicates a prefix that matches all IP prefix. A length of zero indicates a prefix that matches all IP
addresses. The Prefix field contains IP address prefixes followed addresses. The Prefix field contains IP address prefixes followed
by enough trailing bits with a value of zero to make the end of the by enough trailing bits with a value of zero to make the end of the
field fall on a four octets boundary. field fall on a four octets boundary.
2.2 Utilization of the redistribution communities 2.2 Utilization of the redistribution communities
A router may, depending on its policy, add any number of redistri- A router may, depending on its policy, add one or several redistri-
bution communities to a route originated by itself or received from bution communities to a route originated by itself or received from
another BGP speaker with iBGP or eBGP. When a router attaches one another BGP speaker over an iBGP or an eBGP session. In practice,
or several redistribution communities to a route, it must ensure it can be expected that the redistribution communities will often
that two of the included redistribution communities do not con- be attached by the originator of the route will as this is an
flict. This is necessary to ensure that the redistribution communi-
ties will be processed in a deterministic manner by the remote
peer. When several redistribution communities contain the same
action type and parameter, then all the BGP speakers filters of
those communities must have the same high order bit in the
BGP_Speakers_Filter type. A BGP router that receives a route con-
taining invalid redistribution communities for a given action type
and parameter should ignore all the redistribution communities con-
cerning this action type and parameter.
In practice, it can be expected that only the originator of the
route will attach the redistribution communities as this is an
attempt of the route originator to do some form of inter-domain attempt of the route originator to do some form of inter-domain
traffic engineering. In practice, it can also be expected that traffic engineering. In practice, it can also be expected that most
most utilizations of the redistribution communities will only utilizations of the redistribution communities will only require to
require to attach a small number of those communities to a given attach a small number of those communities to a given route.
route.
When a router attaches one or several redistribution communities to
a route, it must ensure that two of the included redistribution
communities do not conflict. This is necessary to ensure that the
redistribution communities will be processed in a deterministic
manner by the remote BGP peer. When several redistribution
communities contain the same action type and parameter, then all
the BGP_Speakers_filters of those communities must have the same
high order bit in the BGP_Speakers_Filter type. A BGP router that
receives a route containing invalid redistribution communities for
a given action type and parameter should ignore all the redistribu-
tion communities concerning this action type and parameter. This
ignore action must be logged.
2.3 Operations 2.3 Operations
This document defines the procedures to support the redistribution
communities that are non-transitive extended communities of type
01TBDTBD. An implementation that understands the redistribution
communities should discard and ignore upon receipt the extended
communities of the form 00TBDTBD (i.e. same type as a redistribu-
tion community but transitive).
The redistribution communities defined in this document only affect The redistribution communities defined in this document only affect
the redistribution of the associated route to eBGP peers. The the redistribution of the associated route over eBGP sessions. The
redistribution communities do not affect the redistribution of redistribution communities do not affect the redistribution of
routes via iBGP or between the sub-ASs of a confederation. routes over iBGP sessions or between the sub-ASes of a confedera-
tion.
When a router receives a route with redistribution communities, it When a router receives a route with redistribution communities, it
should apply the operations specified by these communities when should apply the operations specified by these communities when
redistributing the route to eBGP peers. Since the redistribution redistributing the route over eBGP sessions. Since the redistribu-
communities defined by this document are non-transitive, a router tion communities defined by this document are non-transitive, a
will remove the received redistribution communities when redis- router will remove the received redistribution communities when
tributing the route to eBGP peers. Of course, nothing prevents this redistributing those routes over eBGP sessions. Of course, nothing
router from adding its own redistribution communities to this route prevents this router from adding its own redistribution communities
before redistributing it. to this route before redistributing it.
A router should apply the policies defined by the redistribution A router should apply the policies defined by the redistribution
communities to the routes that is has selected for advertisement communities to the routes that is has selected for advertisement
from its Adj-RIB-OUT based on its own policy. A route that con- from its Adj-Rib-Out based on its own policy. A route that contains
tains redistribution communities should be processed as follows. redistribution communities should be processed as follows:
First, the BGP speaker should build for each action type and param- First, the BGP speaker should build for each action type and param-
eter contained in the redistribution communities attached to the eter contained in the redistribution communities attached to the
route a list of the target BGP speakers contained in the BGP_Speak- route a list of the target BGP speakers contained in the BGP_Speak-
ers_filters for this action type. In the remainder of this sec- ers_filters for this action type. In the remainder of this sec-
tion, we will use the wordings "a BGP speaker P is affected by tion, we will use the wordings "an eBGP session is affected by
action type x with parameter" to indicate that either of the fol- action type x" to indicate that either of the following is true
lowing is true : when the BGP_Speakers_Filters contain AS numbers:
- P appears inside one of the BGP_Speakers_Filter of the redistri- - the AS number of the remote BGP peer appears inside one of the
bution communities with action x and the high order bit of the BGP_Speakers_Filter of the redistribution communities with action x
BGP_Speakers_Filter type is set to one and the high order bit of the BGP_Speakers_Filter type is set to
one
- P does not appear inside any of the BGP_Speakers_Filter of the - the AS number of the remote BGP peer does not appear inside any
redistribution communities with action x and the high order bit of of the BGP_Speakers_Filter of the redistribution communities with
the BGP_Speakers_Filter type is set to zero action x and the high order bit of the BGP_Speakers_Filter type is
set to zero
Then, when a route is about to be redistributed to peer P, the When the BGP_Speakers_Filter contains a CIDR prefix/length, we will
router first checks if this peer is affected by action type "Do not use the wordings "an eBGP session is affected by action type x" to
announce". If this is the case, the route is not announced to this indicate that either of the following is true:
peer. Otherwise, the router checks the other action types as fol-
lows.
- If peer P is affected by action type "No export" then the well- - the IP address of at least one of the endpoints of the eBGP ses-
known community NO_EXPORT is attached to the route. sion belongs to the CIDR prefix specified inside one of the
BGP_Speakers_Filter of the redistribution communities with action x
and the high order bit of the BGP_Speakers_Filter type is set to
one
- If peer P is affected by one or more actions of type "Prepend", - the IP addresses of the local and the remote endpoints of the
then the AS-Path of the route shall be prepended n times where n is eBGP session do not belong to the CIDR prefix specified inside one
the smallest parameter of the matched "Prepend" actions. of the BGP_Speakers_Filter of the redistribution communities with
action x and the high order bit of the BGP_Speakers_Filter type is
set to zero
Then the route is announced to peer P. Then, when a route is about to be redistributed over an eBGP ses-
sion, the router first checks if this session is affected by action
type "Do not announce". If this is the case, the route is not
announced over this eBGP session. Otherwise, the router checks the
other action types as follows.
- If the eBGP session is affected by action type "No export" then
the well-known community NO_EXPORT is attached to the route.
- If the eBGP session is affected by one or more actions of type
"Prepend", then the AS-Path of the route shall be prepended n times
(with the AS number of the router redistributing the route) where n
is the smallest parameter of the matched "Prepend" actions.
Otherwise the route is announced over the eBGP session.
2.4 Filtering and precedence
In order to allow operators to control the implementation of their
policies, a BGP implementation that supports the redistribution
communities should allow the operator to determine, on a per ses-
sion basis whether redistribution communities are permitted or
denied on this session. For example, an AS could elect to receive
redistribution communities from its customers, but not on a shared-
cost peering session. A BGP implementation may provide additional
details in the filtering of the redistribution communities, but
this is implementation dependent and goes beyond this specifica-
tion.
A BGP implementation that supports both the normal (extended) com-
munities and the redistribution communities should allow the opera-
tor to adjust the order in which these types of communities are
processed. The default precedence should be to first process the
redistribution communities before processing the other manually
defined (extended) communities.
3 IANA considerations 3 IANA considerations
This document requests the attribution of a new BGP extended commu- This document requests the attribution of a new BGP extended commu-
nities type field from IANA. In addition, this document proposes nities type [EXT-COM] field from IANA.
that IANA maintains the action types and the BGP speakers filter
types values defined in section 2. The redistribution community contains two fields that are to be
maintained by IANA. The first field is the Action type that is part
of the Action octet defined in section 2.1 shall be maintained by
IANA. This document defines the utilization of action types 000b -
010b ; action types 011b - 111b are reserved for future use and are
to be assigned by IANA by IETF consensus as defined in [RFC2434].
The second field are the seven low order bits of the Type octet of
the BGP_Speakers_Filter defined in section 2.1. This document
defines four types of BGP_Speakers_Filters (values 0x01-0x04).
Value 0x00 is reserved and values 0x05-0x3f are reserved for future
use and are to be assigned by IANA by IETF consensus as defined in
[RFC2434]. Values 0x40-0x7f are vendor specific and are assigned
by IANA on a first come, first serve basis.
4 Security considerations 4 Security considerations
This extension to BGP does not change the underlying security This extension to BGP does not change the underlying security
issues of the extended community attribute. issues of the extended community attribute.
5 Conclusion 5 Conclusion
This document has proposed a new type of extended communinities This document has proposed a new type of extended communities
called the redistribution communities. These redistribution commu- called the redistribution communities. These redistribution commu-
nities can be used by a BGP router to influence the redistribution nities can be used by a BGP router to influence the redistribution
of some of its routes by its peers. Three types of redistribution of some of its routes by its peers. Three types of redistribution
communities have been proposed. The first type may be used to communities have been proposed. The first type may be used to
indicate that a specific route should not be announced to the spec- indicate that a specific route should not be announced over the
ified set of eBGP speakers. The second type may be used to indi- specified set of eBGP sessions. The second type may be used to
cate that the attached route should only be announced with the indicate that the attached route should only be announced with the
NO_EXPORT community to the specified set of eBGP speakers and the NO_EXPORT community over the specified set of eBGP sessions and the
third type may be used to indicate that the attached route should third type may be used to indicate that the attached route should
be prepended n times when announced to the specified set of eBGP be prepended n times when announced over the specified set of eBGP
speakers. sessions.
Acknowledgements Acknowledgements
This work was partially funded by the European Commission, within This work was partially funded by the European Commission, within
the ATRIUM IST project. We would like to thank Bart Peirens and the ATRIUM IST project. We would like to thank Bart Peirens,
Alvaro Retana for their comments. Alvaro Retana and Andrew Partan for their comments.
References References
[Hal97] B. Halabi. Internet Routing Architectures. Cisco Press, [Halabi97] B. Halabi. Internet Routing Architectures. Cisco Press,
1997. 1997.
[Hus01] G. Huston. AS1221 BGP table statistics. available from [Huston01] G. Huston. AS1221 BGP table statistics. available from
http://www.telstra.net/ops/bgp/, 2001. http://www.telstra.net/ops/bgp/, 2001.
[QuB02] B. Quoitin, O. Bonaventure, A survey of the utilization [COM-SUR] B. Quoitin, O. Bonaventure, A survey of the utilization
of the BGP community attribute, Internet draft, draft-quoitin-bgp- of the BGP community attribute, Internet draft, draft-quoitin-bgp-
comm-survey-00.txt, work in progress, February 2002 comm-survey-00.txt, work in progress, February 2002
[Quo02] B. Quoitin, An implementation of the BGP redistribution [Quoitin02] B. Quoitin, An implementation of the BGP redistribution
communities in zebra, Technical report Infonet-TR-2002-03, February communities in zebra, Technical report Infonet-TR-2002-03, February
2002, http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-03.html 2002, http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-03.html
[RTR01] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended commu- [EXT-COM] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended com-
nities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi- munities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi-
ties-01.txt, work in progress, August 2001. ties-05.txt, work in progress, May 2002.
[RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC2434, October 1998
Authors' Addresses Authors' Addresses
Olivier Bonaventure, Bruno Quoitin Olivier Bonaventure, Bruno Quoitin
Infonet group (FUNDP) Infonet group (FUNDP)
Rue Grandgagnage 21, B-5000 Namur, Belgium Rue Grandgagnage 21, B-5000 Namur, Belgium
Email: Olivier.Bonaventure@info.fundp.ac.be, Bruno.Quoitin@info.fundp.ac.be Email: Olivier.Bonaventure@info.fundp.ac.be, Bruno.Quoitin@info.fundp.ac.be
URL : http://www.infonet.fundp.ac.be URL : http://www.infonet.fundp.ac.be
Stefaan De Cnodder Stefaan De Cnodder
skipping to change at page 12, line 5 skipping to change at page 13, line 27
Email: stefaan.de_cnodder@alcatel.be Email: stefaan.de_cnodder@alcatel.be
Jeffrey Haas Jeffrey Haas
NextHop Technologies NextHop Technologies
Email: jhaas@nexthop.com Email: jhaas@nexthop.com
Russ White Russ White
Cisco Systems Cisco Systems
Email: ruwhite@cisco.com Email: ruwhite@cisco.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this doc-
ument itself may not be modified in any way, such as by removing the
copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of develop-
ing Internet standards in which case the procedures for copyrights
defined in the Internet Standards process must be followed, or as
required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER-
CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Appendix 1 Simple example Appendix 1 Simple example
The redistribution communities defined in this document can be The redistribution communities defined in this document can be
used in two different ways. A first possible solution would be used in two different ways. A first possible solution would be
to rely on the existing support for the extended communities in to rely on the existing support for the extended communities in
BGP implementations and to manually configure the redistribution BGP implementations and to manually configure the redistribution
communities defined in this document. This solution could be communities defined in this document. This solution could be
used today by ISPs to support the redistribution communities (or a subset used today by ISPs to support the redistribution communities (or a subset
of those communities) defined of those communities) defined
in this document instead on defining special community values in in this document instead on defining special community values in
skipping to change at page 13, line 37 skipping to change at page 16, line 37
! !
Figure A : Sample configuration Figure A : Sample configuration
For a router with a small number of peers, such a manual configura- For a router with a small number of peers, such a manual configura-
tion of the redistribution communities is possible. However, if the tion of the redistribution communities is possible. However, if the
routers has many peers, the required configuration file may become routers has many peers, the required configuration file may become
very large, especially if one wants to fully support all the redis- very large, especially if one wants to fully support all the redis-
tribution communities defined in this document. In this case, a bet- tribution communities defined in this document. In this case, a bet-
ter solution is to rely on a direct support for the redistribution ter solution is to rely on a direct support for the redistribution
communities inside the BGP implementation itself as discussed in communities inside the BGP implementation itself as discussed in
[Quo02]. With a BGP implementation supporting directly the redistri- [Quoitin02]. With a BGP implementation supporting directly the redis-
bution communities, a few lines of configuration will be sufficient tribution communities, a few lines of configuration will be suffi-
to enable or disable some or all of the redistribution communites for cient to enable or disable some or all of the redistribution communi-
each peer. ties for each peer.
 End of changes. 57 change blocks. 
165 lines changed or deleted 257 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/