draft-ietf-idr-restart-10.txt   draft-ietf-idr-restart-11.txt 
Network Working Group Srihari R. Sangli (Procket Networks) Network Working Group Srihari R. Sangli
Internet Draft Yakov Rekhter (Juniper Networks) Internet Draft Yakov Rekhter
Expiration Date: December 2004 Rex Fernando (Procket Networks) Expiration Date: November 2006 Rex Fernando
John G. Scudder (Cisco Systems) John G. Scudder
Enke Chen (Redback Networks) Enke Chen
Graceful Restart Mechanism for BGP Graceful Restart Mechanism for BGP
draft-ietf-idr-restart-10.txt draft-ietf-idr-restart-11.txt
1. Status of this Memo
This document is an Internet-Draft and is in full conformance with Status of this Memo
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.
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
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as ``work in progress.'' material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
2. Abstract IPR Disclosure Acknowledgement
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Abstract
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 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).
3. 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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC2119 [RFC2119]. document are to be interpreted as described in RFC2119 [RFC2119].
4. Introduction 2. 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
overall network performance. overall network performance.
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.
5. 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
withdrawn routes for that <AFI, SAFI>. withdrawn routes for that <AFI, SAFI>.
skipping to change at page 3, line 11 skipping to change at line 103
graceful restart, it is noted that the generation of such a marker graceful restart, it is noted that the generation of such a marker
upon completion of the initial update would be useful for routing upon completion of the initial update would be useful for routing
convergence in general, and thus the practice is recommended. convergence in general, and thus the practice is recommended.
In addition, it would be beneficial for routing convergence if a BGP In addition, it would be beneficial for routing convergence if a BGP
speaker can indicate to its peer up-front that it will generate the speaker can indicate to its peer up-front that it will generate the
End-Of-RIB marker, regardless of its ability to preserve its End-Of-RIB marker, regardless of its ability to preserve its
forwarding state during BGP restart. This can be accomplished using forwarding state during BGP restart. This can be accomplished using
the Graceful Restart Capability described in the next section. the Graceful Restart Capability described in the next section.
6. Graceful Restart Capability 4. Graceful Restart Capability
The Graceful Restart Capability is a new BGP capability [BGP-CAP] The Graceful Restart Capability is a new BGP capability [BGP-CAP]
that can be used by a BGP speaker to indicate its ability to preserve that can be used by a BGP speaker to indicate its ability to preserve
its forwarding state during BGP restart. It can also be used to its forwarding state during BGP restart. It can also be used to
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
skipping to change at page 5, line 31 skipping to change at line 220
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
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.
7. 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
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 (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
skipping to change at page 6, line 23 skipping to change at line 259
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 SHALL be followed
by the Restarting Speaker as well as the Receiving Speaker once the by the Restarting Speaker as well as the Receiving Speaker once the
Restarting Speaker restarts. Restarting Speaker restarts.
7.1. Procedures for the Restarting Speaker 5.1. Procedures for the Restarting Speaker
When the Restarting Speaker restarts, possible it SHOULD retain, if When the Restarting Speaker restarts, possible it SHOULD retain, if
possible, the forwarding state for the BGP routes in the Loc-RIB, and possible, the forwarding state for the BGP routes in the Loc-RIB, and
SHALL mark them as stale. It SHOULD NOT differentiate between stale SHALL mark them as stale. It SHOULD NOT differentiate between stale
and other information during forwarding. and other 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 SHALL defer route
selection for an address family until it receives the End-of-RIB selection for an address family until it either (a) receives the End-
marker from all its peers (excluding the ones with the "Restart of-RIB marker from all its peers (excluding the ones with the
State" bit set in the received capability and excluding the ones "Restart State" bit set in the received capability and excluding the
which do not advertise the graceful restart capability). It is noted ones which do not advertise the graceful restart capability) or (b)
that prior to route selection, the speaker has no routes to advertise the Selection_Deferral_Timer referred to below has expired. It is
to its peers and no routes to update the forwarding state. noted that prior to route selection, the speaker has no routes to
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 SHALL be updated and any previously marked stale
information SHALL be removed. The Adj-RIB-Out can then be advertised information SHALL 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 SHALL 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. imposes this upper bound. This timer is referred to as the
"Selection_Deferral_Timer". The value of this timer should be large
enough, as to provide all the peers of the Restarting Speaker with
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.
7.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 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). See Section 8 for a description of this been received from the peer). See Section 8 for a description of this
skipping to change at page 8, line 35 skipping to change at line 370
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. 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
specification modifies the BGP finite state machine. specification modifies the BGP finite state machine.
The specific state machine modifications to [BGP-4] Section 8.2.2 are The specific state machine modifications to [BGP-4] Section 8.2.2 are
as follows. In the Established state, replace this text: as follows.
If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is In the Idle state, make the following changes.
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: Replace this text:
If a TcpConnection_Valid (Event 14) or Tcp_CR_Acked (Event 16) is - initializes all BGP resources for the peer connection,
received, a second TCP connection may be in progress. This second
TCP connection is tracked per Connection Collision processing with
(Section 6.8) until an OPEN message is received.
- initializes all BGP resources for the peer connection, other
than those resources required in order to retain routes according
to section "Procedures for the Receiving Speaker" of this
(Graceful Restart) specification,
In the Established state, make the following changes.
Replace this text:
In response to an indication that the TCP connection is
successfully established (Event 16 or Event 17), the second
connection SHALL be tracked until it sends an OPEN message.
with
If the Graceful Restart capability with one or more AFI/SAFI has If the Graceful Restart capability with one or more AFI/SAFI has
been received for the session, then TcpConnectionConfirmed (Event not been received for the session, then in response to an
17) is treated as TcpConnectionFails (Event 18). indication that a TCP connection is successfully established
(Event 16 or Event 17), the second connection SHALL be tracked
until it sends an OPEN message.
If a TcpConnectionConfirmed event (Event 17) is received and if However, if the Graceful Restart capability with one or more
the Graceful Restart capability with one or more AFI/SAFI has not AFI/SAFI has been received for the session, then in response to
been received for the session, a second TCP connection may be in Event 16 or Event 17 the local system:
progress. This second TCP connection is tracked per Connection
Collision processing (Section 6.8) until an OPEN message is
received.
9. Deployment Considerations - retains all routes associated with this connection according
to section "Procedures for the Receiving Speaker" of this
(Graceful Restart) specification,
- releases all other BGP resources,
- drops the TCP connection associated with the ESTABLISHED
session,
- initializes all BGP resources for the peer connection, other
than those required in order to retain routes according to
section "Procedures for the Receiving Speaker" of this
specification,
- sets ConnectRetryCounter to zero,
- starts the ConnectRetryTimer with the initial value,
- changes its state to Connect.
Replace this text:
If the local system receives a NOTIFICATION message (Event 24 or
Event 25), or a TcpConnectionFails (Event 18) from the underlying
TCP, the local system:
- sets the ConnectRetryTimer to zero,
- deletes all routes associated with this connection,
- releases all the BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- changes its state to Idle.
with
If the local system receives a NOTIFICATION message (Event 24 or
Event 25), or if the local system receives a TcpConnectionFails
(Event 18) from the underlying TCP and the Graceful Restart
capability with one or more AFI/SAFI has not been received for the
session, the local system:
- sets the ConnectRetryTimer to zero,
- deletes all routes associated with this connection,
- releases all the BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- changes its state to Idle.
However, if the local system receives a TcpConnectionFails (Event
18) from the underlying TCP, and the Graceful Restart capability
with one or more AFI/SAFI has been received for the session, the
local system:
- sets the ConnectRetryTimer to zero,
- retains all routes associated with this connection according
to section "Procedures for the Receiving Speaker" of this
(Graceful Restart) specification,
- releases all other BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCounter by 1,
- changes its state to Idle.
7. 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 10, line 5 skipping to change at line 510
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.
10. 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.
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.
11. Acknowledgments 9. Intellectual Property Considerations
This section is taken from Section 5 of RFC 3668.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
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
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
10. Copyright Notice
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
11. IANA Considerations
This document defines a new BGP Capability - Graceful Restart
Capability. The Capability Code for Graceful Restart Capability is
64.
12. 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.
12. 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)", work in progress. (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
BGP-4", draft-ietf-idr-rfc2842bis-02.txt, April 2002. BGP-4", RFC3392, November 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.
13. Author Information 14. Author Information
Srihari R. Sangli Srihari R. Sangli
Procket Networks, Inc. Cisco Systems, Inc.
1100 Cadillac Court EMail: rsrihari@cisco.com
Milpitas, CA 95035
e-mail: srihari@procket.com
Yakov Rekhter Yakov Rekhter
Juniper Networks, Inc. Juniper Networks, Inc.
1194 N. Mathilda Avenue EMail: yakov@juniper.net
Sunnyvale, CA 94089
e-mail: yakov@juniper.net
Rex Fernando Rex Fernando
Procket Networks, Inc. e-mail: rex_f@yahoo.com
1100 Cadillac Court
Milpitas, CA 95035
e-mail: rex@procket.com
John G. Scudder John G. Scudder
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive EMail: jgs@cisco.com
San Jose, CA 95134
e-mail: jgs@cisco.com
Enke Chen Enke Chen
Redback Networks, Inc. Cisco Systems, Inc.
350 Holger Way EMail: enkechen@cisco.com
San Jose, CA 95134
e-mail: enke@redback.com
 End of changes. 33 change blocks. 
67 lines changed or deleted 200 lines changed or added

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