idnits 2.17.1 draft-raszuk-idr-ibgp-auto-mesh-00.txt: 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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document is more than 15 pages and seems to lack a Table of Contents. == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2796]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 813 has weird spacing: '...for the purpo...' -- 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.) -- The document date (June 2003) is 7614 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2434' is defined on line 704, but no explicit reference was found in the text == Unused Reference: 'RFC1771' is defined on line 712, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) == Outdated reference: A later version (-26) exists of draft-ietf-idr-bgp4-21 -- Obsolete informational reference (is this intentional?): RFC 1965 (Obsoleted by RFC 3065) -- Obsolete informational reference (is this intentional?): RFC 2796 (Obsoleted by RFC 4456) -- Obsolete informational reference (is this intentional?): RFC 2858 (Obsoleted by RFC 4760) == Outdated reference: A later version (-17) exists of draft-ietf-idr-route-filter-08 -- No information found for draft-ietf-idr-as4octets - is the name correct? == Outdated reference: A later version (-01) exists of draft-lindem-ospf-cap-00 == Outdated reference: A later version (-06) exists of draft-walton-bgp-add-paths-01 -- No information found for draft-raszuk-isis-bgp-peer-discovery - is the name correct? Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Robert Raszuk (Editor) 3 Internet Draft Chandra Appanna 4 Category: Standards Track Cisco Systems, Inc 5 Expires: December 2003 Pedro Roque Marques 6 Juniper Networks, Inc 7 June 2003 8 IBGP Auto Mesh 9 draft-raszuk-idr-ibgp-auto-mesh-00.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its Areas, and its Working Groups. Note that other 18 groups may also distribute working documents as Internet Drafts. 20 Internet Drafts are draft documents valid for a maximum of six 21 months. Internet Drafts may be updated, replaced, or obsolete by 22 other documents at any time. It is not appropriate to use Internet 23 Drafts as reference material or to cite them other than as a "working 24 draft" or "work in progress". 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 The distribution of BGP routing information within an autonomous 35 system requires all border routers to be fully meshed. This 36 constitutes a significant operational problem in terms of 37 configuration management. 39 This has led to the wide-spread adoption of route reflection 40 [RFC2796], primarily in order to reduce the number systems which 41 configuration must be modified in order to introduce or remove a new 42 internal BGP speaker. Route reflection, however, implies with it 43 information reduction which is not always desired. 45 This document defines a discovery mechanism that is designed to 46 address the problem of introducing (or removing) a BGP speaker into 47 an iBGP mesh without implying any other behavior change when compared 48 to manual configuration. 50 1. Specification of Requirements 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 2. Introduction 58 One of the most common complains received from operators is the 59 comment on complexities associated with configuration of BGP meshes. 61 This draft attempts to make this claim a history by proposing auto 62 discovery of internal BGP peers via configuration information 63 flooding as well as a set of procedures which would allow to 64 establish IBGP sessions automatically. 66 It should be noted that for easy and fast deployment flooding of 67 information is piggybacked on top of existing IGP mechanisms. This 68 feature is designed with flooding mechanism transparency in mind. 69 When new and more effective flooding protocol is introduced and 70 deployed into production networks it should be with no additional 71 effort on the BGP component to migrate the flooding from IGPs to such 72 a new protocol. 74 Unlike other attempts in this area it does not relay on any 75 management station. Also it keeps all BGP functional and transport 76 mechanism unchanged. 78 The particular piece of functionality this draft addresses is 79 distribution of related local configuration to all routers within 80 flooding scope as well as usage of this information in establishment 81 of IBGP peering. 83 Today we can observe a number of network topologies where IBGP is 84 being used to distribute routing information between BGP speakers: 86 A - Full iBGP mesh between all routers in the AS 87 B - Full iBGP mesh between all members of confederation 88 C - Route reflectors clusters peering 89 D - Full iBGP mesh between all PEs/ASBRs and BGP free core 91 In the operation section we will describe how this draft can automate 92 IBGP peering in all of the above scenarios. 94 Another very important observation is that today BGP often play other 95 roles than just distribution of IPv4 reachability information. With 96 introduction of multiprotocol BGP extensions [RFC2858] BGP speakers 97 may be configured to keep and maintain data belonging to multiple 98 address families. 100 In multiprotocol environments, the IBGP mesh for one address family 101 may not match the mesh for a different address family as in the case 102 where different route reflectors are used for different applications. 103 This draft will also automate IBGP session establishment with 104 matching AFIs taken into consideration of the auto discovered peers. 106 Historically introduction of route reflection drastically removed the 107 need for full mesh manual configuration of all BGP speakers in a 108 domain. It also reduced the number of TCP session each BGP speakers 109 needed to handle. 111 Another characteristics of route reflection is their ability to 112 eliminate number of advertised paths to a given peer to only best 113 path from reflector's point of view. 115 While this last point was originally thought of a benefit (at least 116 from the perspective of best effort ipv4 reachability) today's 117 applications require a bit more granular path's classification and 118 features like IBGP multipath is becoming already a production 119 requirement. To keep the former benefit of reduced configuration or 120 low number of TCP sessions approaches like add-paths draft [ADD-PATH] 121 are being currently under investigation. 123 It should be noticed that idea presented in this draft eliminates any 124 manual configuration for full mesh BGP peering. Also modern operating 125 systems implementations can hold and maintain much more TCP sessions 126 that their predecessors could. Therefore by auto meshing all or 127 selected address families on BGP speakers the need for route 128 reflection becomes obsolete in some cases. 130 In order to reduce amount of information distributed across IBGP 131 sessions to only a required subset outbound route filtering 132 techniques could be employed [IDR-ORF]. 134 Another operational benefit of using IBGP auto mesh is the ease of AS 135 renumbering or merges/migrations. It is generally very difficult to 136 manually change the AS number on all BGP speakers in a short 137 maintenance window. With the automation such task would be much 138 easier to accomplish. 140 3. The BGP Auto Discovery TLV 142 This section proposes an encoding to be used in IPv4 & IPv6 networks. 144 The BGP Auto Discovery TLV is defined as follows: 146 0 1 2 3 147 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | TLV Type | Length | FLOODING RESERVED |F|D| 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | BGP Identifier | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | FRAG | BGP RESERVED | 16 bit CHECKSUM | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Autonomous System(s) or confederation sub-AS(s) sub-TLV | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | IPv4/IPv6 Peering Address sub-TLV | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | AFI/SAFI for mesh topologies sub-TLV | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | AFI/SAFI for reflection topologies sub-TLV | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Old BGP Identifier sub-TLV (opt) | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 Figure 1. BGP Auto Discovery TLV 168 3.1. TLV Type 170 BGP Auto Discovery TLV is proposed to be carried in OSPF Router 171 Information LSA [LINDEM1] with area scope or domain wide scope 172 depending on the configuration. Details describing OSPF specifics and 173 encoding will be described in [OSPF-BGP]. 175 In ISIS BGP Auto Discovery TLV is proposed to be carried as a new TLV 176 with flooding scope local to the intra area or domain wide. Details 177 describing ISIS specific encoding will be described in [ISIS-BGP]. 179 The selection of ISIS and OSPF for flooding is mostly based on the 180 fact that those protocols already have a flooding mechanism which can 181 be reused for the purpose of required in this proposal information 182 distribution. 184 It is a strong design goal that flooding of BGP Auto Discovery TLV 185 can be realized over any other protocol when such is deployed and 186 when it can provide further benefits. For example: selective groups 187 of destinations or disjoined information distribution trees per 188 AFI/SAFI. 190 In cases of multiple bgp processes running on a router each BGP 191 process should send it's own BGP Auto Discovery TLV with a different 192 BGP Identifier. 194 3.2. TLV Length 196 Length - Total length in octets of this TLV 198 The minimum TLV length can be 10 octets. 200 When a size of the TLV reaches 255 octets TLV fragmentation needs to 201 occur. A special "FRAG" 4 bit counter has been allocated in the BGP 202 Control Information's first octet for unlikely cases where BGP Auto 203 Discovery TLV needs to be splitted across multiple TLVs for a given 204 BGP speaker. 206 It is estimated that the average size of BGP Auto Discovery TLV in 207 today's production environments will be anywhere from 30-50 octets. 209 3.3. Global flooding flags 211 This comprises of one or more global for given BGP Auto Discovery TLV 212 flags related to flooding. Currently defined are the following flags: 214 0 1 2 3 215 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | TLV Type | Length | FLOODING RESERVED |F|D| 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 Figure 2. Value field of global flags 222 Symbol Definition 224 F Flooding scope 225 D Down Bit 227 "F" {flooding} flooding scope of this TLV. When set domain wide 228 flooding scope is required, when not set TLV should not be 229 flooded into other areas or levels. Default not set 230 indicating area/level wide flooding only. 232 "D" {down} down bit set by ISIS when leaked to other areas/levels. 234 When advertised BGP Auto Discovery TLV for a given BGP Identifier 235 does not contain any sub-TLVs it should be interpreted as an implicit 236 withdraw of any previously advertised BGP Auto Discovery TLV for a 237 given BGP Identifier. 239 This is intentional not to duplicate BGP capabilities in this 240 message. BGP operation in session establishment to auto discovered 241 peers should remain without any changes as compared to today's 242 operation. 244 All reserved flags and not defined yet should be set to zeros. 246 3.4. BGP Identifier 248 4 octet value set to BGP ID [IDR-BGP4]. When BGP ID is being changed 249 on a BGP speaker next BGP Auto Discovery TLV announced should contain 250 "Old BGP ID sub-TLV". Presence of this sub-TLV is an indication that 251 the received BGP Auto Discovery TLV is being related to previously 252 flooded BGP information with the contained in this sub-TLV BGP 253 Identifier. 255 3.5. BGP Control Information 257 The below 4 octets with BGP specific control information has been 258 defined: 260 0 1 2 3 261 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | FRAG | BGP RESERVED | 16 bit CHECKSUM | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 3 BGP Control Information 268 3.6. Fragmentation counter 270 When a size of the BGP Auto Discovery TLV reaches 255 octets TLV 271 fragmentation needs to occur. A special "FRAG" 4 bit counter has been 272 allocated for unlikely cases where BGP Auto Discovery TLV needs to be 273 splitted across multiple TLVs for a given BGP speaker. 275 3.7. Checksum 277 Depending on the flooding protocol being utilized BGP may be 278 receiving identical information periodically. To allow easy 279 determination if the content of the TLV has changed for a given BGP 280 Identifier 16 bit checksum has been defined. Checksum should be 281 computed from the content of the entire BGP Auto Discovery TLV 282 (before potential fragmentation) excluding first 4 octets of the TLV. 284 4. The BGP Auto Discovery sub-TLVs 286 In following subsections we will focus on describing each of the 287 sub-TLVs directly related to BGP operation. The format of each sub- 288 TLV will be following: 290 0 1 2 3 291 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Type | Length | RESERVED | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Value(s)... | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 4. BGP Sub-TLV 300 4.1. BGP Autonomous System(s) sub-TLV 302 Type One octet field set to value of 1. 303 Length One octet field that indicates the length of the value 304 portion in octets. 305 Reserved Two octet field reserved for flags and sub-TLV control 306 Value 4 octet BGP Autonomous System Number(s) [IDR-BGP4] 307 [IDR-AS4] or confederation sub-AS [RFC1965]. 309 Advertising multiple autonomous system numbers may be required during 310 AS renumbering and merges with other ASes. Therefore this proposal 311 does not limit advertisement to a single AS value per BGP speaker. 313 The peering attempt should be made only to those peers which match 314 locally configured AS number or numbers (multi-as migration case). 316 When confederation is used sub-AS will limit the scope of full mesh 317 peering only to a given sub-AS even if flooding scope is common to 318 all sub-ASes. Usage of route reflectors within each confederation 319 sub-AS is also supported. 321 4.2. IPv4 Peering Address sub-TLV 323 0 1 2 3 324 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Type | Length | RESERVED |F| 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | IPv4 Peering Address | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 Figure 5. BGP IPv4 Peering Sub-TLV 333 Type One octet field set to value of 2. 334 Length One octet field that indicates the length of the value 335 portion in octets. 336 Reserved Set to all zeros 337 Flag "F" - Force new peering. Default not set. 338 Value 4 octet ipv4 peering address 340 This address will be used by BGP speakers as a destination in BGP 341 Open message. Sending a BGP Auto Discovery TLV with new peering 342 address is an explicit withdraw of the previously advertised one. 344 When such a messages is received old peering should remain intact 345 when "F" flag is not set (default). When session is cleared manually 346 or IGP reachability to the old peering address disappears new peering 347 address should be used. 349 When "F" flag is set new peering address should be used immediately 350 and current BGP session to the peer restarted. 352 4.3. IPv6 Peering Address sub-TLV 354 0 1 2 3 355 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | Type | Length | RESERVED |F| 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | | 360 | IPv6 Peering Address | 361 | | 362 | | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 6. BGP IPv6 Peering Sub-TLV 367 Type One octet field set to value of 3. 368 Length One octet field that indicates the length of the value 369 portion in octets. 370 Reserved Set to all zeros 371 Flag "F" - Force new peering. Default not set. 372 Value 16 octet ipv6 peering address 374 This address will be used by BGP speakers as the destination in BGP 375 Open message. Sending a BGP Auto Discovery TLV with new peering 376 address is an explicit withdraw of the previously advertised one. 378 When such a messages is received old peering should remain intact 379 when "F" flag is not set (default). When session is cleared manually 380 or IGP reachability to the old peering address disappears new peering 381 address should be used. 383 When "F" flag is set new peering address should be used immediately 384 and current BGP session to the peer restarted. 386 When both IPv4 & IPv6 peering addresses are present it is up to the 387 implementation to decide on the peering address selection. 389 4.4. AFI/SAFI for mesh topologies sub-TLV 391 Type One octet field set to value of 4. 392 Length One octet field that indicates the length of the value 393 portion in octets. 394 Reserved Set to zero 395 Value 2 octet Address Family Identifier(s) [RFC2858] 396 1 octet Subsequent Address Family Identifier [RFC2858] 397 1 octet Per AFI/SAFI Flags 399 0 1 2 3 400 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Type | Length | RESERVED | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Address Family Identifier 1 | SAFI 1 | RESERVED |O| 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 ..... 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Address Family Identifier 1 | SAFI 2 | RESERVED |O| 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 7. Value field of BGP AFI/SAFI mesh topologies sub-TLV 413 Sub-TLV Value Flags: 415 "O" - Originator or EBGP speaker 417 Originator flag: 419 IBGP sessions in a full or partial mesh topology are required to 420 directly peer with those BGP speakers which originate routes or which 421 maintain EBGP sessions. This flag should be used to mark such a bgp 422 speakers when advertising BGP Auto Discovery TLV. On reception this 423 flag should be used for selection or required IBGP peering 424 candidates. 426 It is important to note that the actual state of EBGP session or 427 present or not in the routing table of redistribuited prefix is not 428 relevant and this bit should be set always when EBGP session or local 429 route origination is configured. 431 4.5. AFI/SAFI for reflection topologies sub-TLV 433 Type One octet field set to value of 5. 434 Length One octet field that indicates the length of the value 435 portion in octets. 436 Reserved Set to zero 437 Value 2 octet Address Family Identifier(s) [RFC2858] 438 1 octet Subsequent Address Family Identifier [RFC2858] 439 1 octet Per AFI/SAFI Flags 441 0 1 2 3 442 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length | RESERVED | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | Address Family Identifier N | SAFI N | RESERVED |R|O| 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Cluster ID N | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 ...... 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Address Family Identifier X | SAFI X | RESERVED |R|O| 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Cluster ID X | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Figure 8. Value field of AFI/SAFI reflection sub-TLV 459 Sub-TLV Value Flags: 461 "O" - Originator or EBGP speaker 462 "R" - Route Reflector for given AFI-SAFI/Cluster_ID combination 464 See section "AFI/SAFI for mesh topologies sub-TLV" for explanation of 465 "O" flag. 467 "R" - Route reflector flag. 469 When "R" flag is set BGP speaker announcing this TLV is configured 470 for route reflection function for a given AFI/SAFI combination. In 471 addition when "R" bit is set the following cluster ID 4 octet value 472 [RFC2796] indicates cluster id assigned for a given reflection 473 function. 475 Clients of route reflection will send their cluster ID lists assigned 476 to each AFI/SAFI without "R" bit set. When client wishes to indicate 477 the request to become a member of all possible cluster_ids for given 478 AFI/SAFI combination within a flooding scope of his BGP Auto 479 Discovery TLV the "R" bit should not be set and the value of 480 cluster_id associated with the AFI/SAFI should be set to all zeros. 482 To allow chain of route reflection (hierarchy) it is perfectly valid 483 for a BGP speaker to have for a given AFI/SAFI a "R" bit set for one 484 cluster IDs (ie to perform a route reflection function) and in the 485 same time for other cluster ID values be a client of other route 486 reflectors (R bit not set). 488 Network designs of reflection within confederations are also 489 supported. 491 At this time of publication authors will also leave the implementor's 492 freedom to allow single sided signaling only from route reflectors to 493 the clients. When client receives the BGP Auto Discovery TLV which 494 contains the interesting cluster ID and has R bit set it can initiate 495 BGP Open without injecting any information about his own BGP 496 configuration in the reflection topologies into the network. 498 4.6. Old BGP Identifier sub-TLV 500 0 1 2 3 501 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | Type | Length | RESERVED | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Old BGP Identifier | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 Figure 9. Old BGP Identifier Sub-TLV 510 Type One octet field set to value of 6. 511 Length One octet field that indicates the length of the value 512 portion in octets. 513 Reserved Set to all zeros 514 Value 4 octet BGP Identifier [IDR-BGP4]. 516 When BGP Identifier is being replaced with a new value the "Old BGP 517 Identifier" sub-TLV must be present and contain a previously 518 advertised BGP ID for this given BGP speaker. 520 5. Operation 522 Each BGP speaker configured to participate in an IBGP auto mesh 523 should pass to flooding component BGP Auto Discovery TLV with it's 524 own local configuration dependent information. 526 On the receive side, a cache should be maintained by BGP with all 527 received information from flooding component about other BGP speakers 528 announcing their BGP Auto Discovery TLVs in a given area or domain. 530 IBGP auto mesh configuration should allow for per address family and 531 subsequent address family disjoint topologies granularity. 533 When multiple AFI/SAFI pairs match on any two BGP speakers only one 534 IBGP session should be attempted. Regular BGP capabilities will be 535 used to negotiate given AFI/SAFI mutual set. Never less AFI/SAFI 536 granularity is required to allow for very fine grade disjoint 537 topologies for different types of distributed by BGP information. 539 5.1. Full mesh topologies 541 When operator finds required to fully or partially mesh BGP speakers 542 "AFI/SAFI for mesh topologies" sub-TLV should be utilized. 544 BGP speakers may be eligible for origination of routes or may be 545 configured for EBGP peering. We will call them "O" flag eligible (see 546 section "AFI/SAFI for mesh topologies sub-TLV"). 548 BGP speakers "O" flag eligible may establish session with any other 549 BGP speaker if passing all peering criteria for a given AFI/SAFI. 551 BGP speakers "O" flag not eligible (ex: P routers) should not 552 establish IBGP peering to any other "O" flag not eligible BGP 553 speakers. 555 One possible example of such a configuration could be vpnv4 AF 556 connecting all PEs in a domain into a full IBGP mesh. 558 After reception of peers BGP Auto Discovery TLV BGP speaker should 559 check for autonomous system numbers match as well as AFI/SAFI 560 identifiers match. Positive results from the above actions should 561 trigger a standard process of connection establishment attempt with 562 the peer. 564 It is also highly recommened that a local range of allowed peering 565 addressed be also maintained and consulted at each attempt to 566 establish a new IBGP peering. 568 BGP Auto Discovery TLV may be area/level or domain wide in full mesh 569 topologies. The default should be area/level wide flooding. 571 5.2. Confederations 573 To automate iBGP full mesh establishment in each confederation sub-AS 574 each confederation member should advertise it's confederation sub-AS 575 instead of main AS (confederation_id) it is a member of in BGP 576 Autonomous System(s) sub-TLV. 578 There could be two cases here: 580 A) Confederation sub-ASes strictly contained within flooding scope 581 B) Confederation sub-ASes unrelated to flooding topology 583 Case (A) BGP auto discovery TLV flooding scope should be limited to 584 one area/level. 586 Case (B) BGP auto discovery TLV flooding scope should be domain wide 587 and use of Auto Peering Range(s) sub-TLV is highly recommended. 589 In the cases where reflectors are used within each confederation 590 rather then direct peering "AFI/SAFI for reflection topologies sub- 591 TLV" should be used instead of "AFI/SAFI for mesh topologies sub- 592 TLV". 594 5.3. Route Reflectors 596 When operator wishes to automate establishment of BGP sessions to 597 route reflectors the only additional information required is 598 configuration of at least one identical cluster id on both route 599 reflector as well as on route reflector client. As mentioned earlier 600 even this requirement could be relaxed by implementation supporting 601 single sided signaling of reflector capabilities. The drawback in 602 such a case is that route reflector injecting his BGP Auto Discovery 603 TLV would also need to be configured with an additional information 604 allowing to distinguish BGP Open requests coming from clients as well 605 as those coming from non clients based on the peering address range 606 and mark such a peering accordingly. 608 Routers or devices designated to serve route reflector function shall 609 advertise their "AFI/SAFI for reflection topologies" sub-TLV with "R" 610 flag set as well as with their cluster id(s) attached. 612 If IBGP session will be established between route reflector ("R" flag 613 set) and non route reflector BGP speaker ("R" flag not set) who's 614 specific AFI/SAFI cluster ID matches on at least one entry with given 615 route reflector cluster id it should be marked as route reflector 616 client. 618 BGP speakers which are not to act as route reflectors ("R" flag not 619 set) and do not have configured cluster id value(s) indicating their 620 designation as route reflector clients would attempt to establish 621 regular IBGP peering to other BGP speakers in the domain (per rules 622 described in section "Full mesh topologies"). 624 An implementation may also allow the additional route reflection 625 client to client full mesh. This is left for the implementor's choice 626 to be enabled with a configuration option. 628 Route reflection chaining (reflector hierarchy) is fully supported. 629 Route reflector server may advertise for a given AFI/SAFI his ability 630 to reflect routes for one set of cluster ID(s) ("R" bit set) and in 631 the same time for the same AFI/SAFI value submit a list of cluster 632 IDs without "R" bit set indicating the willingness to become a 633 regular client on servers eligible to reflect those cluster ID(s). 635 When client wishes to indicate the request to become a member of all 636 possible cluster_ids for given AFI/SAFI combination within a flooding 637 scope of his BGP Auto Discovery TLV the "R" bit should not be set and 638 the value of cluster_id associated with the AFI/SAFI should be set to 639 all zeros. 641 6. Local peering verification 643 It is highly recommended for an implementation to support local 644 configuration of all possible remote peering address ranges expected 645 to be received via BGP Auto Discovery TLV messages. 647 In particular this can protect from configuration mistakes when 648 peering in a full or partial mesh and setting flooding scope 649 accidentally to domain wide. 651 In this version of the draft the decision has been made not to flood 652 this local peering range list to the remote peers. Such a flooding 653 could further protect from even sending BGP Open message when given 654 bgp speaker own peering address does not match received list from a 655 peer. 657 That decision can be revisited in the future versions of this work 658 and new sub-TLV for flooding this information can be added. 660 7. Deployment Considerations 662 The idea described in this document should not present any deployment 663 challenges. It is expected that all implementations would still allow 664 manual neighbor establishments which in fact could be complimentary 665 and co-existing to the IBGP auto mesh. 667 In addition BGP Auto Discovery TLV exchange could be enabled just for 668 informational purposes while provisioning would remain manual before 669 operational teams get familiar with new functionality. 671 Incremental deployment with enabling just a few routers to advertise 672 BGP Auto Discovery TLV while maintaining manual configuration based 673 peering with the rest of the network is supported. An implementation 674 may also allow for mixed peering for example reflector client being 675 configured automatically while reflector's clusters itself being 676 interconnected manually. 678 8. IANA Considerations 680 There are no IANA considerations required in this document. 681 Extensions to ISIS [ISIS-BGP] & OSPF [OSPF-BGP] will have their own 682 IANA consideration sections. 684 9. Security Considerations 686 This document fully relies on authentication mechanism that an 687 implementation of BGP MUST support as specified in [RFC2385]. The 688 authentication provided by this mechanism could be done on a per peer 689 basis. 691 It also relies on security of flooding mechanism being used for 692 information distribution. 694 10. Acknowledgments 696 I would like to express our thanks to Alvaro Retana, Keyur Patel, 697 Barry Friedman & Gargi Nalawade for their valuable comments. 699 11. Normative References 701 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 702 Requirement Levels", RFC 2119, March 1997. 704 [RFC2434] Narten, T., Alvestrand, H., "Guidelines for Writing an 705 IANA Considerations Section in RFCs", RFC2434, October 1998. 707 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 708 Signature Option", RFC2385, August 1998. 710 12. Informative References 712 [RFC1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 713 (BGP-4)", RFC 1771, March 1995. 715 [IDR-BGP4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 716 (BGP-4)", Work in Progress (draft-ietf-idr-bgp4-21.txt), April 717 2003. 719 [RFC1965] Traina, P., "Autonomous System Confederations for BGP", 720 RFC 1965, June 1996. 722 [RFC2796] Bates, T., Chandra, R., and Chen, E., "BGP Route 723 Reflection An Alternative to Full Mesh IBGP", RFC 2796, April 724 2000. 726 [RFC2858] Bates, T., Rekhter, Y., Chandra, R., Katz, D., 727 "Multiprotocol Extensions for BGP-4", RFC 2858, June 2000 729 [IDR-ORF] Chen, E., Rekhter, Y., "Cooperative Route Filtering 730 Capability for BGP-4", draft-ietf-idr-route-filter-08.txt 732 [IDR-AS4] Vohra, Q., Chen, E., "BGP support for four-octet AS number 733 space" draft-ietf-idr-as4octets-06.txt, January 2003 735 [LINDEM1] Lindem, A. at all, "Extensions to OSPF for Advertising 736 Optional Router Capabilities", draft-lindem-ospf-cap-00.txt, May 737 2003 739 [ADD-PATH] Walton, D.,at all, "Advertisement of Multiple Paths in 740 BGP" draft-walton-bgp-add-paths-01.txt 742 [ISIS-BGP] Raszuk, R., "ISIS Extensions for BGP Peer Discovery" , 743 draft-raszuk-isis-bgp-peer-discovery-00.txt, June 2003 Work in 744 progress 746 [OSPF-BGP] Raszuk, R., "OSPF Extensions for BGP peer discovery", 747 draft-raszuk-ospf-bgp-peer-discovery.txt, Work in Progress 749 13. Authors' Addresses 751 Robert Raszuk 752 Cisco Systems, Inc. 753 Al. Jerozolimskie 146C 754 02-305 Warsaw, Poland 755 E-mail: rraszuk@cisco.com 757 Pedro Marques 758 Juniper Networks, Inc. 759 1194 N. Mathilda Ave. 760 Sunnyvale, CA 94089 761 E-mail: roque@juniper.net 763 Chandrashekhar Appanna 764 Cisco Systems, Inc 765 170 West Tasman Dr 766 San Jose, CA 95134 767 E-mail: achandra@cisco.com 769 14. IPR Notices 771 The IETF takes no position regarding the validity or scope of any 772 intellectual property or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; neither does it represent that it 776 has made any effort to identify any such rights. Information on the 777 IETF's procedures with respect to rights in standards-track and 778 standards-related documentation can be found in BCP-11. Copies of 779 claims of rights made available for publication and any assurances of 780 licenses to be made available, or the result of an attempt made to 781 obtain a general license or permission for the use of such 782 proprietary rights by implementors or users of this specification can 783 be obtained from the IETF Secretariat. 785 The IETF invites any interested party to bring to its attention any 786 copyrights, patents or patent applications, or other proprietary 787 rights which may cover technology that may be required to practice 788 this standard. Please address the information to the IETF Executive 789 Director. 791 15. Terms of Use 793 Cisco has a pending patent which relates to the subject matter of 794 this Internet Draft. If a standard relating to this subject matter 795 is adopted by IETF and any claims of any issued Cisco patents are 796 necessary for practicing this standard, any party will be able to 797 obtain a license from Cisco to use any such patent claims under 798 openly specified, reasonable, non-discriminatory terms to implement 799 and fully comply with the standard. 801 16. Full Copyright Notice 803 Copyright (C) The Internet Society (2002). All Rights Reserved. 805 This document and translations of it may be copied and furnished to 806 others, and derivative works that comment on or otherwise explain it 807 or assist in its implmentation may be prepared, copied, published and 808 distributed, in whole or in part, without restriction of any kind, 809 provided that the above copyright notice and this paragraph are 810 included on all such copies and derivative works. However, this 811 document itself may not be modified in any way, such as by removing 812 the copyright notice or references to the Internet Society or other 813 Internet organizations, except as needed for the purpose of 814 developing Internet standards in which case the procedures for 815 copyrights defined in the Internet Standards process must be 816 followed, or as required to translate it into languages other than 817 English. 819 The limited permissions granted above are perpetual and will not be 820 revoked by the Internet Society or its successors or assigns. 822 This document and the information contained herein is provided on an 823 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 824 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 825 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 826 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 827 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.