idnits 2.17.1 draft-chen-idr-rfc4724bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 13 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 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC4724, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 29, 2011) is 4616 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: 'IANA-AFI' is defined on line 594, but no explicit reference was found in the text == Unused Reference: 'IANA-SAFI' is defined on line 596, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-AFI' -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-SAFI' Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force (IETF) S. Sangli 3 Internet Draft E. Chen 4 Intended Status: Standards Track R. Fernando 5 Obsoletes: RFC 4724 (if approved) Cisco Systems 6 Expiration Date: March 1, 2012 J. Scudder 7 Y. Rekhter 8 Juniper Networks 9 August 29, 2011 11 Graceful Restart Mechanism for BGP 13 draft-chen-idr-rfc4724bis-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 This Internet-Draft will expire on March 1, 2012. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Abstract 55 This document describes a mechanism for BGP that would help minimize 56 the negative effects on routing caused by BGP restart. An End-of-RIB 57 marker is specified and can be used to convey routing convergence 58 information. A new BGP capability, termed "Graceful Restart 59 Capability", is defined that would allow a BGP speaker to express its 60 ability to preserve its forwarding state during BGP restart, as well 61 as to convey its intention of generating the End-of-RIB marker upon 62 the completion of its initial routing update. Finally, procedures 63 are outlined for temporarily retaining routing information across a 64 TCP session termination/re-establishment. 66 The mechanisms described in this document are applicable to all 67 routers, both those with the ability to preserve the forwarding state 68 during BGP restart and those without (although the latter need to 69 implement only a subset of the mechanisms described in this 70 document). 72 1. Introduction 74 Usually, when BGP on a router restarts, all the BGP peers detect that 75 the session went down and then came up. This "down/up" transition 76 results in a "routing flap" and causes BGP route re-computation, 77 generation of BGP routing updates, and unnecessary churn to the 78 forwarding tables. It could spread across multiple routing domains. 79 Such routing flaps may create transient forwarding blackholes and/or 80 transient forwarding loops. They also consume resources on the 81 control plane of the routers affected by the flap. As such, they are 82 detrimental to the overall network performance. 84 This document describes a mechanism for BGP that would help minimize 85 the negative effects on routing caused by BGP restart. An End-of-RIB 86 marker is specified and can be used to convey routing convergence 87 information. A new BGP capability, termed "Graceful Restart 88 Capability", is defined that would allow a BGP speaker to express its 89 ability to preserve its forwarding state during BGP restart, as well 90 as to convey its intention of generating the End-of-RIB marker upon 91 the completion of its initial routing update. Finally, procedures 92 are outlined for temporarily retaining routing information across a 93 TCP session termination/re-establishment. 95 1.1. Specification of Requirements 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 99 document are to be interpreted as described in RFC 2119 [RFC2119]. 101 2. Marker for End-of-RIB 103 An UPDATE message with no reachable Network Layer Reachability 104 Information (NLRI) and empty withdrawn NLRI is specified as the End- 105 of-RIB marker that can be used by a BGP speaker to indicate to its 106 peer the completion of the initial routing update after the session 107 is established. For the IPv4 unicast address family, the End-of-RIB 108 marker is an UPDATE message with the minimum length [BGP-4]. For any 109 other address family, it is an UPDATE message that contains only the 110 MP_UNREACH_NLRI attribute [BGP-MP] with no withdrawn routes for that 111 . 113 Although the End-of-RIB marker is specified for the purpose of BGP 114 graceful restart, it is noted that the generation of such a marker 115 upon completion of the initial update would be useful for routing 116 convergence in general, and thus the practice is highly recommended. 118 In addition, it would be beneficial for routing convergence if a BGP 119 speaker can indicate to its peer up-front that it will generate the 120 End-of-RIB marker, regardless of its ability to preserve its 121 forwarding state during BGP restart. This can be accomplished using 122 the Graceful Restart Capability described in the next section. 124 3. Graceful Restart Capability 126 The Graceful Restart Capability is a new BGP capability [BGP-CAP] 127 that can be used by a BGP speaker to indicate its ability to preserve 128 its forwarding state during BGP restart, and to convey its intention 129 of generating the End-of-RIB marker upon the completion of its 130 initial routing update. 132 This capability is defined as follows: 134 Capability code: 64 136 Capability length: variable 138 Capability value: Consists of the "Restart Flags" field, "Restart 139 Time" field, and zero or more tuples as follows: 142 +--------------------------------------------------+ 143 | Restart Flags (4 bits) | 144 +--------------------------------------------------+ 145 | Restart Time in seconds (12 bits) | 146 +--------------------------------------------------+ 147 | Address Family Identifier (16 bits) | 148 +--------------------------------------------------+ 149 | Subsequent Address Family Identifier (8 bits) | 150 +--------------------------------------------------+ 151 | Flags for Address Family (8 bits) | 152 +--------------------------------------------------+ 153 | ... | 154 +--------------------------------------------------+ 155 | Address Family Identifier (16 bits) | 156 +--------------------------------------------------+ 157 | Subsequent Address Family Identifier (8 bits) | 158 +--------------------------------------------------+ 159 | Flags for Address Family (8 bits) | 160 +--------------------------------------------------+ 162 The use and meaning of the fields are as follows: 164 Restart Flags: 166 This field contains bit flags related to restart. 168 0 1 2 3 169 +-+-+-+-+ 170 |R|Resv.| 171 +-+-+-+-+ 173 The most significant bit is defined as the Restart State (R) 174 bit, which can be used to avoid possible deadlock caused by 175 waiting for the End-of-RIB marker when multiple BGP speakers 176 peering with each other restart. When set (value 1), this bit 177 indicates that the BGP speaker has restarted, and its peer MUST 178 NOT wait for the End-of-RIB marker from the speaker before 179 advertising routing information to the speaker. 181 The remaining bits are reserved and MUST be set to zero by the 182 sender and ignored by the receiver. 184 Restart Time: 186 This is the estimated time (in seconds) it will take for the 187 BGP session to be re-established after a restart. This can be 188 used to speed up routing convergence by its peer in case that 189 the BGP speaker does not come back after a restart. 191 Address Family Identifier (AFI), Subsequent Address Family 192 Identifier (SAFI): 194 The AFI and SAFI, taken in combination, indicate that the BGP 195 speaker has the ability to preserve its forwarding state for 196 the address family during a subsequent BGP restart. Routes may 197 be explicitly associated with a particular AFI and SAFI using 198 the encoding of [BGP-MP] or implicitly associated with 199 if using the encoding of [BGP-4]. 201 Flags for Address Family: 203 This field contains bit flags relating to routes that were 204 advertised with the given AFI and SAFI. 206 0 1 2 3 4 5 6 7 207 +-+-+-+-+-+-+-+-+ 208 |F| Reserved | 209 +-+-+-+-+-+-+-+-+ 211 The most significant bit is defined as the Forwarding State (F) 212 bit, which can be used to indicate whether the forwarding state 213 for routes that were advertised with the given AFI and SAFI has 214 indeed been preserved during the previous BGP restart. When 215 set (value 1), the bit indicates that the forwarding state has 216 been preserved. 218 The remaining bits are reserved and MUST be set to zero by the 219 sender and ignored by the receiver. 221 When a sender of this capability does not include any in 222 the capability, it means that the sender is not capable of preserving 223 its forwarding state during BGP restart. It also indicates that the 224 sender will generate the End-of-RIB marker upon the completion of its 225 initial routing update. In that case, the value of the "Restart 226 Time" field advertised by the sender is irrelevant. 228 A BGP speaker MUST NOT include more than one instance of the Graceful 229 Restart Capability in the capability advertisement [BGP-CAP]. If 230 more than one instance of the Graceful Restart Capability is carried 231 in the capability advertisement, the receiver of the advertisement 232 MUST ignore all but the last instance of the Graceful Restart 233 Capability. 235 Including in the Graceful Restart Capability 236 does not imply that the IPv4 unicast routing information should be 237 carried by using the BGP multiprotocol extensions [BGP-MP] -- it 238 could be carried in the NLRI field of the BGP UPDATE message. 240 4. Operation 242 A BGP speaker SHOULD advertise the Graceful Restart Capability to 243 indicate its intention of generating the End-of-RIB marker upon the 244 completion of its initial routing update. The of an 245 address family SHOULD be included in the capability if the speaker 246 has the ability to preserve its forwarding state for the address 247 family during a subsequent BGP restart. 249 A BGP speaker that has advertised the Graceful Restart Capability 250 (with or without any in the advertised capability) MUST 251 send the End-of-RIB marker to its peer once it completes its initial 252 routing update (including the case when there is no update to send) 253 for an address family after the BGP session is established. 255 It is noted that the normal BGP procedures MUST be followed when the 256 TCP session terminates due to the sending or receiving of a BGP 257 NOTIFICATION message. 259 A suggested default for the Restart Time is a value less than or 260 equal to the HOLDTIME carried in the OPEN. 262 In the following sections, "Restarting Speaker" refers to a router 263 whose BGP has restarted, and "Receiving Speaker" refers to a router 264 that peers with the restarting speaker. 266 Consider that the Graceful Restart Capability for an address family 267 is advertised by the Restarting Speaker, and is understood by the 268 Receiving Speaker, and a BGP session between them is established. 269 The following sections detail the procedures to be followed by the 270 Restarting Speaker as well as the Receiving Speaker once the 271 Restarting Speaker restarts. 273 4.1. Procedures for the Restarting Speaker 275 When the Restarting Speaker restarts, it MUST retain, if possible, 276 the forwarding state for the BGP routes in the Loc-RIB and MUST mark 277 them as stale. It MUST NOT differentiate between stale and other 278 information during forwarding. 280 To re-establish the session with its peer, the Restarting Speaker 281 MUST set the "Restart State" bit in the Graceful Restart Capability 282 of the OPEN message. Unless allowed via configuration, the 283 "Forwarding State" bit for an address family in the capability can be 284 set only if the forwarding state has indeed been preserved for that 285 address family during the restart. 287 Once the session between the Restarting Speaker and the Receiving 288 Speaker is re-established, the Restarting Speaker will receive and 289 process BGP messages from its peers. However, it MUST defer route 290 selection for an address family until it either (a) receives the End- 291 of-RIB marker from all its peers (excluding the ones with the 292 "Restart State" bit set in the received capability and excluding the 293 ones that do not advertise the Graceful Restart Capability) or (b) 294 the Selection_Deferral_Timer referred to below has expired. It is 295 noted that prior to route selection, the speaker has no routes to 296 advertise to its peers and no routes to update the forwarding state. 298 In situations where both Interior Gateway Protocol (IGP) and BGP have 299 restarted, it might be advantageous to wait for IGP to converge 300 before the BGP speaker performs route selection. 302 After the BGP speaker performs route selection, the forwarding state 303 of the speaker MUST be updated and any previously marked stale 304 information MUST be removed. The Adj-RIB-Out can then be advertised 305 to its peers. Once the initial update is complete for an address 306 family (including the case that there is no routing update to send), 307 the End-of-RIB marker MUST be sent. 309 To put an upper bound on the amount of time a router defers its route 310 selection, an implementation MUST support a (configurable) timer that 311 imposes this upper bound. This timer is referred to as the 312 "Selection_Deferral_Timer". The value of this timer should be large 313 enough, so as to provide all the peers of the Restarting Speaker with 314 enough time to send all the routes to the Restarting Speaker. 316 If one wants to apply graceful restart only when the restart is 317 planned (as opposed to both planned and unplanned restart), then one 318 way to accomplish this would be to set the Forwarding State bit to 1 319 after a planned restart, and to 0 in all other cases. Other 320 approaches to accomplish this are outside the scope of this document. 322 4.2. Procedures for the Receiving Speaker 324 When the Restarting Speaker restarts, the Receiving Speaker may or 325 may not detect the termination of the TCP session with the Restarting 326 Speaker, depending on the underlying TCP implementation, whether or 327 not [BGP-AUTH] is in use, and the specific circumstances of the 328 restart. In case it does not detect the termination of the old TCP 329 session and still considers the BGP session as being established, it 330 MUST treat the subsequent open connection from the peer as an 331 indication of the termination of the old TCP session and act 332 accordingly (when the Graceful Restart Capability has been received 333 from the peer). See Section 8 for a description of this behavior in 334 terms of the BGP finite state machine. 336 "Acting accordingly" in this context means that the previous TCP 337 session MUST be closed, and the new one retained. Note that this 338 behavior differs from the default behavior, as specified in [BGP-4], 339 Section 6.8. Since the previous connection is considered to be 340 terminated, no NOTIFICATION message should be sent -- the previous 341 TCP session is simply closed. 343 When the Receiving Speaker detects termination of the TCP session for 344 a BGP session with a peer that has advertised the Graceful Restart 345 Capability, unless overridden by configuration, it MUST retain the 346 routes received from the peer for all the address families that were 347 previously received in the Graceful Restart Capability and MUST mark 348 them as stale routing information. To deal with possible consecutive 349 restarts, a route (from the peer) previously marked as stale MUST be 350 deleted. The router MUST NOT differentiate between stale and other 351 routing information during forwarding. 353 In re-establishing the session, the "Restart State" bit in the 354 Graceful Restart Capability of the OPEN message sent by the Receiving 355 Speaker MUST NOT be set unless the Receiving Speaker has restarted. 356 The presence and the setting of the "Forwarding State" bit for an 357 address family depend upon the actual forwarding state and 358 configuration. 360 If the session does not get re-established within the "Restart Time" 361 that the peer advertised previously, the Receiving Speaker MUST 362 delete all the stale routes from the peer that it is retaining. 364 A BGP speaker could have some way of determining whether its peer's 365 forwarding state is still viable, for example through Bidirectional 366 Forwarding Detection [BFD] or through monitoring layer two 367 information. Specifics of such mechanisms are beyond the scope of 368 this document. In the event that it determines that its peer's 369 forwarding state is not viable prior to the re-establishment of the 370 session, the speaker MAY delete all the stale routes from the peer 371 that it is retaining. 373 Once the session is re-established, if the "Forwarding State" bit for 374 a specific address family is not set in the newly received Graceful 375 Restart Capability, or if a specific address family is not included 376 in the newly received Graceful Restart Capability, or if the Graceful 377 Restart Capability is not received in the re-established session at 378 all, then the Receiving Speaker MUST immediately remove all the stale 379 routes from the peer that it is retaining for that address family. 381 The Receiving Speaker MUST replace the stale routes by the routing 382 updates received from the peer. Once the End-of-RIB marker for an 383 address family is received from the peer, it MUST immediately remove 384 any routes from the peer that are still marked as stale for that 385 address family. 387 To put an upper bound on the amount of time a router retains the 388 stale routes, an implementation MAY support a (configurable) timer 389 that imposes this upper bound. 391 5. Changes to BGP Finite State Machine 393 As mentioned under "Procedures for the Receiving Speaker" above, this 394 specification modifies the BGP finite state machine. 396 The specific state machine modifications to [BGP-4], Section 8.2.2, 397 are as follows. 399 In the Idle state, make the following changes. 401 Replace this text: 403 - initializes all BGP resources for the peer connection, 405 with 407 - initializes all BGP resources for the peer connection, other 408 than those resources required in order to retain routes 409 according to section "Procedures for the Receiving Speaker" of 410 this (Graceful Restart) specification, 412 In the Established state, make the following changes. 414 Replace this text: 416 In response to an indication that the TCP connection is 417 successfully established (Event 16 or Event 17), the second 418 connection SHALL be tracked until it sends an OPEN message. 420 with 422 If the Graceful Restart Capability with one or more AFIs/SAFIs 423 has not been received for the session, then in response to an 424 indication that a TCP connection is successfully established 425 (Event 16 or Event 17), the second connection SHALL be tracked 426 until it sends an OPEN message. 428 However, if the Graceful Restart Capability with one or more 429 AFIs/SAFIs has been received for the session, then in response 430 to Event 16 or Event 17 the local system: 432 - retains all routes associated with this connection according 433 to section "Procedures for the Receiving Speaker" of this 434 (Graceful Restart) specification, 436 - releases all other BGP resources, 438 - drops the TCP connection associated with the ESTABLISHED 439 session, 441 - initializes all BGP resources for the peer connection, other 442 than those required in order to retain routes according to 443 section "Procedures for the Receiving Speaker" of this 444 specification, 446 - sets ConnectRetryCounter to zero, 448 - starts the ConnectRetryTimer with the initial value, and 450 - changes its state to Connect. 452 Replace this text: 454 If the local system receives a NOTIFICATION message (Event 24 or 455 Event 25), or a TcpConnectionFails (Event 18) from the underlying 456 TCP, the local system: 458 - sets the ConnectRetryTimer to zero, 460 - deletes all routes associated with this connection, 462 - releases all the BGP resources, 464 - drops the TCP connection, 466 - increments the ConnectRetryCounter by 1, 468 - changes its state to Idle. 470 with 472 If the local system receives a NOTIFICATION message (Event 24 or 473 Event 25), or if the local system receives a TcpConnectionFails 474 (Event 18) from the underlying TCP and the Graceful Restart 475 Capability with one or more AFIs/SAFIs has not been received for 476 the session, the local system: 478 - sets the ConnectRetryTimer to zero, 480 - deletes all routes associated with this connection, 482 - releases all the BGP resources, 484 - drops the TCP connection, 486 - increments the ConnectRetryCounter by 1, and 488 - changes its state to Idle. 490 However, if the local system receives a TcpConnectionFails (Event 491 18) from the underlying TCP, and the Graceful Restart Capability 492 with one or more AFIs/SAFIs has been received for the session, the 493 local system: 495 - sets the ConnectRetryTimer to zero, 497 - retains all routes associated with this connection according 498 to section "Procedures for the Receiving Speaker" of this 499 (Graceful Restart) specification, 501 - releases all other BGP resources, 503 - drops the TCP connection, 505 - increments the ConnectRetryCounter by 1, and 507 - changes its state to Idle. 509 6. Deployment Considerations 511 Although the procedures described in this document would help 512 minimize the effect of routing flaps, it is noted that when a BGP 513 Graceful Restart-capable router restarts, or if it restarts without 514 preserving its forwarding state (e.g., due to a power failure), there 515 is a potential for transient routing loops or blackholes in the 516 network if routing information changes before the involved routers 517 complete routing updates and convergence. Also, depending on the 518 network topology, if not all IBGP speakers are Graceful Restart 519 capable, there could be an increased exposure to transient routing 520 loops or blackholes when the Graceful Restart procedures are 521 exercised. 523 The Restart Time, the upper bound for retaining routes, and the upper 524 bound for deferring route selection may need to be tuned as more 525 deployment experience is gained. 527 Finally, it is noted that the benefits of deploying BGP Graceful 528 Restart in an Autonomous System (AS) whose IGPs and BGP are tightly 529 coupled (i.e., BGP and IGPs would both restart) and IGPs have no 530 similar Graceful Restart Capability are reduced relative to the 531 scenario where IGPs do have similar Graceful Restart Capability. 533 7. Security Considerations 535 Since with this proposal a new connection can cause an old one to be 536 terminated, it might seem to open the door to denial of service 537 attacks. However, it is noted that unauthenticated BGP is already 538 known to be vulnerable to denials of service through attacks on the 539 TCP transport. The TCP transport is commonly protected through use 540 of [BGP-AUTH]. Such authentication will equally protect against 541 denials of service through spurious new connections. 543 If an attacker is able to successfully open a TCP connection 544 impersonating a legitimate peer, the attacker's connection will 545 replace the legitimate one, potentially enabling the attacker to 546 advertise bogus routes. We note, however, that the window for such a 547 route insertion attack is small since through normal operation of the 548 protocol the legitimate peer would open a new connection, in turn 549 causing the attacker's connection to be terminated. Thus, this 550 attack devolves to a form of denial of service. 552 It is thus concluded that this proposal does not change the 553 underlying security model (and issues) of BGP-4. 555 We also note that implementations may allow use of graceful restart 556 to be controlled by configuration. If graceful restart is not 557 enabled, naturally the underlying security model of BGP-4 is 558 unchanged. 560 8. Acknowledgments 562 The authors would like to thank Bruce Cole, Jie Dong, Lars Eggert, 563 Bill Fenner, Eric Gray, Jeffrey Haas, Sam Hartman, Jakob Heitz, Keyur 564 Patel, Robert Raszuk, Alvaro Retana, Pekka Savola Naiming Shen, 565 Satinder Singh, Mark Townsley, David Ward, Shane Wright, and Alex 566 Zinin for their review and comments. 568 9. IANA Considerations 570 This document defines a new BGP capability - Graceful Restart 571 Capability. The Capability Code for Graceful Restart Capability is 572 64. 574 10. References 576 10.1. Normative References 578 [BGP-4] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 579 Protocol 4 (BGP-4)", RFC 4271, January 2006. 581 [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., 582 "Multiprotocol Extensions for BGP-4", RFC 4760, 583 January 2007. 585 [BGP-CAP] Scudder, J., and Chandra, R., "Capabilities Advertisement 586 with BGP-4", RFC 5492, February 2009. 588 [BGP-AUTH] Touch, J., A. Mankin, and R. Bonica, "The TCP 589 Authentication Option", RFC 5925, June 2010. 591 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 592 Requirement Levels", BCP 14, RFC 2119, March 1997. 594 [IANA-AFI] http://www.iana.org/assignments/address-family-numbers 596 [IANA-SAFI] http://www.iana.org/assignments/safi-namespace 598 10.2. Informative References 600 [BFD] Katz, D. and D. Ward, "Bidirectional Forwarding 601 Detection", RFC 5880, June 2010. 603 Appendix A. Comparison with RFC 4724 605 Several inconsistencies and ambiguities are addressed. 607 11. Authors' Addresses 609 Srihari R. Sangli 610 Cisco Systems, Inc. 612 EMail: rsrihari@cisco.com 614 Yakov Rekhter 615 Juniper Networks, Inc. 617 EMail: yakov@juniper.net 619 Rex Fernando 620 Cisco Systems, Inc. 622 EMail: rex@cisco.com 624 John G. Scudder 625 Juniper Networks, Inc. 627 EMail: jgs@juniper.net 629 Enke Chen 630 Cisco Systems, Inc. 632 EMail: enkechen@cisco.com