draft-ietf-ptomaine-bgp-redistribution-01.txt   draft-ietf-ptomaine-bgp-redistribution-02.txt 
Internet Engineering Task Force Olivier Bonaventure Internet Engineering Task Force Olivier Bonaventure
INTERNET DRAFT FUNDP INTERNET DRAFT UCL
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
August, 2002 February, 2003
Expires February, 2002 Expires October, 2003
Controlling the redistribution of BGP routes Controlling the redistribution of BGP routes
<draft-ietf-ptomaine-bgp-redistribution-01.txt> <draft-ietf-ptomaine-bgp-redistribution-02.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 5, line 4 skipping to change at page 5, line 4
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 called the redistribution community. If a extended community called the redistribution community. If a
redistribution policy applies to several of BGP speakers, then it redistribution policy applies to several of BGP speakers, 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 [EXT-COM]. 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 one or two octets type field and as an eight octets quantity with a one or two octets type field and
a six or seven octet value field. Several types of extended commu- a six or seven octet value field. Several types of extended commu­
nity values are defined in [EXT-COM]. This document proposes a new nity values are defined in [EXT-COM]. This document proposes a new
well-known 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 [EXT-COM]. The high- (regular type). It is encoded as defined in [EXT-COM]. The high-
order bit is cleared (type assigned by IANA). Since the redistribu- order bit is cleared (type assigned by IANA). Since the redistribu­
tion community is only used for signalling purposes between two tion community is only used for signalling purposes between two
neighbor AS's, bit6 is set meaning that the extended community is neighbor AS's, bit6 is set meaning that the extended community is
non-transitive across ASes. This is important to ensure that com- non-transitive across ASes. This is important to ensure that com­
munities used to affect the redistribution of routes by a given AS munities used to affect the redistribution of routes by a given AS
are not unnecessarily distributed over the entire Internet as it is are not unnecessarily distributed over the entire Internet as it is
often the case today [COM-SUR]. The remaining 6 lower-order bits often the case today [COM-SUR]. The remaining 6 lower-order bits
are to be 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
skipping to change at page 6, line 21 skipping to change at page 6, line 21
although legal, will not cause any additional prepending of the although legal, will not cause any additional prepending of the
route's AS PATH. 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 BGP 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 BGP 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 BGP 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 the redistribution communities. In this case, the high field of the redistribution communities. In this case, the high
order bit of the type field of the BGP_Speakers_Filter field is set order bit of the type field of the BGP_Speakers_Filter field is set
to 1. The second method is to explicitly list only the BGP speak- to 1. The second method is to explicitly list only the BGP speak­
ers that will not be affected by the specified action. In this ers that will not be affected by the specified action. In this
case, the high order bit of the BGP_Speakers_Filter type field case, the high order bit of the BGP_Speakers_Filter type field
shall be set to 0. The 7 low order bits of the BGP_Speakers_Filter shall be set to 0. The 7 low order bits of the BGP_Speakers_Filter
type field are used to indicate the type of BGP speakers included type field are used to indicate the type of BGP speakers included
in the five low order octets of the BGP_Speakers_Filter field. in the five low order octets of the BGP_Speakers_Filter field.
This document defines four types of BGP_Speakers_Filters (values This document defines four types of BGP_Speakers_Filters (values
0x01-0x04). Value 0x00 is reserved and values 0x05-0x3f are 0x01-0x04). Value 0x00 is reserved and values 0x05-0x3f are
reserved for future use and are to be assigned by IANA by IETF con- 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- sensus as defined in [RFC2434]. Values 0x40-0x7f are vendor spe­
cific and are assigned by IANA on a first come, first serve basis. 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 octet 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 octet AS numbers - The BGP_Speakers_Filter value contains two two octet AS numbers
type 0x02) type 0x02)
skipping to change at page 8, line 34 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 one or several 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 over an iBGP or an eBGP session. In practice, another BGP speaker over an iBGP or an eBGP session. In practice,
it can be expected that the redistribution communities will often it can be expected that the redistribution communities will often
be attached by the originator of the route will as this is an be attached by the originator of the route will 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 most traffic engineering. In practice, it can also be expected that most
utilizations of the redistribution communities will only require to utilizations of the redistribution communities will only require to
attach a small number of those communities to a given route. attach a small number of those communities to a given route.
When a router attaches one or several redistribution communities to When a router attaches one or several redistribution communities to
a route, it must ensure that two of the included redistribution a route, it must ensure that two of the included redistribution
communities do not conflict. This is necessary to ensure that the communities do not conflict. This is necessary to ensure that the
redistribution communities will be processed in a deterministic redistribution communities will be processed in a deterministic
manner by the remote BGP peer. When several redistribution manner by the remote BGP peer. When several redistribution
communities contain the same action type and parameter, then all communities contain the same action type and parameter, then all
the BGP_Speakers_filters of those communities must have the same the BGP_Speakers_filters of those communities must have the same
high order bit in the BGP_Speakers_Filter type. A BGP router that high order bit in the BGP_Speakers_Filter type. A BGP router that
receives a route containing invalid redistribution communities for receives a route containing invalid redistribution communities for
a given action type and parameter should ignore all the redistribu- a given action type and parameter should ignore all the redistribu­
tion communities concerning this action type and parameter. This tion communities concerning this action type and parameter. This
ignore action must be logged. ignore action must be logged.
2.3 Operations 2.3 Operations
This document defines the procedures to support the redistribution This document defines the procedures to support the redistribution
communities that are non-transitive extended communities of type communities that are non-transitive extended communities of type
01TBDTBD. An implementation that understands the redistribution 01TBDTBD. An implementation that understands the redistribution
communities should discard and ignore upon receipt the extended communities should discard and ignore upon receipt the extended
communities of the form 00TBDTBD (i.e. same type as a redistribu- communities of the form 00TBDTBD (i.e. same type as a redistribu­
tion community but transitive). 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 over eBGP sessions. 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 over iBGP sessions or between the sub-ASes of a confedera- routes over iBGP sessions or between the sub-ASes of a confedera­
tion. 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 over eBGP sessions. Since the redistribu- redistributing the route over eBGP sessions. Since the redistribu­
tion communities defined by this document are non-transitive, a tion communities defined by this document are non-transitive, a
router will remove the received redistribution communities when router will remove the received redistribution communities when
redistributing those routes over eBGP sessions. Of course, nothing redistributing those routes over eBGP sessions. Of course, nothing
prevents this router from adding its own redistribution communities prevents this router from adding its own redistribution communities
to this route 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 contains from its Adj-Rib-Out based on its own policy. A route that contains
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 "an eBGP session is affected by tion, we will use the wordings "an eBGP session is affected by
action type x" to indicate that either of the following is true action type x" to indicate that either of the following is true
when the BGP_Speakers_Filters contain AS numbers: when the BGP_Speakers_Filters contain AS numbers:
- the AS number of the remote BGP peer appears inside one of the - the AS number of the remote BGP peer appears inside one of the
BGP_Speakers_Filter of the redistribution communities with action x BGP_Speakers_Filter of the redistribution communities with action x
and the high order bit of the BGP_Speakers_Filter type is set to and the high order bit of the BGP_Speakers_Filter type is set to
one one
- the AS number of the remote BGP peer does not appear inside any - the AS number of the remote BGP peer does not appear inside any
of the BGP_Speakers_Filter of the redistribution communities with of the BGP_Speakers_Filter of the redistribution communities with
action x and the high order bit of the BGP_Speakers_Filter type is action x and the high order bit of the BGP_Speakers_Filter type is
set to zero set to zero
When the BGP_Speakers_Filter contains a CIDR prefix/length, we will When the BGP_Speakers_Filter contains a CIDR prefix/length, we will
use the wordings "an eBGP session is affected by action type x" to use the wordings "an eBGP session is affected by action type x" to
indicate that either of the following is true: indicate that either of the following is true:
- the IP address of at least one of the endpoints of the eBGP ses- - the IP address of at least one of the endpoints of the eBGP ses­
sion belongs to the CIDR prefix specified inside one of the sion belongs to the CIDR prefix specified inside one of the
BGP_Speakers_Filter of the redistribution communities with action x BGP_Speakers_Filter of the redistribution communities with action x
and the high order bit of the BGP_Speakers_Filter type is set to and the high order bit of the BGP_Speakers_Filter type is set to
one one
- the IP addresses of the local and the remote endpoints of the - the IP addresses of the local and the remote endpoints of the
eBGP session do not belong to the CIDR prefix specified inside one eBGP session do not belong to the CIDR prefix specified inside one
of the BGP_Speakers_Filter of the redistribution communities with of the BGP_Speakers_Filter of the redistribution communities with
action x and the high order bit of the BGP_Speakers_Filter type is action x and the high order bit of the BGP_Speakers_Filter type is
set to zero set to zero
Then, when a route is about to be redistributed over an eBGP ses- 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 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 type "Do not announce". If this is the case, the route is not
announced over this eBGP session. Otherwise, the router checks the announced over this eBGP session. Otherwise, the router checks the
other action types as follows. other action types as follows.
- If the eBGP session is affected by action type "No export" then - If the eBGP session is affected by action type "No export" then
the well-known community NO_EXPORT is attached to the route. the well-known community NO_EXPORT is attached to the route.
- If the eBGP session is affected by one or more actions of type - 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 "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 (with the AS number of the router redistributing the route) where n
is the smallest parameter of the matched "Prepend" actions. is the smallest parameter of the matched "Prepend" actions.
Otherwise the route is announced over the eBGP session. Otherwise the route is announced over the eBGP session.
2.4 Filtering and precedence 2.4 Filtering and precedence
In order to allow operators to control the implementation of their In order to allow operators to control the implementation of their
policies, a BGP implementation that supports the redistribution policies, a BGP implementation that supports the redistribution
communities should allow the operator to determine, on a per ses- communities should allow the operator to determine, on a per ses­
sion basis whether redistribution communities are permitted or sion basis whether redistribution communities are permitted or
denied on this session. For example, an AS could elect to receive denied on this session. For example, an AS could elect to receive
redistribution communities from its customers, but not on a shared- redistribution communities from its customers, but not on a shared-
cost peering session. A BGP implementation may provide additional cost peering session. A BGP implementation may provide additional
details in the filtering of the redistribution communities, but details in the filtering of the redistribution communities, but
this is implementation dependent and goes beyond this specifica- this is implementation dependent and goes beyond this specifica­
tion. tion.
A BGP implementation that supports both the normal (extended) com- A BGP implementation that supports both the normal (extended) com­
munities and the redistribution communities should allow the opera- munities and the redistribution communities should allow the opera­
tor to adjust the order in which these types of communities are tor to adjust the order in which these types of communities are
processed. The default precedence should be to first process the processed. The default precedence should be to first process the
redistribution communities before processing the other manually redistribution communities before processing the other manually
defined (extended) communities. 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 [EXT-COM] field from IANA. nities type [EXT-COM] field from IANA.
The redistribution community contains two fields that are to be The redistribution community contains two fields that are to be
maintained by IANA. The first field is the Action type that is part 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 of the Action octet defined in section 2.1 shall be maintained by
IANA. This document defines the utilization of action types 000b - IANA. This document defines the utilization of action types 000b -
010b ; action types 011b - 111b are reserved for future use and are 010b ; action types 011b - 111b are reserved for future use and are
to be assigned by IANA by IETF consensus as defined in [RFC2434]. 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 second field are the seven low order bits of the Type octet of
the BGP_Speakers_Filter defined in section 2.1. This document the BGP_Speakers_Filter defined in section 2.1. This document
skipping to change at page 12, line 4 skipping to change at page 12, line 4
by IANA on a first come, first serve basis. 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 communities 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 over the indicate that a specific route should not be announced over the
specified set of eBGP sessions. The second type may be used to specified set of eBGP sessions. The second type may be used to
indicate that the attached route should only be announced with the indicate that the attached route should only be announced with the
NO_EXPORT community over the specified set of eBGP sessions 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 over the specified set of eBGP be prepended n times when announced over the specified set of eBGP
sessions. sessions.
skipping to change at page 12, line 38 skipping to change at page 12, line 38
http://www.telstra.net/ops/bgp/, 2001. http://www.telstra.net/ops/bgp/, 2001.
[COM-SUR] 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
[Quoitin02] 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
[EXT-COM] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended com- [EXT-COM] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended com­
munities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi- munities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi­
ties-05.txt, work in progress, May 2002. ties-05.txt, work in progress, May 2002.
[RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA
Considerations Section in RFCs, RFC2434, October 1998 Considerations Section in RFCs, RFC2434, October 1998
Authors' Addresses Authors' Addresses
Olivier Bonaventure, Bruno Quoitin Olivier Bonaventure,
Dept. Computing Science and Engineering
Universite catholique de Louvain (UCL)
Place Sainte-Barbe, 2, B-1348 Louvain-la-Neuve (Belgium)
Email: Olivier.Bonaventure@info.fundp.ac.be
URL : http://www.info.ucl.ac.be/people/OBO
Bruno Quoitin
Infonet group (FUNDP) Infonet group (FUNDP)
Rue Grandgagnage 21, B-5000 Namur, Belgium Rue Grandgagnage 21
Email: Olivier.Bonaventure@info.fundp.ac.be, Bruno.Quoitin@info.fundp.ac.be B-5000 Namur
Email: 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
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
B-2018 Antwerp, Belgium B-2018 Antwerp, Belgium
Email: stefaan.de_cnodder@alcatel.be Email: stefaan.de_cnodder@alcatel.be
Jeffrey Haas Jeffrey Haas
NextHop Technologies NextHop Technologies
skipping to change at page 16, line 30 skipping to change at page 16, line 30
! action "do not announce" ! action "do not announce"
! filter "include AS2" ! filter "include AS2"
! !
ip extcommunity-list 5 permit 0x4410810000000002 ip extcommunity-list 5 permit 0x4410810000000002
! !
route-map do_not_announce_as2 deny 10 route-map do_not_announce_as2 deny 10
match extcommunity 5 match extcommunity 5
! !
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
[Quoitin02]. With a BGP implementation supporting directly the redis- [Quoitin02]. With a BGP implementation supporting directly the redis­
tribution communities, a few lines of configuration will be suffi- tribution communities, a few lines of configuration will be suffi­
cient to enable or disable some or all of the redistribution communi- cient to enable or disable some or all of the redistribution communi­
ties for each peer. ties for each peer.
 End of changes. 31 change blocks. 
40 lines changed or deleted 48 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/