idnits 2.17.1 draft-ietf-grow-bgp-redistribution-00.txt: -(184): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(193): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(246): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(263): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(268): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(276): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(350): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(369): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(390): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(402): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(404): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(424): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(464): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(465): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(473): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(498): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(532): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(533): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(673): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(676): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(678): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 33 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 18 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 86 has weird spacing: '...routers is to...' == Line 88 has weird spacing: '...or some annou...' == Line 100 has weird spacing: '...stomers to in...' == Line 103 has weird spacing: '...eceived from ...' == Line 503 has weird spacing: '...ied set of eB...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Halabi97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Huston01' -- Possible downref: Normative reference to a draft: ref. 'COM-SUR' -- Possible downref: Non-RFC (?) normative reference: ref. 'Quoitin02' -- No information found for draft-ietf-idr-bgp-ext-communi - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'EXT-COM' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Olivier Bonaventure 3 INTERNET DRAFT UCL 4 Stefaan De Cnodder 5 Alcatel 6 Jeffrey Haas 7 NextHop 8 Bruno Quoitin 9 FUNDP 10 Russ White 11 Cisco 12 April, 2003 13 Expires October, 2003 15 Controlling the redistribution of BGP routes 16 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Abstract 41 This document proposes the redistribution extended community. This 42 new extended community allows a router to influence how a specific 43 route should be redistributed towards a specified set of eBGP 44 speakers. Several types of redistribution communities are proposed. 45 The first type may be used to indicate that a specific route should 46 not be announced over a specified set of eBGP sessions. The second 47 type may be used to indicate that the attached route should only be 48 announced with the NO_EXPORT community over the specified set of eBGP 49 sessions and the third type may be used to indicate that the attached 50 route should be prepended n times when announced over a specified set 51 of eBGP sessions. 53 1 Introduction 55 In today's commercial Internet, many ISPs need to have some control 56 on their inter-domain traffic. In the outgoing direction, this 57 control can be obtained by configuring the BGP routers of the ISP to 58 favor some routes over others by using the LOCAL-PREF attribute. 59 However, due to the asymetry of Internet traffic, most ISPs also need 60 to control their incoming traffic. 62 +---------------+ 63 | | 64 | AS22 | 65 | | 66 +---------------+ 67 || 68 +---------------+ +---------------+ 69 | 13.0.0.0/8 | | AS21 | 70 | 12.0.0.0/8 |===============| | 71 | AS20 | +---------------+ 72 +---------------+ 73 || 74 +---------------+ 75 | | 76 | AS10 | 77 | | 78 +---------------+ 79 Figure 1: Simple inter-domain topology 81 In the incoming direction, the only way to influence the traffic flow 82 is to control the redistribution of its routes. Several methods exist 83 and are used in practice [Halabi97,COM-SUR]. In this case, the ISP 84 needs to influence the redistribution and the selection of its own 85 routes by remote ISPs. Since the default configuration of many BGP 86 routers is to select the route with the smallest AS path length, a 87 common technique is to artificially increase the length of the AS 88 path for some announced routes. For example, in figure 1, if AS20 89 wanted to indicate that it prefers to receive its traffic towards 90 subnet 13.0.0.0/8 through its link with AS22, then it would announce 91 this prefix as usual on this link to AS22 and announce a prefix with 92 the AS20:AS20:AS20:AS20 path to AS21 and AS10. If AS10 and AS21 use 93 the AS path length to select the best BGP route, they will prefer the 94 shorter route received by AS22. This requires manual configuration of 95 the BGP routers, but path prepending is very frequently used today on 96 the Internet [Huston01]. In some cases, the configuration burden can 97 be reduced by using the BGP communities attribute. 99 Recently, several large ISPs have gone one step further by defining 100 BGP communities that allow their customers to influence the 101 redistribution of their routes. For example, in figure 1, AS20 could 102 configure its BGP routers to always prepend AS20 four times when they 103 announce via eBGP a route received from one of AS20's customers with 104 a special community attribute. For this, AS20 needs to publish the 105 specific BGP communities that it supports and its customers need to 106 configure their router appropriately. If AS20 needs to define a new 107 BGP community or change an existing one, it must inform all its 108 customers may need to update the configuration of their routers. 110 A more detailed survey of the utilization of the BGP community 111 attribute by ISPs may be found in [COM-SUR]. This survey reveals the 112 following: 113 - Many different ASes define their own BGP community values 114 to allow their customers/peers to indicate that a 115 particular route should not be propagated towards a specific AS, 116 towards the routers attached to a specific IX, or towards ASes 117 within a given geographical area (e.g. a European AS could want 118 to prohibit a route from being announced to US peers). 119 - Many ASes define their own BGP community values 120 to allow their peers or customers to indicate that an 121 announced route should be prepended when announced towards a 122 specific AS, IX or set of ASes. 123 - Several ASes define their own BGP community attribute to indicate 124 that a given route should only be redistributed towards a 125 specified AS. 127 Furthermore, this survey also reveals that some ASes have difficulty 128 providing all these facilities while still relying on their assigned 129 set of BGP community values. For example, some ASes have chosen to 130 reuse several BGP community values in the private AS space (i.e. 131 community values 64512:00 - 65534:65535) to be able to define 132 structured communities that allow their customers to influence the 133 redistribution of their routes. Some of these community values 134 appear in BGP tables on the global Internet. 136 Although the survey shows that these BGP communities are widely used 137 today to provide such facilities, this is far from the best solution. 138 Requiring each AS to select its own values for the BGP communities 139 and to document these values in the routing registries is not very 140 efficient because it forces the BGP routers to be configured manually 141 based on information found in these registries, peering agreements, 142 or elsewhere. 144 In this document, we define a new type of BGP extended community. By 145 using a set BGP extended communities with a precise syntax, we 146 support most of the current utilizations of the BGP community without 147 relying unnecessarily on manual configuration of the BGP routers. We 148 believe that reducing the manual configuration of these routers would 149 be very useful for the stability and the performance of the global 150 Internet. 152 2 Controlled redistribution of BGP routes 154 This document defines a method to allow a BGP speaker to influence 155 how its peers will redistribute its own routes. For this, the BGP 156 speaker may define for each announced route a redistribution policy 157 that controls how this route will be redistributed. This is done by 158 defining a set of allowed or requested operations and a list of BGP 159 speakers. The list of BGP speakers can be specified by listing either 160 the BGP speakers that are covered by the redistribution policy or 161 those that are not covered by this policy. The current version of 162 this document supports the following operations: 164 - the attached route should not be announced to the specified BGP 165 speakers 167 - the attached route should only be announced to the specified BGP 168 speakers 170 - the attached route should be announced with the NO_EXPORT 171 attribute to the specified BGP speakers 173 - the attached route should be prepended n times when announced to 174 to the specified BGP speakers 176 The redistribution policies are encoded in a special type of 177 extended community called the redistribution community. If a 178 redistribution policy applies to several of BGP speakers, then it 179 will be encoded in several redistribution communities. 181 2.1 The redistribution community 183 The extended communities attribute is defined in [EXT-COM]. This 184 attribute allows a BGP router to attach a set of extended communi� 185 ties to an UPDATE message. Each extended community value is encoded 186 as an eight octets quantity with a one or two octets type field and 187 a six or seven octet value field. Several types of extended commu� 188 nity values are defined in [EXT-COM]. This document proposes a new 189 well-known extended community: the redistribution community. 191 The redistribution community is composed of a one octet type field 192 (regular type). It is encoded as defined in [EXT-COM]. The high- 193 order bit is cleared (type assigned by IANA). Since the redistribu� 194 tion community is only used for signalling purposes between two 195 neighbor AS's, bit6 is set meaning that the extended community is 196 non-transitive across ASes. This is important to ensure that com� 197 munities used to affect the redistribution of routes by a given AS 198 are not unnecessarily distributed over the entire Internet as it is 199 often the case today [COM-SUR]. The remaining 6 lower-order bits 200 are to be defined by IANA (TBDTBD notation in figure 1). 202 1 octet 1 octet 6 octets 203 +--------+--------+---------------------+ 204 |01TBDTBD| Action | BGP_Speakers_Filter | 205 +--------+--------+---------------------+ 206 Figure 1: Encoding of the redistribution community 208 The remaining 7 octets of the redistribution community indicate how 209 a router will advertise the received route to its peers. This 210 requires two pieces of information: a filter to select a subset of 211 BGP speakers and an action that indicates how the attached route 212 should be redistributed to the selected BGP speakers. The high- 213 order octet indicates the action to be taken and the 6 remaining 214 octets define the filter. 216 The Action octet is encoded as follow: 218 - The high and the second order bits (Bit7 and Bit6) are reserved 219 and set to zero in this document 221 - Bit5-3 are the Action type 223 - Bit2-0 are the Action parameters 225 Action types 227 This document defines three types of actions (values 000b - 010b). 228 Values 011b-111b are reserved for future use and are to be assigned 229 by IANA by IETF consensus as defined in [RFC2434]. 231 - 000b Prepend. This action means that the AS number of the 232 announcing router should be prepended when announcing the attached 233 route to the BGP speakers covered by the redistribution policy. The 234 action parameter indicates how many times the AS number should be 235 prepended. Using an action parameter of 000 with this type, 236 although legal, will not cause any additional prepending of the 237 route's AS PATH. 239 - 001b No_Export. This action means that the NO_EXPORT community 240 should be inserted when announcing the attached route to the BGP 241 speakers covered by the redistribution policy. This action type 242 does not require a parameter. The action parameter should be set to 243 zero by the sender and ignored by the receiver. 245 - 010b Do not announce. This action means that the route should not 246 be announced to the BGP speakers covered by the redistribution pol� 247 icy. This action type does not require a parameter. The action 248 parameter should be set to zero by the sender and ignored by the 249 receiver. 251 The BGP Speakers Filter 253 The BGP_Speakers_Filter field is used to specify the BGP speakers 254 that will be affected by the specified action. It is composed of a 255 one octet type field and a five octets value field. 257 +--------+--------------------------------------+ 258 | Type | BGP_Speakers_Filter Value (5 octets) | 259 +--------+--------------------------------------+ 260 Figure 2: Encoding of the BGP_Speakers_Filter field 262 The BGP_Speakers_Filter field is used to specify the BGP speakers 263 that will be affected by the specified action. There are two meth� 264 ods to specify the affected BGP speakers. The first method is to 265 explicitly list all those speakers inside the BGP_Speakers_Filters 266 field of the redistribution communities. In this case, the high 267 order bit of the type field of the BGP_Speakers_Filter field is set 268 to 1. The second method is to explicitly list only the BGP speak� 269 ers that will not be affected by the specified action. In this 270 case, the high order bit of the BGP_Speakers_Filter type field 271 shall be set to 0. The 7 low order bits of the BGP_Speakers_Filter 272 type field are used to indicate the type of BGP speakers included 273 in the five low order octets of the BGP_Speakers_Filter field. 274 This document defines four types of BGP_Speakers_Filters (values 275 0x01-0x04). Value 0x00 is reserved and values 0x05-0x3f are 276 reserved for future use and are to be assigned by IANA by IETF con� 277 sensus as defined in [RFC2434]. Values 0x40-0x7f are vendor spe� 278 cific and are assigned by IANA on a first come, first serve basis. 280 BGP_Speakers_Filter types 282 - The BGP_Speakers_Filter value contains a two octet AS number 283 (type 0x01) 285 - The BGP_Speakers_Filter value contains two two octet AS numbers 286 type 0x02) 288 - The BGP_Speakers_Filter value contains a CIDR prefix/length pair 289 (type 0x03) 291 - The BGP_Speakers_Filter value contains a four octets AS number 292 (type 0x04) 294 The BGP_Speakers_Filter value shall be encoded as follows. If this 295 field contains a two octet AS number, the AS number shall be placed 296 in the two low order octets. The three high order octets shall be 297 set to zero upon transmission and ignored upon reception. 299 +---------------------------+ 300 | Must be Zero (3 octets) | 301 +---------------------------+ 302 | AS number (2 octets) | 303 +---------------------------+ 304 Figure 3: BGP speakers filter containing a single two octet AS number 306 If the BGP_Speakers_Filter value contains two two octet AS numbers, 307 one of the AS numbers should be placed in the two low order octets. 308 The other AS number should be placed in the next two higher order 309 octets and the last octet shall be set to zero upon transmission 310 and ignored upon reception. 312 +---------------------------+ 313 | Must be Zero (1 octet) | 314 +---------------------------+ 315 | AS number A (2 octets) | 316 +---------------------------+ 317 | AS number B (2 octets) | 318 +---------------------------+ 319 Figure 4: BGP speakers filter containing two distinct two octet AS number 320 If the BGP_Speakers_Filter value contains a four octet AS number, 321 the AS number shall be placed in the four low order octets. The 322 high order octet shall be set to zero upon transmission and ignored 323 upon reception. 325 +---------------------------+ 326 | Must be Zero (1 octet) | 327 +---------------------------+ 328 | AS number (4 octets) | 329 +---------------------------+ 330 Figure 5: BGP speakers filter containing a single four octets AS number 332 If the BGP_Speakers_Filter value contains a CIDR prefix/length 333 pair, it should be encoded as shown below: 335 +---------------------------+ 336 | Length (1 octet) | 337 +---------------------------+ 338 | Prefix (4 octets) | 339 +---------------------------+ 340 Figure 6: BGP speakers filter containing a CIDR prefix/length pair 342 The Length field indicates the length in bits of the IP address 343 prefix. A length of zero indicates a prefix that matches all IP 344 addresses. The Prefix field contains IP address prefixes followed 345 by enough trailing bits with a value of zero to make the end of the 346 field fall on a four octets boundary. 348 2.2 Utilization of the redistribution communities 350 A router may, depending on its policy, add one or several redistri� 351 bution communities to a route originated by itself or received from 352 another BGP speaker over an iBGP or an eBGP session. In practice, 353 it can be expected that the redistribution communities will often 354 be attached by the originator of the route will as this is an 355 attempt of the route originator to do some form of inter-domain 356 traffic engineering. In practice, it can also be expected that most 357 utilizations of the redistribution communities will only require to 358 attach a small number of those communities to a given route. 360 When a router attaches one or several redistribution communities to 361 a route, it must ensure that two of the included redistribution 362 communities do not conflict. This is necessary to ensure that the 363 redistribution communities will be processed in a deterministic 364 manner by the remote BGP peer. When several redistribution 365 communities contain the same action type and parameter, then all 366 the BGP_Speakers_filters of those communities must have the same 367 high order bit in the BGP_Speakers_Filter type. A BGP router that 368 receives a route containing invalid redistribution communities for 369 a given action type and parameter should ignore all the redistribu� 370 tion communities concerning this action type and parameter. This 371 ignore action must be logged. 373 2.3 Operations 375 This document defines the procedures to support the redistribution 376 communities that are non-transitive extended communities of type 377 01TBDTBD. An implementation that understands the redistribution 378 communities should discard and ignore upon receipt the extended 379 communities of the form 00TBDTBD (i.e. same type as a redistribu� 380 tion community but transitive). 382 The redistribution communities defined in this document only affect 383 the redistribution of the associated route over eBGP sessions. The 384 redistribution communities do not affect the redistribution of 385 routes over iBGP sessions or between the sub-ASes of a confedera� 386 tion. 388 When a router receives a route with redistribution communities, it 389 should apply the operations specified by these communities when 390 redistributing the route over eBGP sessions. Since the redistribu� 391 tion communities defined by this document are non-transitive, a 392 router will remove the received redistribution communities when 393 redistributing those routes over eBGP sessions. Of course, nothing 394 prevents this router from adding its own redistribution communities 395 to this route before redistributing it. 397 A router should apply the policies defined by the redistribution 398 communities to the routes that is has selected for advertisement 399 from its Adj-Rib-Out based on its own policy. A route that contains 400 redistribution communities should be processed as follows: 402 First, the BGP speaker should build for each action type and param� 403 eter contained in the redistribution communities attached to the 404 route a list of the target BGP speakers contained in the BGP_Speak� 405 ers_filters for this action type. In the remainder of this sec� 406 tion, we will use the wordings "an eBGP session is affected by 407 action type x" to indicate that either of the following is true 408 when the BGP_Speakers_Filters contain AS numbers: 410 - the AS number of the remote BGP peer appears inside one of the 411 BGP_Speakers_Filter of the redistribution communities with action x 412 and the high order bit of the BGP_Speakers_Filter type is set to 413 one 415 - the AS number of the remote BGP peer does not appear inside any 416 of the BGP_Speakers_Filter of the redistribution communities with 417 action x and the high order bit of the BGP_Speakers_Filter type is 418 set to zero 420 When the BGP_Speakers_Filter contains a CIDR prefix/length, we will 421 use the wordings "an eBGP session is affected by action type x" to 422 indicate that either of the following is true: 424 - the IP address of at least one of the endpoints of the eBGP ses� 425 sion belongs to the CIDR prefix specified inside one of the 426 BGP_Speakers_Filter of the redistribution communities with action x 427 and the high order bit of the BGP_Speakers_Filter type is set to 428 one 430 - the IP addresses of the local and the remote endpoints of the 431 eBGP session do not belong to the CIDR prefix specified inside one 432 of the BGP_Speakers_Filter of the redistribution communities with 433 action x and the high order bit of the BGP_Speakers_Filter type is 434 set to zero 436 Then, when a route is about to be redistributed over an eBGP ses� 437 sion, the router first checks if this session is affected by action 438 type "Do not announce". If this is the case, the route is not 439 announced over this eBGP session. Otherwise, the router checks the 440 other action types as follows. 442 - If the eBGP session is affected by action type "No export" then 443 the well-known community NO_EXPORT is attached to the route. 445 - If the eBGP session is affected by one or more actions of type 446 "Prepend", then the AS-Path of the route shall be prepended n times 447 (with the AS number of the router redistributing the route) where n 448 is the smallest parameter of the matched "Prepend" actions. 450 Otherwise the route is announced over the eBGP session. 452 2.4 Filtering and precedence 453 In order to allow operators to control the implementation of their 454 policies, a BGP implementation that supports the redistribution 455 communities should allow the operator to determine, on a per ses� 456 sion basis whether redistribution communities are permitted or 457 denied on this session. For example, an AS could elect to receive 458 redistribution communities from its customers, but not on a shared- 459 cost peering session. A BGP implementation may provide additional 460 details in the filtering of the redistribution communities, but 461 this is implementation dependent and goes beyond this specifica� 462 tion. 464 A BGP implementation that supports both the normal (extended) com� 465 munities and the redistribution communities should allow the opera� 466 tor to adjust the order in which these types of communities are 467 processed. The default precedence should be to first process the 468 redistribution communities before processing the other manually 469 defined (extended) communities. 471 3 IANA considerations 473 This document requests the attribution of a new BGP extended commu� 474 nities type [EXT-COM] field from IANA. 476 The redistribution community contains two fields that are to be 477 maintained by IANA. The first field is the Action type that is part 478 of the Action octet defined in section 2.1 shall be maintained by 479 IANA. This document defines the utilization of action types 000b - 480 010b ; action types 011b - 111b are reserved for future use and are 481 to be assigned by IANA by IETF consensus as defined in [RFC2434]. 482 The second field are the seven low order bits of the Type octet of 483 the BGP_Speakers_Filter defined in section 2.1. This document 484 defines four types of BGP_Speakers_Filters (values 0x01-0x04). 485 Value 0x00 is reserved and values 0x05-0x3f are reserved for future 486 use and are to be assigned by IANA by IETF consensus as defined in 487 [RFC2434]. Values 0x40-0x7f are vendor specific and are assigned 488 by IANA on a first come, first serve basis. 490 4 Security considerations 492 This extension to BGP does not change the underlying security 493 issues of the extended community attribute. 495 5 Conclusion 497 This document has proposed a new type of extended communities 498 called the redistribution communities. These redistribution commu� 499 nities can be used by a BGP router to influence the redistribution 500 of some of its routes by its peers. Three types of redistribution 501 communities have been proposed. The first type may be used to 502 indicate that a specific route should not be announced over the 503 specified set of eBGP sessions. The second type may be used to 504 indicate that the attached route should only be announced with the 505 NO_EXPORT community over the specified set of eBGP sessions and the 506 third type may be used to indicate that the attached route should 507 be prepended n times when announced over the specified set of eBGP 508 sessions. 510 Acknowledgements 512 This work was partially funded by the European Commission, within 513 the ATRIUM IST project. We would like to thank Bart Peirens, 514 Alvaro Retana and Andrew Partan for their comments. 516 References 518 [Halabi97] B. Halabi. Internet Routing Architectures. Cisco Press, 519 1997. 521 [Huston01] G. Huston. AS1221 BGP table statistics. available from 522 http://www.telstra.net/ops/bgp/, 2001. 524 [COM-SUR] B. Quoitin, O. Bonaventure, A survey of the utilization 525 of the BGP community attribute, Internet draft, draft-quoitin-bgp- 526 comm-survey-00.txt, work in progress, February 2002 528 [Quoitin02] B. Quoitin, An implementation of the BGP redistribution 529 communities in zebra, Technical report Infonet-TR-2002-03, February 530 2002, http://www.infonet.fundp.ac.be/doc/tr/Infonet-TR-2002-03.html 532 [EXT-COM] S. Sangli, D. Tappan, and Y. Rekhter. BGP extended com� 533 munities attribute. Internet draft, draft-ietf-idr-bgp-ext-communi� 534 ties-05.txt, work in progress, May 2002. 536 [RFC2434] T. Narten, H. Alvestrand, Guidelines for Writing an IANA 537 Considerations Section in RFCs, RFC2434, October 1998 539 Authors' Addresses 541 Olivier Bonaventure, 542 Dept. Computing Science and Engineering 543 Universite catholique de Louvain (UCL) 544 Place Sainte-Barbe, 2, B-1348 Louvain-la-Neuve (Belgium) 545 Email: Olivier.Bonaventure@info.fundp.ac.be 546 URL : http://www.info.ucl.ac.be/people/OBO 548 Bruno Quoitin 549 Infonet group (FUNDP) 550 Rue Grandgagnage 21 551 B-5000 Namur 552 Email: Bruno.Quoitin@info.fundp.ac.be 553 URL : http://www.infonet.fundp.ac.be 555 Stefaan De Cnodder 556 Alcatel 557 Francis Wellesplein 1 558 B-2018 Antwerp, Belgium 559 Email: stefaan.de_cnodder@alcatel.be 561 Jeffrey Haas 562 NextHop Technologies 563 Email: jhaas@nexthop.com 565 Russ White 566 Cisco Systems 567 Email: ruwhite@cisco.com 569 Full Copyright Statement 571 Copyright (C) The Internet Society (2002). All Rights Reserved. 573 This document and translations of it may be copied and furnished to 574 others, and derivative works that comment on or otherwise explain it 575 or assist in its implementation may be prepared, copied, published 576 and distributed, in whole or in part, without restriction of any 577 kind, provided that the above copyright notice and this paragraph are 578 included on all such copies and derivative works. However, this doc- 579 ument itself may not be modified in any way, such as by removing the 580 copyright notice or references to the Internet Society or other 581 Internet organizations, except as needed for the purpose of develop- 582 ing Internet standards in which case the procedures for copyrights 583 defined in the Internet Standards process must be followed, or as 584 required to translate it into languages other than English. 586 The limited permissions granted above are perpetual and will not be 587 revoked by the Internet Society or its successors or assigns. 589 This document and the information contained herein is provided on an 590 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 591 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 592 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 593 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- 594 CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Appendix 1 Simple example 598 The redistribution communities defined in this document can be 599 used in two different ways. A first possible solution would be 600 to rely on the existing support for the extended communities in 601 BGP implementations and to manually configure the redistribution 602 communities defined in this document. This solution could be 603 used today by ISPs to support the redistribution communities (or a subset 604 of those communities) defined 605 in this document instead on defining special community values in 606 their community space and advertising them in the routing registries. 608 To illustrate a possible configuration with an existing BGP implementation 609 supporting the extended communities, we use a syntax similar 610 to the syntax used by zebra. Let us assume that one route 611 from AS3 has two peerings: one peering with AS2 and one peering with AS1. 612 The configuration below shows how AS3's router could be configured to 613 support the redistribution communities defined in this document. In 614 the configuration in figure A, we show each extended community in 615 hex format for readability reasons and only consider a subset of the 616 redistribution communities. Figure A shows how AS3 would configure its 617 routers to allow to request that a route announced to AS1 would be 618 prepended n times before being announced and to request that a specific 619 route would not be announced to AS2. 621 router bgp 3 622 neighbor 172.17.1.1 remote-as 1 623 neighbor 172.17.1.1 route-map prepend1_as1 out 624 neighbor 172.17.1.2 remote-as 2 625 neighbor 172.17.1.2 route-map do_not_announce_as2 out 626 ! Extended community list 627 ! -------------------------- 628 ! action "prepend x times" 629 ! filter "include AS1" 630 ! 631 ip extcommunity-list 1 permit 0x4401810000000001 632 ip extcommunity-list 2 permit 0x4402810000000001 633 ip extcommunity-list 3 permit 0x4403810000000001 634 ip extcommunity-list 4 permit 0x4404810000000001 635 ! 636 ! Route-maps 637 ! -------------------------- 638 ! action "prepend x times" 639 ! filter "include AS1" 640 ! 641 route-map prepend_as1 permit 10 642 match extcommunity 1 643 set as-path prepend 1 644 ! 645 route-map prepend_as1 permit 20 646 match extcommunity 2 647 set as-path prepend 2 648 ! 649 route-map prepend_as1 permit 30 650 match extcommunity 3 651 set as-path prepend 3 652 ! 653 route-map prepend_as1 permit 40 654 match extcommunity 4 655 set as-path prepend 4 656 ! 657 ! Extended community list 658 ! -------------------------- 659 ! action "do not announce" 660 ! filter "include AS2" 661 ! 662 ip extcommunity-list 5 permit 0x4410810000000002 663 ! 664 route-map do_not_announce_as2 deny 10 665 match extcommunity 5 666 ! 667 Figure A: Sample configuration 669 For a router with a small number of peers, such a manual configura� 670 tion of the redistribution communities is possible. However, if the 671 routers has many peers, the required configuration file may become 672 very large, especially if one wants to fully support all the redis� 673 tribution communities defined in this document. In this case, a bet� 674 ter solution is to rely on a direct support for the redistribution 675 communities inside the BGP implementation itself as discussed in 676 [Quoitin02]. With a BGP implementation supporting directly the redis� 677 tribution communities, a few lines of configuration will be suffi� 678 cient to enable or disable some or all of the redistribution communi� 679 ties for each peer.