--- 1/draft-ietf-idr-restart-09.txt 2006-02-04 23:31:26.000000000 +0100 +++ 2/draft-ietf-idr-restart-10.txt 2006-02-04 23:31:26.000000000 +0100 @@ -1,19 +1,20 @@ + Network Working Group Srihari R. Sangli (Procket Networks) Internet Draft Yakov Rekhter (Juniper Networks) -Expiration Date: October 2004 Rex Fernando (Procket Networks) +Expiration Date: December 2004 Rex Fernando (Procket Networks) John G. Scudder (Cisco Systems) Enke Chen (Redback Networks) Graceful Restart Mechanism for BGP - draft-ietf-idr-restart-09.txt + draft-ietf-idr-restart-10.txt 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -299,21 +300,22 @@ 7.2. Procedures for the Receiving Speaker When the Restarting Speaker restarts, the Receiving Speaker may or may not detect the termination of the TCP session with the Restarting Speaker, depending on the underlying TCP implementation, whether or not [BGP-AUTH] is in use, and the specific circumstances of the restart. In case it does not detect the TCP reset and still considers the BGP session as being established, it SHALL treat the subsequent open connection from the peer as an indication of TCP reset and act accordingly (when the Graceful Restart Capability has - been received from the peer). + been received from the peer). See Section 8 for a description of this + behavior in terms of the BGP finite state machine. "Acting accordingly" in this context means that the previous TCP session SHOULD be closed, and the new one retained. Note that this behavior differs from the default behavior, as specified in [BGP-4] section 6.8. Since the previous connection is considered to be reset, no NOTIFICATION message should be sent -- the previous TCP session is simply closed. When the Receiving Speaker detects TCP reset for a BGP session with a peer that has advertised the Graceful Restart Capability, it SHALL @@ -351,21 +352,53 @@ The Receiving Speaker SHALL replace the stale routes by the routing updates received from the peer. Once the End-of-RIB marker for an address family is received from the peer, it SHALL immediately remove any routes from the peer that are still marked as stale for that address family. To put an upper bound on the amount of time a router retains the stale routes, an implementation MAY support a (configurable) timer that imposes this upper bound. -8. Deployment Considerations +8. Changes to BGP Finite State Machine + + As mentioned under "Procedures for the Receiving Speaker" above, this + specification modifies the BGP finite state machine. + + The specific state machine modifications to [BGP-4] Section 8.2.2 are + as follows. In the Established state, replace this text: + + If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is + received, or a TcpConnectionConfirmed event (Event 17) is + received, a second TCP connection may be in progress. This second + TCP connection is tracked per Connection Collision processing + (Section 6.8) until an OPEN message is received. + + with this: + + If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is + received, a second TCP connection may be in progress. This second + TCP connection is tracked per Connection Collision processing + (Section 6.8) until an OPEN message is received. + + If the Graceful Restart capability with one or more AFI/SAFI has + been received for the session, then TcpConnectionConfirmed (Event + 17) is treated as TcpConnectionFails (Event 18). + + If a TcpConnectionConfirmed event (Event 17) is received and if + the Graceful Restart capability with one or more AFI/SAFI has not + been received for the session, a second TCP connection may be in + progress. This second TCP connection is tracked per Connection + Collision processing (Section 6.8) until an OPEN message is + received. + +9. Deployment Considerations While the procedures described in this document would help minimize the effect of routing flaps, it is noted, however, that when a BGP Graceful Restart capable router restarts, there is a potential for transient routing loops or blackholes in the network if routing information changes before the involved routers complete routing updates and convergence. Also, depending on the network topology, if not all IBGP speakers are Graceful Restart capable, there could be an increased exposure to transient routing loops or blackholes when the Graceful Restart procedures are exercised. @@ -373,61 +406,61 @@ The Restart Time, the upper bound for retaining routes and the upper bound for deferring route selection may need to be tuned as more deployment experience is gained. Finally, it is noted that the benefits of deploying BGP Graceful Restart in an AS whose IGPs and BGP are tightly coupled (i.e., BGP and IGPs would both restart) and IGPs have no similar Graceful Restart capability are reduced relative to the scenario where IGPs do have similar Graceful Restart capability. -9. Security Considerations +10. Security Considerations Since with this proposal a new connection can cause an old one to be terminated, it might seem to open the door to denial of service attacks. However, it is noted that unauthenticated BGP is already known to be vulnerable to denials of service through attacks on the TCP transport. The TCP transport is commonly protected through use of [BGP-AUTH]. Such authentication will equally protect against denials of service through spurious new connections. It is thus concluded that this proposal does not change the underlying security model (and issues) of BGP-4. -10. Acknowledgments +11. Acknowledgments The authors would like to thank Bruce Cole, Bill Fenner, Eric Gray Jeffrey Haas, Alvaro Retana, Naiming Shen, Satinder Singh, David Ward, Shane Wright and Alex Zinin for their review and comments. -11. Normative References +12. Normative References - [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- - 4)", RFC 1771, March 1995. + [BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4 + (BGP- 4)", work in progress. [BGP-MP] Bates, T., Chandra, R., Katz, D., and Rekhter, Y., "Multiprotocol Extensions for BGP-4", RFC2858, June 2000. [BGP-CAP] Chandra, R., Scudder, J., "Capabilities Advertisement with BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. [BGP-AUTH] Heffernan A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [IANA-AFI] http://www.iana.org/assignments/address-family-numbers. [IANA-SAFI] http://www.iana.org/assignments/safi-namespace. -12. Author Information +13. Author Information Srihari R. Sangli Procket Networks, Inc. 1100 Cadillac Court Milpitas, CA 95035 e-mail: srihari@procket.com Yakov Rekhter Juniper Networks, Inc. 1194 N. Mathilda Avenue