idnits 2.17.1 draft-hares-asconfed-edge-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 816. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (February 24, 2008) is 5903 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) ** Obsolete normative reference: RFC 3392 (ref. '2') (Obsoleted by RFC 5492) == Outdated reference: A later version (-16) exists of draft-ietf-idr-dynamic-cap-09 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group S. Hares 3 Internet-Draft Green Hills Software 4 Expires: August 27, 2008 P. Bose 5 Lockheed 6 February 24, 2008 8 Dynamic AS Re-Association At Confederation Edge 9 draft-hares-asconfed-edge-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 27, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document provides a mechanism for Autonomous Systems within an 43 AS Confederation to survive the disconnection to other AS within the 44 AS confederation without dropping peers. When all links to the other 45 AS in the Confederation break, this mechanism allows the AS to revert 46 to local AS to continue communication with E-BGP peers. This 47 mechanism has two parts: Capability signaling between the two parties 48 at connection start to save two AS (internal and AS Confederation AS) 49 and a mechanism to signal the switch between AS Confederation AS and 50 internal AS. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 56 3. Mechanism overview for Dynamic AS Confederation Edge 57 Re-association . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. BGP Peer mechanisms . . . . . . . . . . . . . . . . . . . . . 7 59 5. Open Dynamic AS Capability . . . . . . . . . . . . . . . . . . 11 60 6. Capability Message . . . . . . . . . . . . . . . . . . . . . . 13 61 7. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 15 62 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 63 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 64 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 66 Intellectual Property and Copyright Statements . . . . . . . . . . 25 68 1. Introduction 70 This mechanism provides a mechanism for an Autonomous System within 71 an AS confederation to survive disconnection from the rest of the 72 Autonomous Systems within the AS Confederation. When an AS is 73 connected to the rest of an AS confederation, it acts as a single AS. 74 If all links between the AS to other members of the AS confederation 75 are broken, the AS Confederation is broken in two (or more) parts, 76 and the individual sub-Autonomous Systems (sub-AS-es) within the 77 confederation may need to "back off" to their local AS number to 78 restore connectivity through some external path. 80 If a router along the edge of an AS determines the sub-AS has lost 81 its connection to the remainder of the confederation AS, it will need 82 to change the AS number with which it is peering to eBGP peers. This 83 restart of all EBGP connections can be onerous for the AS that has 84 broken away from the AS Confederation. This draft provides a 85 mechanism for the AS within the AS confederation to use a pre-agreed 86 upon fail-over to the internal AS, so its eBGP connections will not 87 be reset. 89 Upon return of the AS Confederation links, this mechanism can signal 90 the Edge AS returning to the AS Confederation. 92 2. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in RFC 2119 [1]. 98 3. Mechanism overview for Dynamic AS Confederation Edge Re-association 100 The mechanism has parts: Open Capability and Dynamic Capability. 102 1) An Dynamic AS-Confederation Edge Open capability 104 The AS-Confederation capability signals the ability to fail-over upon 105 "AS confederation disconnect" by changing the local AS number without 106 resetting the eBGP peering session. 108 The format of the ASConfed-Edge capability is described in section 4 109 and contains the AS of the Confederation and a list of Internal AS 110 that the BGP peer will back off to. This capability also indicates 111 the mechanism by which the node will signal the switch via the 112 dynamic capabilities. 114 Note: The detection of the "AS confederation disconnect" is a locally 115 determined feature that includes (but is not limited to): determining 116 that all AS Confederation BGP peers are disconnected from this peer. 118 2) Dynamic Capablity - Signaling AS Fail-over and Restoration 120 2.1)Signaling the AS Fail-over to Internal AS 122 Signaling an AS fail-over is done via a dynamic capability with 123 the ASConfed_Edge capability with AS flag on. The 124 ASConfed_Edge dynamic capability requires a dynamic capability 125 with an "ACK" be sent to the originating BGP peer. Whether the 126 "ACK" signals a success or failure, the full ASConfed_Edge 127 capability must be sent. 129 The AS peer wishing to switch from an AS confederation to an 130 internal AS, signals this to a peer by sending a ASConfed_Edge 131 dynamic capability with the AS-in-Use flag set to the internal 132 AS. 134 Upon receiving this dynamic capability the BGP speaker 135 associated with the AS-Confederation Edge switches from the AS 136 confederation to the AS number specified for the session to the 137 internal session. 139 After switching to the new AS: 141 -All checking of the local AS in BGP packets utilizes the 142 new AS. 144 -All new routes will be announced with the new AS number. 146 -All older routes will be re-announced based on the AS 147 resend flag. 149 2.2) Signaling a AS restoring to AS confederations 151 When the AS Confederations links are re-established, the BGP 152 speaker on the AS Confederation sends a Dynamic Capability with 153 the ASConfed_Edge Capability with "AS in Use flag" set AS 154 Confederation flag. All AS checking for the local BGP speaker 155 reverts to the original Confederation AS. 157 After switching back to the AS Confederation: 159 -All Checking of the local AS in BGP packets utilizes the AS 160 Confederation number. 162 -All new routes will be announced with the AS confederation 163 number 165 All older routes will be re-announced with the AS 166 confederation number based on the AS resend flag. 168 4. BGP Peer mechanisms 170 The mechanism has two parts: 172 1) Negotiate Open Capability with AS Confederation Edge 174 The ASConfed-Edge capability signals that a BGP peer ability to 175 use the Dynamic AS Dynamic-Capability exchange on an AS 176 Confederation Edge. 178 The format of the ASConfed-Edge capability is described in section 179 5 and contains a list of Autonomous systems that the BGP peer may 180 re-associated to. This capability also indicates the mechanism by 181 which the node will signal the switch is the dynamic capabilities 182 message. The resend flags indicated in the type of resend flags 183 the peer will support. 185 Within an AS, any BGP peer that will send an ASConfed-Edge 186 Capability to an Exterior peer MUST send the ASConfed-Edge 187 capability to all IBGP peers. Only if all IBGP Peers successfully 188 negotiated the ASConfed-Edge capability, can any BGP peer 189 dynamically switch over from the AS Confederation to an internal 190 AS using this mechanism. 192 2) Signaling the Dynamic AS Confederation Switch -Originator 194 Signaling a Dynamic Switch is done via the Dynamic Capability 195 message DYN-CAP [3] with the Dynamic AS capability (format in 196 section 6). 198 The BGP peer decides to initiate the AS switch over by using local 199 policy and implementation specific mechanisms. To signal the 200 Dynamic AS switch over, the initiating BGP peer has two steps. 202 Step 1: Dynamic AS Confederation AS change to all IBGP peers 204 Upon receiving a "Dynamic AS Confederation change" indication 205 to the BGP process, the BGP process will send to IBGP peers a 206 dynamic capability message with Dynamic AS Confed_Edge 207 capability with flags of: 209 Source flag to IBGP 211 AS use set to either InternalAS /AS Confederation, 213 Reserve/Start set to reserve, 214 Success flag set to Success (0) and, 216 Resend flags set to peers desired resend capability 218 If the Dynamic AS Confederation is switching from the AS 219 Confederation to the internal peer, the flag is set to internal 220 peer. If peer is requesting a switch from the internal AS to 221 the AS Confederation, the flag is set to AS Confederation 223 Upon receiving the ACK from all IBGP peers for the Dynamic AS 224 Capability,the BGP peer will send a capability message with the 225 AS Confed_EDGE capability with flags set to: 227 source flag to IBGP, 229 the AS use set to InternalAS/AS Confederation, 231 Reserve/Start set to Start, 233 Success/Failure byte - set to Success, and 235 resend flags set to peers desired resend capability. 237 Upon receiving an ACK from all IBGP peers for the dynamic AS 238 Confed_EDGE capability with start step 2. 240 In case of the receiving IBGP peer's local BGP implementation 241 detecting a failure to switch to a new AS when it receives the 242 dynamic capability with the "Reserve" flag set, Capability will 243 be signaled with a "failure" flag. This failure will halt the 244 originating Peer switch to the new AS. The failure is signaled 245 by responding to the Dynamic ASConfed_Edge dynamic capability 246 with the following bits set: 248 source flag set to IBGP 250 AS use flags set to internal/AS confederation, 252 Reserve/Start set to reserve, 254 resend flags set to original resend 256 If the IBGP peers are part of a Route-Reflection hierarchy, a 257 Route Reflector MUST wait to send an ack to the Dynamic AS 258 change after it has signaled all of its clients and all of it 259 total mesh peers. In this way, when the initiating IBGP peer 260 receives the Dynamic Capability ACK, the rest of the IBGP peer 261 has been informed. 263 Note: that the Dynamic Capability ACK may pass back success or 264 failure. A failure anywhere in an IBGP cloud will not allow 265 the BGP to progress to step 2. Each AS Confed_Edge capability 266 MUST be responded to with an dynamic capability with an ACK. 268 Step 2: Send all EBGP peers the Dynamic AS Confederation Change 270 Each EBGP peers signal the Dynamic AS change to its neighbor 271 with ASConfed_EDGE Dynamic Capability. When sent to an EBGP 272 peer, the source flag is set to "EBGP" flag. 274 Upon receiving this dynamic capability from an E-BGP peer, the 275 BGP speaker processes the switch of the peer from the current 276 AS number to the one specified in the capability. This change 277 in processing includes: 279 -All checking of the local AS in BGP packets utilizes the 280 new AS. 282 -All new routes will be announced with the new AS number. 284 -All older routes will be re-announced based on the AS 285 resend flag. 287 Upon successful processing, the EBGP peer will acknowledge the 288 Dynamic AS capability by sending a Dynamic Capability with an 289 Ack in the Dynamic Capability flag and an "ack-succeess" 290 indication in the Dynamic Capabiity flag word. 292 3) E-BGP Peer Receiving a Signaling the Dynamic AS Switch-over 294 Upon receiving a "Dynamic AS Change" Dynamic capability from an EBGP 295 peer, the EBGP peer will follow 2 steps: 297 Step 1: Upon receiving a Dynamic AS Confed_Edge capability the BGP 298 process will send to all IBGP peers the Dynamic AS Confed_Edge 299 dynamic capability with an the as switch over flags. 301 Upon receiving the Dynamic Capability with the "Ack" bit set 302 from all IBGP peers for the Dynamic ASConfed_EDGE Capability, 303 the BGP peer can start step 2. 305 Again, if the IBGP peers of the receiving BGP are part of a 306 Route-Reflection hierarchy, a Route Reflector MUST only send an 307 ACK to the Dynamic AS Confed_Edge change after it has 308 successfully sent the Dynamic Capability to its clients and all 309 of it total mesh peers. In this way, when the initiating IBGP 310 peer receives the Dynamic capability ACK, the rest of the IBGP 311 peer has been informed. 313 In case of errors in resetting the Dynamic AS capability, the 314 receiving IBGP peer can set the "Failure" flag in the Dynamic 315 capability that is being ACK. Any failures will be signaled to 316 the originating AS, and the Dynamic AS switch terminated. 318 Termination of the AS_confederation switch can be done by 319 deleting the Dynamic AS_Confederation capability 321 Step 2: Respond to E-BGP AS with Dynamic AS change 323 The E-BGP peer responds to the originated AS with a Dynamic AS 324 change with an EBGP flag set and the Failure bit off. 326 Upon receiving this dynamic capability from an E-BGP peer, the 327 BGP speaker associated with the AS Edge process the switch of 328 the peer from the current AS number to the one specified in the 329 capability. This switch includes: 331 -All checking of the local AS in BGP packets utilizes the 332 new AS. 334 -All new routes will be announced with the new AS number n 336 -All older routes will be re-announced based on the AS 337 resend flag. 339 5. Open Dynamic AS Capability 341 RFC 3992 [2] describes the open capability mechanisms. This document 342 describes a new Capability: Dynamic ASConfeder_EDGE. 344 +------------------------------+ 345 | Capability Code (1 octet) | 346 +------------------------------+ 347 | Capability Length (1 octet) | 348 +------------------------------+ 349 | Capability Value (variable) | 350 +------------------------------+ 352 Where the Capability value is: 354 +------------------------------+ 355 | Length of AS (1 octet) | - length of AS field (2 or 4) 356 +------------------------------+ 357 | Reserved (5 bits) | - Reserved 358 +------------------------------+ 359 | resend prefix flag (3 bits) | - Resend/AS Flag 360 -------------------------------- 361 | Number of AS supported | - # of AS in re-associate list 362 | (1 octet) | 363 +------------------------------+ 364 | AS confederation | - AS Confederation number 365 +------------------------------+ 366 | internal AS number | - AS 1 dynamic re-association 367 +------------------------------+ 369 Dynamic AS Confederation Edge Open Capability Bytes 371 The resend prefix flag indicates when the AS will resend the routes 372 with the new AS. The flag values are set as a bit pattern to 373 indicate that 375 0x00 - Resend routes based on local timer (in bataches) 377 0x01 - Resend routes immediately 379 0x02 - Don't resend routes (leave with old AS confederation) 381 The number of AS supported field gives the number of the Autonomous 382 Systems fin the dynamic re-association list.The Autonomous Systems in 383 the AS list are the list of ASes that this peer may switch to in when 384 dynamically re-association from the original AS to a new AS. 386 Each side of the peer will send a list of Autonomous Systems that it 387 will dynamic re-associate with. Upon start-up the re-associations 388 list can be check by policy to determine that each side can support 389 the required re-associations. 391 6. Capability Message 393 This BGP dynamic capability uses the new BGP Dynamic Capability DYN- 394 CAP [3] format of: 396 +------------------------------+ 397 | Init/Ack (1 bit) | 398 +------------------------------+ 399 | Ack Request (1 bit) | 400 +------------------------------+ 401 | Reserved (5 bits) | 402 +------------------------------+ 403 | Action (1 bit) | 404 +------------------------------+ 405 | Sequence Number (4 octets) | 406 +------------------------------+ 407 | Capability Code (1 octet) | 408 +------------------------------+ 409 | Capability Length (2 octets) | 410 +------------------------------+ 411 | Capability Value (variable) | 412 +------------------------------+ 414 The capability value is: 416 +------------------------------+ 417 | Length of AS | - Length of AS field 418 +------------------------------+ 419 | Source (1 bits) | - Source flag 420 +------------------------------+ 421 | Failure flag (1 bits) | - Resend/AS Flag 422 +------------------------------+ 423 | Confed AS in Use (1 bit) | - Confederation AS in use 424 +------------------------------+ 425 + IBGP Reserve or Send + - Reserve/Start IBGP peers 426 +------------------------------- 427 | reserved (1 bits) | - Reserved 428 +------------------------------+ 429 | resend prefix flag (3 bits) | - Resend/AS Flag 430 +------------------------------+ 431 | Current AS number | - Old AS number 432 +------------------------------+ 433 | New AS number | - new AS number 434 +------------------------------+ 436 Dynamic AS Confed Edge Dynamic Capability Bytes 438 bit definitions: 440 Source Flag flag (1 bits) 442 0 - node originated 444 1 - EBGP peer originated 446 Failiure Flag (1 bit) 448 1 - failure 450 0 - success 452 AS in USE: 454 0x0 - Internal AS number 456 0x1 - AS Confederation number 458 IBGP Reserve or Start 460 0x0 - Reserve IBGP peers only, Do not start EBGP peers 461 negotiation. 463 0x1 - Start IBGP peers and Start EBGP negotiation 465 Resend flag values 467 0x00 - Resend routes based on local timer 469 0x01 - Resend routes immediately 471 0x02 - Don't resend routes (leave with old AS confederation) 473 7. Prevention of Loops 475 Because all IBGP nodes are synchronized before an EBGP peer is 476 transition to a new AS, the local BGP logic can detect the full 477 transition. 479 If any active IBGP peer is unable to transition, the whole transition 480 to the new AS stops. 482 The two stages of IBGP negotation (IBGP only and EBGP/IBGP 483 negotiation) allow the peer to negotiated the ability to AS change 484 before information exterior peers. The two stage IBGP negotiation 485 can reduce or eliminate chatter to EBGP peers while the IBGP peers 486 settle on the decision to change the AS. 488 The two stage negotiation requires that IBGP peers deal with the 489 multiple AS identity that AS confederation nodes have. Each AS 490 confederation node has an internal AS and a Confederation Edge AS. 491 This section describes two scenarios of using the two stage process. 492 In the first scenario, the IBGP stage 1 synchronization fails. In 493 the second example, the IBGP Stage 1 synchronization succeeds. 495 In the example below, Node B, C, D an E are inside the AS 496 confederation. Nodes A and F are outside the AS confederation 497 (denoted as AS 200). 499 When node D is disconnected from Node C, the dynamic AS Confederation 500 Edge switch takes place. Node B, C, and E switch to AS 1000 for IBGP 501 and EBGP. Their split view of the world (AS 200/1000) becomes just 502 AS 1000. Node C detects the loss of the Connection to D, and sends 503 an indication to switch to the Internal AS. 505 +--------+ +-------------------+ +-------------------+ +-------+ 506 +EBGP + + EBGP |IBGP Peer+ +IBGP peer| EBGP + +EBGP + 507 +outside +--+AS Confed|Internal + +Internal | inside + +inside + 508 + confed + + AS 200 |AS 1000 +-|-+ AS 1000 | confed +-|-+Confed + 509 + AS 300 + + | + | + | AS 1000 + +AS 2000+ 510 + + + | + | + | + + Node D + 511 + + + | + | + |-------- + +-------+ 512 + A + + Node B + | + Node C | S 200 + +AS 200 + 513 +----|---+ +-------------------+ | +---------+------|--+ +--|----+ 514 | | | | 515 | +---------------------+ +------------+ | 516 | |EBGP Peer | IBGP Peer| | EBGP peer +--- 517 +-----------|AS Confed | AS 1000 | | outside + 518 | AS 200 | | | Confed + 519 | | | | AS 500 + 520 | Node E| | | Node F + 521 +---------------------+ +------------+ 523 Dual AS identities for an IBGP with Dynamic AS Confederation 525 Loop Prevention 527 1) Two stage commit in IBGP peers with failure 529 1. Node C's sends a Capability message to Node B with sequence 530 number 10 and an Add capability for Dynamic AS Confed_Edge 531 Capability. Inside the Dynamic AS Confed_Edge capability the 532 flags are set for: IBGP, Reserve and AS-in-Use Internal, 533 Success (always on request capability). The AS Confederation 534 is 200, and the Internal AS is 1000. 536 2. Node C's sends a Capability message to Node E with sequence 537 number 30 and an Add capability for Dynamic AS Confed_Edge 538 Capability. Inside the Dynamic AS Confed_Edge capability the 539 flags are set for: IBGP, Reserve and AS-in-Use Internal, 540 Success (always on request capability); the AS Confederation 541 is 200, and the Internal AS is 1000. 543 3. Node B trys to engage the AS 1000 switch but fails due to some 544 internal problem. 546 4. Node B sends a dynamic capability (seqence number 10) with an 547 ACK flag set and a Dynamic AS Confed_Edge capability inside 548 with flags set to: IBGP, Reserve, AS-in-Use Internal, Failure. 550 5. Node E successful can switch to the Internal AS. Node E sends 551 the capability message with an ACK flag, sequence number 30, 552 and an AS Confed_Edge capability inside. The flags inside the 553 AS Confed_Edge capability are set to: IBGP, Reserve, AS-In Use 554 Internal, and Success. 556 6. Node C sends sends a capability message to Node E with 557 sequence number 31, Delete flag, Dynamic AS Confed_Edge 558 capability with flag bits set to: IBGP, Reserve, AS-in-Use 559 Internal, and Failure. 561 7. Node E clears all Dynamic AS Confederation state and respond 562 with a capability messages with an "Ack" flag set, sequence 563 number 31, Delete Flag, Dynanic AS Confed_Edge capability with 564 flag bits set to:IBGP, Reserve, AS-in-Use Internal and 565 Failure. 567 8. Node C, B, and E form one portion of AS confederation 200, and 568 Node D forms another portion. (These loops are possible with 569 normal AS Confederations and the rejection by Node B stops the 570 Dynamic AS Confederation Edge from preventing the loops. 572 2) Two stage commit with IBGP peers with success 574 1. Node C's sends a Capability message to Node B with sequence 575 number 10 and an Add capability for Dynamic AS Confed_Edge 576 Capability. Inside the Dynamic AS Confed_Edge capability the 577 flags are set for: IBGP, Reserve and AS-in-Use Internal, 578 Success (always on request capability). Inside the Dynamic 579 AS Confed_Edge capability the AS Confederation is 200, and 580 the Internal AS is 1000. 582 2. Node C's sends a Capability message to Node E with sequence 583 number 30 and an Add capability for Dynamic AS Confed_Edge 584 Capability. Inside the Dynamic AS Confed_Edge capability the 585 flags are set for: IBGP, Reserve and AS-in-Use Internal,and 586 sucess. Success (always on request capability). Inside the 587 Dynamic AS Confed_Edge capability, the AS Confederation is 588 200, and the Internal AS is 1000. 590 3. Node B trys to engage the AS 1000 switch and succeeds. Node 591 B responds to Node C with a capability message with sequence 592 number 10, Ack Flag set, and a Dynamic AS Confed_Edge 593 caability inside. The Dynmic AS Confed_Edge capability has 594 flags set for: IBGP, Reserve, AS in-Use, and Success. 596 4. Node E successful can switch to the Internal AS. Node E 597 sends the capability message with an ACK flag, sequence 598 number 30, and an AS Confed_Edge capability inside. The 599 flags inside the AS Confed_Edge capability are set to: IBGP, 600 Reserve, AS-In Use Internal, and Success. 602 5. Node C's sends a capability message to Node B (seq 11) and 603 Node E (sequence 31) with an Add capability for Dynamic AS 604 Confed_Edge capability. Inside the Dynamic AS Confed_Edge 605 Capability,the flags are set to: IBGP, Reserve and AS-in-Use 606 Internal, Start, and Success (always on request capability). 607 AS 200 is in the AS confederation. AS 1000 is in the 608 internal AS. 610 6. Node B (sequence 11) sends back a capability messages with 611 ACK bit set on the Add of the Dynamic AS Confed_Edge 612 capability. Within the AS Confed_Edge capability, the flags 613 are set to: IBGP, Start, AS-in-Use Internal, and Success. 614 Node B starts to send capability mesages with Dynamic AS 615 Confed_Edge capability to the E-BGP peers. 617 1. Node B sends to Node A a capability message with Add of 618 Dynamic AS Confed_Edge capability with sequence number 5. 619 Inside the Dynamic AS Confed_Edge capability, the flags 620 are set to: EBGP, Start, AS-in-Use Internal, and Success. 622 2. Node A validates it can switch the E-BGP session to 623 receive AS 1000 from Node B. Node A sends back a 624 capability message with sequence number 5 with an ACK 625 flag set with an Internal AS Confed_Edge Capability 626 inside. Inside the AS Confed_Edge Capability the flags 627 are set to: EBGP, Start, AS-in-Use Internal and Success. 629 7. Node E sends node C a capability messages with sequence 630 number 31, Action Add and An Ack Flag set. The Dynamic AS 631 Confed_edge capabilty is contained inside with flags set to: 632 EBGP, Start, AS-in-Use Internal, and Success. Node E starts 633 to send capability messages with Dynamic AS Confed_Edge 634 capability to the E-BGP peers. 636 1. Node E sends to Node A a capability messages with 637 sequence number of 15. Action Add and a Dynamic AS 638 Confed_Edge capability inside. Inside the Dynamic AS 639 Confed_Edge capability the flags are set to: EBGP, Start, 640 AS-in-Use Internal,and Success. 642 2. Node A validates it can change the EBGP session to AS 300 643 to AS 1000, and then sends a capability to confirm the 644 Ack. The capability messages contains sequence number 15, 645 Add Action, Ack flag, and a Dynamic AS Confed_Edge 646 capability inside with flags of: EBGP, Start, AS-in-Use 647 Internal, and Success. Of course, the AS information is 648 AS Confederation 200, As Internal 1000. 650 8. After Node C sends the capability messages to it's internal 651 peers (Node E and Node B), it sends dynamic capabilities to 652 it's external peers: Node D (in the AS confederation) and 653 Node F (in AS 500 external to the AS Confederation.) 655 9. Node D processes C capability message 657 1. Node D receives a capability message from Node C with 658 sequence number 40, Add Action, and Dynamic AS 659 Confed_Edge capability inside. Inside the Dynamic AS 660 Confed_Edge capability the flags are set to: EBGP, Start, 661 AS-in-Use Internal, and Succcess. The AS information is 662 AS Confederation 200 and AS Internal 1000. 664 2. Node D determines it can switch the EBGP Session Node C 665 to AS 1000, the internal AS. It peers with AS 1000 as 666 the AS Confederation, and moves the AS value to 200. 668 3. Node D sends back an capability message with sequence 669 number 40, Add action, and Dynamic AS Confed_Edge 670 capability inside. Inside the Dynamic AS Confed_Edge 671 capability, the flags are set to: EBGP, Start, AS-in-Use 672 Internal and Success. The AS informaiton is AS 673 confederation 200 and AS internal 1000. 675 10. Node F process C's capability message 677 1. Node F receives a capability message from Node C with 678 sequence number 200, Add Action, and Dynamic AS 679 Confed_Edge capability inside. Inside the Dynamic AS 680 Confed_Edge capability the flags are set to: EBGP, Start, 681 AS-in-Use Internal, and Success. The AS information is: 682 AS Confederation 200 and AS Internal 1000. 684 2. Node F determines it can switch the EBGP session with 685 Node C to AS 1000, the internal AS. 687 3. Node F sends back a capability message with sequence 688 number 200, Add Action, and Dynamic AS Confed_Edge 689 capabiliity inside. Inside the Dynamic AS Confeded_Edge 690 capability, the flags are set to: EBGP, Start, AS-in-Use 691 Internal and Success. AGain, the AS information is: AS 692 Confederation 200 and AS internal 100. 694 11. At this point: 696 1. AS 300 has: Node A 698 2. AS 1000 has: Node C, B and E 700 3. AS 200 has Node D as an AS confederation with AS 2000 701 inside. 703 4. AS 2000 has only Node D. 705 5. AS 500 has Node F 707 6. AS 300 peers with AS 1000 709 7. AS 1000 peers with AS 200 (Node D), AS 300 (Node A), and 710 AS 500 (Node F). 712 The two stage commit allows the internal AS one stage to confirm 713 resources with IBGP peers prior to disturbing and E-BGP peers. If an 714 E-BGP peer fails after the IBGP cloud has switched, the single E-BGP 715 peer can be dropped and re-initialized. 717 If there is any local consideration that the AS has split and 718 existing routes may cause a black hole, implementation MAY set the 719 "re-announce all routes now" flag to prevent loops. 721 8. Security Considerations 723 The security of the BGP exchange is optionally secured by the TCP MD5 724 key. 726 Upon discussion with security reviewers, the addition of this feature 727 will neither improve nor detract from the TCP MD5 level of security. 728 The authors considered adding a "cookie" feature to further secure 729 this exchange. Again, review with security experts indicated this 730 "cookie" feature would not improve the security level. 732 The TCP session security will continue across the dynamic BGP peer 733 re-association. The TCP sessions dynamic MD5 re-association or key 734 switch would also allow TCP sessions to continue for a long period. 736 9. IANA Considerations 738 IANA will need to assign the following values: 740 a) Dynamic AS Confederation Edge Open Capability 742 b) Capability Code (1 octet) for the dynamic AS capability 744 Initial testing may be done by taking these codes from the 745 experimental stage. IANA is requested to provide experimental values 746 for both values. 748 10. References 750 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 751 Levels", March 1997, . 753 [2] Redback Networks and Cisco, ""Capability Adverstisement with 754 BGP-4"", November 2002, . 756 [3] Cisco and Cisco, ""Dynamic Capability for BGP-4"", 757 November 2006, . 760 Authors' Addresses 762 Susan Hares 763 Green Hills Software 764 825 Victors Way 765 Ann Arbor, MI 48108 767 Phone: +1-734-222-1610 768 Email: shares@ghs.com 770 Pratik Bose 771 Lockheed 772 700 N Frederick Ave 773 Gaithersburg, MD 20879 775 Phone: +1-301-428-4215 776 Email: pratik.bose@lmco.com 778 Full Copyright Statement 780 Copyright (C) The IETF Trust (2008). 782 This document is subject to the rights, licenses and restrictions 783 contained in BCP 78, and except as set forth therein, the authors 784 retain all their rights. 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 789 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 790 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 791 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Intellectual Property 796 The IETF takes no position regarding the validity or scope of any 797 Intellectual Property Rights or other rights that might be claimed to 798 pertain to the implementation or use of the technology described in 799 this document or the extent to which any license under such rights 800 might or might not be available; nor does it represent that it has 801 made any independent effort to identify any such rights. Information 802 on the procedures with respect to rights in RFC documents can be 803 found in BCP 78 and BCP 79. 805 Copies of IPR disclosures made to the IETF Secretariat and any 806 assurances of licenses to be made available, or the result of an 807 attempt made to obtain a general license or permission for the use of 808 such proprietary rights by implementers or users of this 809 specification can be obtained from the IETF on-line IPR repository at 810 http://www.ietf.org/ipr. 812 The IETF invites any interested party to bring to its attention any 813 copyrights, patents or patent applications, or other proprietary 814 rights that may cover technology that may be required to implement 815 this standard. Please address the information to the IETF at 816 ietf-ipr@ietf.org. 818 Acknowledgment 820 Funding for the RFC Editor function is provided by the IETF 821 Administrative Support Activity (IASA).