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

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/