draft-ietf-idr-restart-12.txt   draft-ietf-idr-restart-13.txt 
Network Working Group Srihari R. Sangli Network Working Group Srihari R. Sangli
Internet Draft Yakov Rekhter Internet Draft Yakov Rekhter
Expiration Date: December 2006 Rex Fernando Expiration Date: January 2007 Rex Fernando
John G. Scudder John G. Scudder
Enke Chen Enke Chen
Graceful Restart Mechanism for BGP Graceful Restart Mechanism for BGP
draft-ietf-idr-restart-12.txt draft-ietf-idr-restart-13.txt
Status of this Memo Status of this Memo
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
skipping to change at line 46 skipping to change at line 46
Abstract Abstract
This document describes a mechanism for BGP that would help minimize This document describes 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 session termination/re-establishment.
The mechanisms described in this document are applicable to all The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this implement only a subset of the mechanisms described in this
document). document).
1. Specification of Requirements 1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at line 79 skipping to change at line 79
routers affected by the flap. As such they are detrimental to the routers affected by the flap. As such they are detrimental to the
overall network performance. overall network performance.
This document describes a mechanism for BGP that would help minimize This document describes 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 session termination/re-establishment.
3. Marker for End-of-RIB 3. Marker for End-of-RIB
An UPDATE message with no reachable NLRI and empty withdrawn NLRI is An UPDATE message with no reachable NLRI and empty withdrawn NLRI is
specified as the End-Of-RIB Marker that can be used by a BGP speaker specified as the End-Of-RIB Marker that can be used by a BGP speaker
to indicate to its peer the completion of the initial routing update to indicate to its peer the completion of the initial routing update
after the session is established. For IPv4 unicast address family, after the session is established. For IPv4 unicast address family,
the End-Of-RIB Marker is an UPDATE message with the minimum length the End-Of-RIB Marker is an UPDATE message with the minimum length
[BGP-4]. For any other address family, it is an UPDATE message that [BGP-4]. For any other address family, it is an UPDATE message that
contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no contains only the MP_UNREACH_NLRI attribute [BGP-MP] with no
skipping to change at line 118 skipping to change at line 118
convey to its peer its intention of generating the End-Of-RIB marker convey to its peer its intention of generating the End-Of-RIB marker
upon the completion of its initial routing updates. upon the completion of its initial routing updates.
This capability is defined as follows: This capability is defined as follows:
Capability code: 64 Capability code: 64
Capability length: variable Capability length: variable
Capability value: Consists of the "Restart Flags" field, "Restart Capability value: Consists of the "Restart Flags" field, "Restart
Time" field, and zero or more of the tuples <AFI, SAFI, Flags for Time" field, and 0 to 63 of the tuples <AFI, SAFI, Flags for
address family> as follows: address family> as follows:
+--------------------------------------------------+ +--------------------------------------------------+
| Restart Flags (4 bits) | | Restart Flags (4 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Restart Time in seconds (12 bits) | | Restart Time in seconds (12 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Address Family Identifier (16 bits) | | Address Family Identifier (16 bits) |
+--------------------------------------------------+ +--------------------------------------------------+
| Subsequent Address Family Identifier (8 bits) | | Subsequent Address Family Identifier (8 bits) |
skipping to change at line 156 skipping to change at line 156
0 1 2 3 0 1 2 3
+-+-+-+-+ +-+-+-+-+
|R|Resv.| |R|Resv.|
+-+-+-+-+ +-+-+-+-+
The most significant bit is defined as the Restart State (R) The most significant bit is defined as the Restart State (R)
bit which can be used to avoid possible deadlock caused by bit which can be used to avoid possible deadlock caused by
waiting for the End-of-RIB marker when multiple BGP speakers waiting for the End-of-RIB marker when multiple BGP speakers
peering with each other restart. When set (value 1), this bit peering with each other restart. When set (value 1), this bit
indicates that the BGP speaker has restarted, and its peer indicates that the BGP speaker has restarted, and its peer MUST
SHOULD NOT wait for the End-of-RIB marker from the speaker NOT wait for the End-of-RIB marker from the speaker before
before advertising routing information to the speaker. advertising routing information to the speaker.
The remaining bits are reserved, and SHOULD be set to zero by The remaining bits are reserved, and MUST be set to zero by the
the sender and ignored by the receiver. sender and ignored by the receiver.
Restart Time: Restart Time:
This is the estimated time (in seconds) it will take for the This is the estimated time (in seconds) it will take for the
BGP session to be re-established after a restart. This can be BGP session to be re-established after a restart. This can be
used to speed up routing convergence by its peer in case that used to speed up routing convergence by its peer in case that
the BGP speaker does not come back after a restart. the BGP speaker does not come back after a restart.
Address Family Identifier (AFI): Address Family Identifier (AFI):
skipping to change at line 198 skipping to change at line 198
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|F| Reserved | |F| Reserved |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
The most significant bit is defined as the Forwarding State (F) The most significant bit is defined as the Forwarding State (F)
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 MUST be set to zero by the
the sender and ignored by the receiver. 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 supports procedures for its forwarding state during BGP restart, but supports procedures for
the Receiving Speaker (as defined in Section 5.2 of this document). the Receiving Speaker (as defined in Section 5.2 of this document).
In that case the value of the "Restart Time" field advertised by the In that case the value of the "Restart Time" field advertised by the
sender is irrelevant. sender is irrelevant.
A BGP speaker SHOULD NOT include more than one instance of the A BGP speaker MUST NOT include more than one instance of the Graceful
Graceful Restart Capability in the capability advertisement [BGP- Restart Capability in the capability advertisement [BGP-CAP]. If
CAP]. If more than one instance of the Graceful Restart Capability more than one instance of the Graceful Restart Capability is carried
is carried in the capability advertisement, the receiver of the in the capability advertisement, the receiver of the advertisement
advertisement SHOULD ignore all but the last instance of the Graceful MUST ignore all but the last instance of the Graceful Restart
Restart Capability. 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
should be carried by using the BGP Multiprotocol extensions [BGP-MP] should be carried by using the BGP Multiprotocol extensions [BGP-MP]
- 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.
5. Operation 5. 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
skipping to change at line 236 skipping to change at line 236
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 (as mentioned before this is done by not Capability to its peer (as mentioned before this is done by not
including any <AFI, SAFI> in the advertised capability). There are including any <AFI, SAFI> in the advertised capability). There are
two reasons for doing this. First, to indicate its intention of two reasons for doing this. First, to indicate its intention of
generating the End-of-RIB marker upon the completion of its initial generating the End-of-RIB marker upon the completion of its initial
routing updates, as doing this would be useful for routing routing updates, as doing this would be useful for routing
convergence in general. Second, to indicate its support for a peer convergence in general. Second, to indicate its support for a peer
which wishes to perform a graceful restart. 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 MUST be sent by a BGP speaker to its peer once
once it completes the initial routing update (including the case when 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.
A suggested default for the Restart Time is a value less than or A suggested default for the Restart Time is a value less than or
equal to the HOLDTIME carried in the OPEN. equal to the HOLDTIME carried in the OPEN.
In the following sections, "Restarting Speaker" refers to a router In the following sections, "Restarting Speaker" refers to a router
whose BGP has restarted, and "Receiving Speaker" refers to a router whose BGP has restarted, and "Receiving Speaker" refers to a router
that peers with the restarting speaker. that peers with the restarting speaker.
Consider that the Graceful Restart Capability for an address family Consider that the Graceful Restart Capability for an address family
is advertised by the Restarting Speaker, and is understood by the is advertised by the Restarting Speaker, and is understood by the
Receiving Speaker, and a BGP session between them is established. Receiving Speaker, and a BGP session between them is established.
The following sections detail the procedures that SHALL be followed The following sections detail the procedures that MUST be followed by
by the Restarting Speaker as well as the Receiving Speaker once the the Restarting Speaker as well as the Receiving Speaker once the
Restarting Speaker restarts. Restarting Speaker restarts.
5.1. Procedures for the Restarting Speaker 5.1. Procedures for the Restarting Speaker
When the Restarting Speaker restarts, it SHOULD retain, if possible, When the Restarting Speaker restarts, it MUST retain, if possible,
the forwarding state for the BGP routes in the Loc-RIB, and SHALL the forwarding state for the BGP routes in the Loc-RIB, and MUST mark
mark them as stale. It SHOULD NOT differentiate between stale and them as stale. It MUST NOT differentiate between stale and other
other information during forwarding. information during forwarding.
To re-establish the session with its peer, the Restarting Speaker To re-establish the session with its peer, the Restarting Speaker
MUST set the "Restart State" bit in the Graceful Restart Capability MUST set the "Restart State" bit in the Graceful Restart Capability
of the OPEN message. Unless allowed via configuration, the of the OPEN message. Unless allowed via configuration, the
"Forwarding State" bit for an address family in the capability can be "Forwarding State" bit for an address family in the capability can be
set only if the forwarding state has indeed been preserved for that set only if the forwarding state has indeed been preserved for that
address family during the restart. address family during the restart.
Once the session between the Restarting Speaker and the Receiving Once the session between the Restarting Speaker and the Receiving
Speaker is re-established, the Restarting Speaker will receive and Speaker is re-established, the Restarting Speaker will receive and
process BGP messages from its peers. However, it SHALL defer route process BGP messages from its peers. However, it MUST defer route
selection for an address family until it either (a) receives the End- selection for an address family until it either (a) receives the End-
of-RIB marker from all its peers (excluding the ones with the of-RIB marker from all its peers (excluding the ones with the
"Restart State" bit set in the received capability and excluding the "Restart State" bit set in the received capability and excluding the
ones which do not advertise the graceful restart capability) or (b) ones which do not advertise the graceful restart capability) or (b)
the Selection_Deferral_Timer referred to below has expired. It is the Selection_Deferral_Timer referred to below has expired. It is
noted that prior to route selection, the speaker has no routes to noted that prior to route selection, the speaker has no routes to
advertise to its peers and no routes to update the forwarding state. advertise to its peers and no routes to update the forwarding state.
In situations where both IGP and BGP have restarted, it might be In situations where both IGP and BGP have restarted, it might be
advantageous to wait for IGP to converge before the BGP speaker advantageous to wait for IGP to converge before the BGP speaker
performs route selection. performs route selection.
After the BGP speaker performs route selection, the forwarding state After the BGP speaker performs route selection, the forwarding state
of the speaker SHALL be updated and any previously marked stale of the speaker MUST be updated and any previously marked stale
information SHALL be removed. The Adj-RIB-Out can then be advertised information MUST be removed. The Adj-RIB-Out can then be advertised
to its peers. Once the initial update is complete for an address to its peers. Once the initial update is complete for an address
family (including the case that there is no routing update to send), family (including the case that there is no routing update to send),
the End-of-RIB marker SHALL be sent. the End-of-RIB marker MUST be sent.
To put an upper bound on the amount of time a router defers its route To put an upper bound on the amount of time a router defers its route
selection, an implementation MUST support a (configurable) timer that selection, an implementation MUST support a (configurable) timer that
imposes this upper bound. This timer is referred to as the imposes this upper bound. This timer is referred to as the
"Selection_Deferral_Timer". The value of this timer should be large "Selection_Deferral_Timer". The value of this timer should be large
enough, as to provide all the peers of the Restarting Speaker with enough, as to provide all the peers of the Restarting Speaker with
enough time to send all the routes to the Restarting Speaker. enough time to send all the routes to the Restarting Speaker.
If one wants to apply graceful restart only when the restart is If one wants to apply graceful restart only when the restart is
planned (as opposed to both planned and unplanned restart), then one planned (as opposed to both planned and unplanned restart), then one
way to accomplish this would be to set the Forwarding State bit to 1 way to accomplish this would be to set the Forwarding State bit to 1
after a planned restart, and to 0 in all other cases. Other after a planned restart, and to 0 in all other cases. Other
approaches to accomplish this are outside the scope of this document. approaches to accomplish this are outside the scope of this document.
5.2. Procedures for the Receiving Speaker 5.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 termination of the old TCP
considers the BGP session as being established, it SHALL treat the session and still considers the BGP session as being established, it
subsequent open connection from the peer as an indication of TCP MUST treat the subsequent open connection from the peer as an
reset and act accordingly (when the Graceful Restart Capability has indication of the termination of the old TCP session and act
been received from the peer). See Section 8 for a description of this accordingly (when the Graceful Restart Capability has been received
behavior in terms of the BGP finite state machine. 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 MUST 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 terminated, no NOTIFICATION message should be sent -- the previous
session is simply closed. TCP session is simply closed.
When the Receiving Speaker detects TCP reset for a BGP session with a When the Receiving Speaker detects termination of the TCP session for
peer that has advertised the Graceful Restart Capability, it SHALL a BGP session with a peer that has advertised the Graceful Restart
retain the routes received from the peer for all the address families Capability, it MUST retain the routes received from the peer for all
that were previously received in the Graceful Restart Capability, and the address families that were previously received in the Graceful
SHALL mark them as stale routing information. To deal with possible Restart Capability, and MUST mark them as stale routing information.
consecutive restarts, a route (from the peer) previously marked as To deal with possible consecutive restarts, a route (from the peer)
stale SHALL be deleted. The router SHOULD NOT differentiate between previously marked as stale MUST be deleted. The router MUST NOT
stale and other routing information during forwarding. differentiate between stale and other routing information during
forwarding.
In re-establishing the session, the "Restart State" bit in the In re-establishing the session, the "Restart State" bit in the
Graceful Restart Capability of the OPEN message sent by the Receiving Graceful Restart Capability of the OPEN message sent by the Receiving
Speaker SHALL NOT be set unless the Receiving Speaker has restarted. Speaker MUST NOT be set unless the Receiving Speaker has restarted.
The presence and the setting of the "Forwarding State" bit for an The presence and the setting of the "Forwarding State" bit for an
address family depends upon the actual forwarding state and address family depends upon the actual forwarding state and
configuration. configuration.
If the session does not get re-established within the "Restart Time" If the session does not get re-established within the "Restart Time"
that the peer advertised previously, the Receiving Speaker SHALL that the peer advertised previously, the Receiving Speaker MUST
delete all the stale routes from the peer that it is retaining. delete all the stale routes from the peer that it is retaining.
A BGP speaker could have some way of determining whether its peer's A BGP speaker could have some way of determining whether its peer's
forwarding state is still viable, for example through [BFD] or forwarding state is still viable, for example through [BFD] or
through monitoring layer two information. Specifics of such through monitoring layer two information. Specifics of such
mechanisms are beyond the scope of this document. In the event that mechanisms are beyond the scope of this document. In the event that
it determines that its peer's forwarding state is not viable prior to it determines that its peer's forwarding state is not viable prior to
the re-establishment of the session, the speaker MAY delete all the the re-establishment of the session, the speaker MAY delete all the
stale routes from the peer that it is retaining. stale routes from the peer that it is retaining.
Once the session is re-established, if the "Forwarding State" bit for Once the session is re-established, if the "Forwarding State" bit for
a specific address family is not set in the newly received Graceful a specific address family is not set in the newly received Graceful
Restart Capability, or if a specific address family is not included Restart Capability, or if a specific address family is not included
in the newly received Graceful Restart Capability, or if the Graceful in the newly received Graceful Restart Capability, or if the Graceful
Restart Capability isn't received in the re-established session at Restart Capability isn't received in the re-established session at
all, then Receiving Speaker SHALL immediately remove all the stale all, then Receiving Speaker MUST immediately remove all the stale
routes from the peer that it is retaining for that address family. routes from the peer that it is retaining for that address family.
The Receiving Speaker SHALL send the End-of-RIB marker once it The Receiving Speaker MUST send the End-of-RIB marker once it
completes the initial update for an address family (including the completes the initial update for an address family (including the
case that it has no routes to send) to the peer. case that it has no routes to send) to the peer.
The Receiving Speaker SHALL replace the stale routes by the routing The Receiving Speaker MUST 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 MUST 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.
6. Changes to BGP Finite State Machine 6. Changes to BGP Finite State Machine
As mentioned under "Procedures for the Receiving Speaker" above, this As mentioned under "Procedures for the Receiving Speaker" above, this
skipping to change at line 530 skipping to change at line 532
8. Security Considerations 8. 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.
If an attacker is able to successfully open a TCP connection
impersonating a legitimate peer, the attacker's connection will
replace the legitimate one, potentially enabling the attacker to
advertise bogus routes. We note, however, that the window for such a
route insertion attack is small since through normal operation of the
protocol the legitimate peer would open a new connection, in turn
causing the attacker's connection to be terminated. Thus, this
attack devolves to a form of denial of service.
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.
We also note that implementations may allow use of graceful restart
to be controlled by configuration. If graceful restart is not
enabled, naturally the underlying security model of BGP-4 is
unchanged.
9. Intellectual Property Considerations 9. Intellectual Property Considerations
This section is taken from Section 5 of RFC 3668. This section is taken from Section 5 of RFC 3668.
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
skipping to change at line 583 skipping to change at line 599
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. IANA Considerations 11. IANA Considerations
This document defines a new BGP Capability - Graceful Restart This document defines a new BGP Capability - Graceful Restart
Capability. The Capability Code for Graceful Restart Capability is Capability. The Capability Code for Graceful Restart Capability is
64. 64.
12. Acknowledgments 12. Acknowledgments
The authors would like to thank Bruce Cole, Bill Fenner, Eric Gray The authors would like to thank Bruce Cole, Lars Eggert, Bill Fenner,
Jeffrey Haas, Alvaro Retana, Naiming Shen, Satinder Singh, David Eric Gray Jeffrey Haas, Sam Hartman Alvaro Retana, Pekka Savola
Ward, Shane Wright and Alex Zinin for their review and comments. Naiming Shen, Satinder Singh, Mark Townsley, David Ward, Shane Wright
and Alex Zinin for their review and comments.
13. Normative References 13. Normative References
[BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4 [BGP-4] Rekhter, Y., T. Li, Hares, S., "A Border Gateway Protocol 4
(BGP-4)", RFC4271, January 2006. (BGP-4)", RFC4271, January 2006.
[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
 End of changes. 28 change blocks. 
56 lines changed or deleted 73 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/