draft-ietf-idr-restart-04.txt   draft-ietf-idr-restart-05.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: December 2002 Rex Fernando (Procket Networks) Expiration Date: December 2002 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-04.txt draft-ietf-idr-restart-05.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 2, line 5 skipping to change at page 1, line 45
This document proposes a mechanism for BGP that would help minimize This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence marker is specified and can be used to convey routing convergence
information. A new BGP capability, termed "Graceful Restart information. A new BGP capability, termed "Graceful Restart
Capability", is defined which would allow a BGP speaker to express Capability", is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally, its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information procedures are outlined for temporarily retaining routing information
across a TCP transport reset. across a TCP transport reset.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).
3. Introduction 3. Introduction
Usually when BGP on a router restarts, all the BGP peers detect that Usually when BGP on a router restarts, all the BGP peers detect that
the session went down, and then came up. This "down/up" transition the session went down, and then came up. This "down/up" transition
results in a "routing flap" and causes BGP route re-computation, results in a "routing flap" and causes BGP route re-computation,
generation of BGP routing updates and flap the forwarding tables. It generation of BGP routing updates and flap the forwarding tables. It
could spread across multiple routing domains. Such routing flaps may could spread across multiple routing domains. Such routing flaps may
create transient forwarding blackholes and/or transient forwarding create transient forwarding blackholes and/or transient forwarding
loops. They also consume resources on the control plane of the loops. They also consume resources on the control plane of the
routers affected by the flap. As such they are detrimental to the routers affected by the flap. As such they are detrimental to the
skipping to change at page 5, line 7 skipping to change at page 5, line 7
bit which can be used to indicate if the forwarding state for bit which can be used to indicate if the forwarding state for
the <AFI, SAFI> has indeed been preserved during the previous the <AFI, SAFI> has indeed been preserved during the previous
BGP restart. When set (value 1), the bit indicates that the BGP restart. When set (value 1), the bit indicates that the
forwarding state has been preserved. forwarding state has been preserved.
The remaining bits are reserved, and should be set to zero by The remaining bits are reserved, and should be set to zero by
the sender and ignored by the receiver. the sender and ignored by the receiver.
When a sender of this capability doesn't include any <AFI, SAFI> in When a sender of this capability doesn't include any <AFI, SAFI> in
the capability, it means that the sender is not capable of preserving the capability, it means that the sender is not capable of preserving
its forwarding state during BGP restart, but is going to generate the its forwarding state during BGP restart, but supports procedures for
End-of-RIB marker upon the completion of its initial routing updates. the Receiving Speaker (as defined in Section 6.2 of this document).
The value of the "Restart Time" field is irrelevant in that case. In that case the value of the "Restart Time" field advertised by the
sender is irrelevant.
A BGP speaker should not include more than one instance of the A BGP speaker should not include more than one instance of the
Graceful Restart Capability in the capability advertisement [BGP- Graceful Restart Capability in the capability advertisement [BGP-
CAP]. If more than one instance of the Graceful Restart Capability CAP]. If more than one instance of the Graceful Restart Capability
is carried in the capability advertisement, the receiver of the is carried in the capability advertisement, the receiver of the
advertisement should ignore all but the last instance of the Graceful advertisement should ignore all but the last instance of the Graceful
Restart Capability. Restart Capability.
Including <AFI=IPv4, SAFI=unicast> into the Graceful Restart Including <AFI=IPv4, SAFI=unicast> into the Graceful Restart
Capability doesn't imply that the IPv4 unicast routing information Capability doesn't imply that the IPv4 unicast routing information
skipping to change at page 5, line 31 skipping to change at page 5, line 32
- it could be carried in the NLRI field of the BGP UPDATE message. - it could be carried in the NLRI field of the BGP UPDATE message.
6. Operation 6. Operation
A BGP speaker may advertise the Graceful Restart Capability for an A BGP speaker may advertise the Graceful Restart Capability for an
address family to its peer if it has the ability to preserve its address family to its peer if it has the ability to preserve its
forwarding state for the address family when BGP restarts. In forwarding state for the address family when BGP restarts. In
addition, even if the speaker does not have the ability to preserve addition, even if the speaker does not have the ability to preserve
its forwarding state for any address family during BGP restart, it is its forwarding state for any address family during BGP restart, it is
still recommended that the speaker advertise the Graceful Restart still recommended that the speaker advertise the Graceful Restart
Capability to its peer to indicate its intention of generating the Capability to its peer (as mentioned before this is done by not
End-of-RIB marker upon the completion of its initial routing updates including any <AFI, SAFI> in the advertised capability). There are
(as mentioned before this is done by not including any <AFI, SAFI> in two reasons for doing this. First, to indicate its intention of
the advertised capability), as doing this would be useful for routing generating the End-of-RIB marker upon the completion of its initial
convergence in general. routing updates, as doing this would be useful for routing
convergence in general. Second, to indicate its support for a peer
which wishes to perform a graceful restart.
The End-of-RIB marker should be sent by a BGP speaker to its peer The End-of-RIB marker should be sent by a BGP speaker to its peer
once it completes the initial routing update (including the case when once it completes the initial routing update (including the case when
there is no update to send) for an address family after the BGP there is no update to send) for an address family after the BGP
session is established. session is established.
It is noted that the normal BGP procedures must be followed when the It is noted that the normal BGP procedures must be followed when the
TCP session terminates due to the sending or receiving of a BGP TCP session terminates due to the sending or receiving of a BGP
NOTIFICATION message. NOTIFICATION message.
skipping to change at page 9, line 24 skipping to change at page 9, line 24
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.
9. Acknowledgments 9. 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.
10. References 10. Normative References
[BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP- [BGP-4] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-
4)", RFC 1771, March 1995. 4)", RFC 1771, March 1995.
[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.
 End of changes. 

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