draft-ietf-mpls-bgp-mpls-restart-05.txt   rfc4781.txt 
Network Working Group Yakov Rekhter (Juniper Networks) Network Working Group Y. Rekhter
Internet Draft Rahul Aggarwal (Juniper Networks) Request for Comments: 4781 R. Aggarwal
Expiration Date: February 2006 Category: Standards Track Juniper Networks
January 2007
Graceful Restart Mechanism for BGP with MPLS Graceful Restart Mechanism for BGP with MPLS
draft-ietf-mpls-bgp-mpls-restart-05.txt Status of This Memo
Status of this Memo
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.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document specifies an Internet standards track protocol for the
http://www.ietf.org/shadow.html. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
IPR Disclosure Acknowledgement Copyright Notice
By submitting this Internet-Draft, each author represents that any Copyright (C) The Internet Society (2007).
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 Abstract
A mechanism for BGP that helps minimize the negative effects on A mechanism for BGP that helps minimize the negative effects on
routing caused by BGP restart has already been developed an is routing caused by BGP restart has already been developed and is
described in a separate document ("Graceful Restart Mechanism for described in a separate document ("Graceful Restart Mechanism for
BGP"). This document extends this mechanism to also minimize the BGP"). This document extends this mechanism to minimize the negative
negative effects on MPLS forwarding caused by the Label Switching effects on MPLS forwarding caused by the Label Switching Router's
Router's (LSR's) control plane restart, and specifically by the (LSR's) control plane restart, and specifically by the restart of its
restart of its BGP component when BGP is used to carry MPLS labels BGP component when BGP is used to carry MPLS labels and the LSR is
and the LSR is capable of preserving the MPLS forwarding state across capable of preserving the MPLS forwarding state across the restart.
the restart.
The mechanism described in this document is agnostic with respect to The mechanism described in this document is agnostic with respect to
the types of the addresses carried in the BGP Network Layer the types of the addresses carried in the BGP Network Layer
Reachability Information (NLRI) field. As such it works in Reachability Information (NLRI) field. As such, it works in
conjunction with any of the address famililies that could be carried conjunction with any of the address families that could be carried in
in BGP (e.g., IPv4, IPv6, etc...) BGP (e.g., IPv4, IPv6, etc.).
The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve their forwarding state during
BGP restart and those without (although the latter need to implement
only a subset of the mechanism described in this document).
Supporting a subset of the mechanism described here by the LSRs that
can not preserve their MPLS forwarding state across the restart would
not reduce the negative impact on MPLS traffic caused by their
control plane restart, but it would minimize the impact if their
neighbor(s) are capable of preserving the forwarding state across the
restart of their control plane and implement the mechanism described
here.
Specification of Requirements Table of Contents
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 1. Introduction ....................................................2
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 1.1. Specification of Requirements ..............................3
document are to be interpreted as described in RFC 2119 [RFC2119]. 2. General Requirements ............................................3
3. Capability Advertisement ........................................4
4. Procedures for the Restarting LSR ...............................4
4.1. Case 1 .....................................................4
4.2. Case 2 .....................................................5
4.3. Case 3 .....................................................5
5. Alternative Procedures for the Restarting LSR ...................6
6. Procedures for a Neighbor of a Restarting LSR ...................6
7. Comparison between Alternative Procedures for the
Restarting LSR ..................................................7
8. Security Considerations .........................................8
9. Acknowledgments .................................................9
10. References .....................................................9
10.1. Normative References ......................................9
10.2. Informative References ....................................9
1. Introduction 1. Introduction
For the sake of brevity in the context of this document by "MPLS
forwarding state" we mean either <incoming label -> (outgoing label,
next hop)>, or <Forwarding Equivalence Class (FEC) -> (outgoing
label, next hop)>, or <incoming label -> label pop, next hop>, or
<incoming label, label pop> mapping. In the context of this document
the forwarding state that is referred to in [1] means MPLS forwarding
state, as defined above. In the context of this document the term
"next hop" refers to the next hop as advertised in BGP.
In the case where a Label Switching Router (LSR) could preserve its In the case where a Label Switching Router (LSR) could preserve its
MPLS forwarding state across restart of its control plane, and MPLS forwarding state across restart of its control plane, and
specifically its BGP component, and BGP is used to carry MPLS labels specifically its BGP component, and BGP is used to carry MPLS labels
(e.g., as specified in [RFC3107]), it may be desirable not to perturb (e.g., as specified in [RFC3107]), it may be desirable not to perturb
the LSPs going through that LSR (and specifically, the LSPs the LSPs going through that LSR (and specifically, the LSPs
established by BGP) after failure of or restart of the BGP component established by BGP) after failure or restart of the BGP component of
of the control plane. In this document, we describe a mechanism that the control plane. In this document, we describe a mechanism that
allows this goal to be accomplished. The mechanism described in this allows this goal to be accomplished. The mechanism described in this
document works in conjunction with the mechanism specified in [1]. document works in conjunction with the mechanism specified in
The mechanism described in this document places no restrictions on [RFC4724]. The mechanism described in this document places no
the types of addresses (address families) that it can support. restrictions on the types of addresses (address families) that it can
support.
The mechanism described in this document is applicable to all LSRs, The mechanism described in this document is applicable to all LSRs,
both those with the ability to preserve forwarding state during BGP both those with the ability to preserve forwarding state during BGP
restart and those without (although the latter need to implement only restart and those without it (although the latter need to implement
a subset of the mechanism described in this document). Supporting a only a subset of this mechanism). Supporting a subset of the
subset of the mechanism described here by the LSRs that can not mechanism described here by the LSRs that cannot preserve their MPLS
preserve their MPLS forwarding state across the restart would not forwarding state across the restart would not reduce the negative
reduce the negative impact on MPLS traffic caused by their control impact on MPLS traffic caused by their control plane restart.
plane restart, but it would minimize the impact if their neighbor(s) However, the impact would be minimized if their neighbor(s) are
are capable of preserving the forwarding state across the restart of capable of preserving the forwarding state across the restart of
their control plane and implement the mechanism described here. The their control plane, and if they implement the mechanism described
subset includes all the procedures described in this document, except here. The subset includes all the procedures described in this
the procedures in Sections 4.1, 4.2, 4.3 and 5. document, except the procedures in Sections 4.1, 4.2, 4.3, and 5.
2. General requirements For the sake of brevity, by "MPLS forwarding state" we mean one of
the following mappings:
<incoming label -> (outgoing label, next hop)>
<Forwarding Equivalence Class (FEC) -> (outgoing label, next hop)>
<incoming label -> label pop, next hop>
<incoming label, label pop>
First of all an LSR MUST implement the Graceful Restart Mechanism for In the context of this document, the forwarding state that is
BGP, as specified in [1]. Second, the LSR SHOULD be capable of referred to in [RFC4724] means MPLS forwarding state, as defined
preserving its MPLS forwarding state across the restart of its above. The term "next hop" refers to the next hop as advertised in
control plane (including the restart of BGP). Third, for the BGP.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. General Requirements
First of all, an LSR MUST implement the Graceful Restart Mechanism
for BGP, as specified in [RFC4724]. Second, the LSR SHOULD be
capable of preserving its MPLS forwarding state across the restart of
its control plane (including the restart of BGP). Third, for the
<Forwarding Equivalence Class (FEC) -> label> bindings distributed <Forwarding Equivalence Class (FEC) -> label> bindings distributed
via BGP the LSR SHOULD be able either (a) to reconstruct the same via BGP, the LSR SHOULD be able either (a) to reconstruct the same
bindings as the LSR had prior to the restart (see Section 4), or (b) bindings as the LSR had prior to the restart (see Section 4), or (b)
to create new <FEC -> label> bindings after restart, while to create new <FEC -> label> bindings after restart, while
temporarily maintaining MPLS forwarding state corresponding to both temporarily maintaining MPLS forwarding state corresponding to both
the bindings prior to the restart, as well as to the newly created the bindings prior to the restart, as well as to the newly created
bindings (see Section 5). Fourth, as long as the LSR retains the MPLS bindings (see Section 5). Fourth, as long as the LSR retains the
forwarding state that the LSR preserved across the restart, the MPLS forwarding state that the LSR preserved across the restart, the
labels from that state can not be used to create new local label labels from that state can not be used to create new local label
bindings (but could be used to reconstruct the existing bindings, as bindings (but could be used to reconstruct the existing bindings, as
per procedures in Section 4). Finally, for each next hop, if the next per procedures in Section 4). Finally, for each next hop, if the
hop is reachable via a Label Switched Path (LSP), then the restarting next hop is reachable via a Label Switched Path (LSP), then the
LSR MUST be able to preserve the MPLS forwarding state associated restarting LSR MUST be able to preserve the MPLS forwarding state
with that LSP across the restart. associated with that LSP across the restart.
In the scenario where label binding on an LSR is created/maintained In the scenario where label binding on an LSR is created/maintained
not just by the BGP component of the control plane, but by other not only by the BGP component of the control plane, but also by other
protocol components as well (e.g., LDP, RSVP-TE), and the LSR protocol components (e.g., LDP, RSVP-TE), and where the LSR supports
supports restart of the individual components of the control plane restart of the individual components of the control plane that
that create/maintain label binding (e.g., restart of BGP, but no create/maintain label binding (e.g., restart of BGP, but no restart
restart of LDP) the LSR MUST be able to preserve across the restart of LDP), the LSR MUST be able to preserve across the restart the
the information about which protocol has assigned which labels. information about which protocol has assigned which labels.
After the LSR restarts, it MUST follow the procedures as specified in After the LSR restarts, it MUST follow the procedures as specified in
[1]. In addition, if the LSR is able to preserve its MPLS forwarding [RFC4724]. In addition, if the LSR is able to preserve its MPLS
state across the restart, the LSR SHOULD advertise this to its forwarding state across the restart, the LSR SHOULD advertise this to
neighbors by appropriately setting the Flag for Address Family field its neighbors by appropriately setting the Flag for Address Family
in the Graceful Restart Capability for all applicable AFI/SAFI pairs. field in the Graceful Restart Capability for all applicable AFI/SAFI
pairs.
3. Capability Advertisement 3. Capability Advertisement
An LSR that supports the mechanism described in this document An LSR that supports the mechanism described in this document
advertises this to its peer by using the Graceful Restart Capability, advertises this to its peer by using the Graceful Restart Capability,
as specified in [1]. The Subsequent Address Family Identifier (SAFI) as specified in [RFC4724]. The Subsequent Address Family Identifier
in the advertised capability MUST indicate that the Network Layer (SAFI) in the advertised capability MUST indicate that the Network
Reachability Information (NLRI) field carries not just addressing Layer Reachability Information (NLRI) field carries not only
Information, but labels as well (see [RFC3107] as an example of where addressing Information, but also labels (see [RFC3107] for an example
NLRI carries labels). of where NLRI carries labels).
4. Procedures for the restarting LSR 4. Procedures for the Restarting LSR
Procedures in this section apply when a restarting LSR is able to Procedures in this section apply when a restarting LSR is able to
reconstruct the same <FEC -> label> bindings as the LSR had prior to reconstruct the same <FEC -> label> bindings as the LSR had prior to
the restart. the restart.
The procedures described in this section are conceptual and do not The procedures described in this section are conceptual and do not
have to be implemented precisely as described here, as long as the have to be implemented precisely as described, as long as the
implementations support the described functionality and their implementations support the described functionality and their
externally visible behavior is the same. externally visible behavior is the same.
Once the LSR completes its route selection (as specified in Section Once the LSR completes its route selection (as specified in Section
"Procedures for the Restarting Speaker" of [1]), then in addition to 4.1, "Procedures for the Restarting Speaker", of [RFC4724]), then in
the procedures specified in [1], the LSR performs one of the addition to the those procedures, the LSR performs one of the
following: following:
4.1. Case 1 4.1. Case 1
The following applies when (a) the best route selected by the LSR was The following applies when (a) the best route selected by the LSR was
received with a label, (b) that label is not an Implicit NULL, and received with a label, (b) that label is not an Implicit NULL, and
(c) the LSR advertises this route with itself as the next hop. (c) the LSR advertises this route with itself as the next hop.
In this case the LSR searches its MPLS forwarding state (the one In this case, the LSR searches its MPLS forwarding state (the one
preserved across the restart) for an entry with <outgoing label, next preserved across the restart) for an entry with <outgoing label, next
hop> equal to the one in the received route. If such an entry is hop> equal to the one in the received route. If such an entry is
found, the LSR no longer marks the entry as stale. In addition if the found, the LSR no longer marks the entry as stale. In addition, if
entry is of type <incoming label, (outgoing label, next hop)> rather the entry is of type <incoming label, (outgoing label, next hop)>
than <Forwarding Equivalence Class (FEC), (outgoing label, next rather than <Forwarding Equivalence Class (FEC), (outgoing label,
hop)>, the LSR uses the incoming label from the entry when next hop)>, the LSR uses the incoming label from the entry when
advertising the route to its neighbors. If the found entry has no advertising the route to its neighbors. If the found entry has no
incoming label, or if no such entry is found, the LSR allocates a new incoming label, or if no such entry is found, the LSR allocates a new
label when advertising the route to its neighbors (assuming that label when advertising the route to its neighbors (assuming that
there are neighbors to which the LSR has to advertise the route with there are neighbors to which the LSR has to advertise the route with
a label). a label).
4.2. Case 2 4.2. Case 2
The following applies when (a) the best route selected by the LSR was The following applies when (a) the best route selected by the LSR was
received either without a label, or with an Implicit NULL label, or received either without a label, with an Implicit NULL label, or the
the route is originated by the LSR, (b) the LSR advertises this route route is originated by the LSR; (b) the LSR advertises this route
with itself as the next hop, and (c) the LSR has to generate a (non with itself as the next hop; and (c) the LSR has to generate a (non-
Implicit NULL) label for the route. Implicit NULL) label for the route.
In this case the LSR searches its MPLS forwarding state for an entry In this case, the LSR searches its MPLS forwarding state for an entry
that indicates that the LSR has to perform label pop, and the next that indicates that the LSR has to perform label pop, and the next
hop equal to the next hop of the route in consideration. If such an hop equal to the next hop of the route in consideration. If such an
entry is found, then the LSR uses the incoming label from the entry entry is found, then the LSR uses the incoming label from the entry
when advertising the route to its neighbors. If no such entry is when advertising the route to its neighbors. If no such entry is
found, the LSR allocates a new label when advertising the route to found, the LSR allocates a new label when advertising the route to
its neighbors. its neighbors.
The description in the above paragraph assumes that the LSR generates The description in the above paragraph assumes that the LSR generates
the same label for all the routes with the same next hop. If this is the same label for all the routes with the same next hop. If this is
not the case, and the LSR generates a unique label per each such not the case and the LSR generates a unique label per each such
route, then the LSR needs to preserve across the restart not just route, then the LSR needs to preserve across the restart not only
<incoming label, (outgoing label, next hop)> mapping, but also the <incoming label, (outgoing label, next hop)> mapping, but also the
Forwarding Equivalence Class (FEC) associated with this mapping. In Forwarding Equivalence Class (FEC) associated with this mapping. In
such case the LSR would search its MPLS forwarding state for an entry such a case the LSR would search its MPLS forwarding state for an
that (a) indicates Label pop (means no outgoing label), (b) the next entry that (a) indicates label pop (means no outgoing label), (b)
hop equal to the next hop of the route and (c) has the same FEC as indicates that the next hop equal to the next hop of the route, and
the route. If such an entry is found, then the LSR uses the incoming (c) has the same FEC as the route. If such an entry is found, then
label from the entry when advertising the route to its neighbors. If the LSR uses the incoming label from the entry when advertising the
no such entry is found, the LSR allocates a new label when route to its neighbors. If no such entry is found, the LSR allocates
advertising the route to its neighbors. a new label when advertising the route to its neighbors.
4.3. Case 3 4.3. Case 3
The following applies when the LSR does not set BGP next hop to self. The following applies when the LSR does not set BGP next hop to self.
In this case the LSR, when advertising its best route for a In this case, the LSR, when advertising its best route for a
particular NLRI just uses the label that was received with that particular NLRI, just uses the label that was received with that
route. And if the route was received with no label, the LSR route. And if the route was received with no label, the LSR
advertises the route with no label as well. Either way, the LSR does advertises the route with no label as well. Either way, the LSR does
not allocate a label for that route. not allocate a label for that route.
5. Alternative procedures for the restarting LSR 5. Alternative Procedures for the Restarting LSR
In this section we describe an alternative to the procedures In this section, we describe an alternative to the procedures
described in Section "Procedures for the restarting LSR". described in Section "Procedures for the restarting LSR".
Procedures in this section apply when a restarting LSR does not Procedures in this section apply when a restarting LSR does not
reconstruct the same <FEC -> label> bindings as the LSR had prior to reconstruct the same <FEC -> label> bindings as the LSR had prior to
the restart, but instead creates new <FEC -> label> bindings after the restart, but instead creates new <FEC -> label> bindings after
restart, while temporarily maintaining MPLS forwarding state restart, while temporarily maintaining MPLS forwarding state
corresponding to both the bindings prior to the restart, as well as corresponding to both the bindings prior to the restart, as well as
to the newly created bindings. to the newly created bindings.
The procedures described in this section require that for the use by The procedures described in this section require that for the use by
BGP graceful restart the LSR SHOULD have (at least) as many BGP graceful restart, the LSR SHOULD have (at least) as many
unallocated labels as labels allocated for the <FEC -> label> unallocated labels as labels allocated for the <FEC -> label>
bindings distributed by BGP. The latter forms the MPLS forwarding bindings distributed by BGP. The latter forms the MPLS forwarding
state that the LSR managed to preserve across the restart. The former state that the LSR managed to preserve across the restart. The
is used for allocating labels after the restart. former is used for allocating labels after the restart.
To create (new) local label bindings after the restart the LSR uses To create (new) local label bindings after the restart, the LSR uses
unallocated labels (this is pretty much the normal procedure). unallocated labels (this is pretty much the normal procedure).
The LSR SHOULD retain the MPLS forwarding state that the LSR The LSR SHOULD retain the MPLS forwarding state that the LSR
preserved across the restart at least until the LSR sends End-of-RIB preserved across the restart at least until the LSR sends an
marker to all of its neighbors (by that time the LSR already End-of-RIB marker to all of its neighbors (by that time the LSR
completed its route selection process, and also advertised its Adj- already completed its route selection process, and also advertised
RIB-Out to its neighbors). The LSR MAY retain the forwarding state its Adj-RIB-Out to its neighbors). The LSR MAY retain the forwarding
even a bit longer (the amount of extra time MAY be controlled by state even a bit longer (the amount of extra time MAY be controlled
configuration on the LSR), as to allow the neighbors to receive and by configuration on the LSR), so as to allow the neighbors to receive
process the routes that have been advertised by the LSR. After that, and process the routes that have been advertised by the LSR. After
the LSR SHOULD delete the MPLS forwarding state that it preserved that, the LSR SHOULD delete the MPLS forwarding state that it
across the restart. preserved across the restart.
Note that while an LSR is in the process of restarting, the LSR may Note that while an LSR is in the process of restarting, the LSR may
have not one, but two local label bindings for a given BGP route - have not one, but two local label bindings for a given BGP route --
one that was retained from prior to restart, and another that was one that was retained from prior to restart, and another that was
created after the restart. Once the LSR completes its restart, the created after the restart. Once the LSR completes its restart, the
former will be deleted. Both of these bindings though would have the former will be deleted. However, both of these bindings would have
same outgoing label (and the same next hop). the same outgoing label (and the same next hop).
6. Procedures for a neighbor of a restarting LSR 6. Procedures for a Neighbor of a Restarting LSR
The neighbor of a restarting LSR (the receiving router in terminology The neighbor of a restarting LSR (the receiving router terminology
used in [1]) follows the procedures specified in [1]. In addition, used in [RFC4724]) follows the procedures specified in [RFC4724]. In
the neighbor treats the MPLS labels received from the restarting LSR addition, the neighbor treats the MPLS labels received from the
the same way as it treats the routes received from the restarting LSR restarting LSR the same way that it treats the routes received from
(both prior and after the restart). the restarting LSR (both prior and after the restart).
Replacing the stale routes by the routing updates received from the Replacing the stale routes by the routing updates received from the
restarting LSR involves replacing/updating the appropriate MPLS restarting LSR involves replacing/updating the appropriate MPLS
labels. labels.
In addition, if the Flags in the Graceful Restart Capability received In addition, if the Flags in the Graceful Restart Capability received
from the restarting LSR indicate that the LSR wasn't able to retain from the restarting LSR indicate that the LSR wasn't able to retain
its MPLS state across the restart, the neighbor SHOULD immediately its MPLS state across the restart, the neighbor SHOULD immediately
remove all the NLRI and the associated MPLS labels that it previously remove all the NLRI and the associated MPLS labels that it previously
acquired via BGP from the restarting LSR. acquired via BGP from the restarting LSR.
An LSR, once it creates a binding between a label and a Forwarding An LSR, once it creates a binding between a label and a Forwarding
Equivalence Class (FEC), SHOULD keep the value of the label in this Equivalence Class (FEC), SHOULD keep the value of the label in this
binding for as long as the LSR has a route to the FEC in the binding. binding for as long as the LSR has a route to the FEC in the binding.
If the route to the FEC disappears, and then re-appears again later, If the route to the FEC disappears and then re-appears again later,
then this may result in using a different label value, as when the then this may result in using a different label value, as when the
route re-appears, the LSR would create a new <label, FEC> binding. route re-appears, the LSR would create a new <label, FEC> binding.
To minimize the potential mis-routing caused by the label change, To minimize the potential misrouting caused by the label change, when
when creating a new <label, FEC> binding the LSR SHOULD pick up the creating a new <label, FEC> binding, the LSR SHOULD pick up the least
least recently used label. Once an LSR releases a label, the LSR recently used label. Once an LSR releases a label, the LSR SHALL NOT
SHALL NOT re-use this label for advertising a <label, FEC> binding to re-use this label for advertising a <label, FEC> binding to a
a neighbor that supports graceful restart for at least the Restart neighbor that supports graceful restart for at least the Restart
Time, as advertised by the neighbor to the LSR. This rule SHALL Time, as advertised by the neighbor to the LSR. This rule SHALL
apply to any label release at any time. apply to any label release at any time.
7. Comparison between alternative procedures for the restarting LSR 7. Comparison between Alternative Procedures for the Restarting LSR
Procedures described in Section 4 involve more computational overhead Procedures described in Section 4 involve more computational overhead
on the restarting router relative to the procedures described in on the restarting router than do the procedures described in Section
Section 5. 5.
Procedures described in Section 5 requires twice as many labels as Procedures described in Section 5 require twice as many labels as
the procedures described in Section 4. those described in Section 4.
Procedures described in Section 4 cause fewer changes to the MPLS Procedures described in Section 4 cause fewer changes to the MPLS
forwarding state in the neighbors of the restarting router than the forwarding state in the neighbors of the restarting router than the
procedures described in Section 5. procedures described in Section 5.
In principle it is possible for an LSR to use procedures described in In principle, it is possible for an LSR to use procedures described
Section 4 for some AFI/SAFI(s) and procedures described in Section 5 in Section 4 for some AFI/SAFI(s) and procedures described in Section
for other AFI/SAFI(s). 5 for other AFI/SAFI(s).
8. Security Consideration 8. Security Considerations
The security considerations pertaining to the original BGP protocol The security considerations pertaining to the BGP protocol [RFC4271]
remain relevant. remain relevant.
In addition, the mechanism described here renders LSRs that implement In addition, the mechanism described here renders LSRs that implement
it vulnerable to additional denial-of-service attacks as follows: it vulnerable to additional denial-of-service attacks as follows:
An intruder may impersonate a BGP peer in order to force a failure An intruder may impersonate a BGP peer in order to force a failure
and reconnection of the TCP connection, but where the intruder and reconnection of the TCP connection, where the intruder sets
sets the Forwarding State (F) bit (as defined in [1]) to 0 on the Forwarding State (F) bit (as defined in [RFC4724]) to 0 on
reconnection. This forces all labels received from the peer to be reconnection. This forces all labels received from the peer to be
released. released.
An intruder could intercept the traffic between BGP peers and An intruder could intercept the traffic between BGP peers and
override the setting of the Forwarding State (F) bit to be set to override the setting of the Forwarding State (F) bit to be set to
0. This forces all labels received from the peer to be released. 0. This forces all labels received from the peer to be released.
All of these attacks may be countered by use of an authentication All of these attacks may be countered by use of an authentication
scheme between BGP peers, such as the scheme outlined in [RFC2385]. scheme between BGP peers, such as the scheme outlined in [RFC2385].
As with BGP carrying labels, a security issue may exist if a BGP As with BGP carrying labels, a security issue may exist if a BGP
implementation continues to use labels after expiration of the BGP implementation continues to use labels after expiration of the BGP
session that first caused them to be used. This may arise if the session that first caused them to be used. This may arise if the
upstream LSR detects the session failure after the downstream LSR has upstream LSR detects the session failure after the downstream LSR has
released and re-used the label. The problem is most obvious with the released and re-used the label. The problem is most obvious with the
platform-wide label space and could result in mis-routing of data to platform-wide label space and could result in misrouting of data to
other than intended destinations and it is conceivable that these destinations other than those intended; and it is conceivable that
behaviors may be deliberately exploited to either obtain services these behaviors may be deliberately exploited, either to obtain
without authorization or to deny services to others. services without authorization or to deny services to others.
In this document, the validity of the BGP session may be extended by In this document, the validity of the BGP session may be extended by
the Restart Time, and the session may be re-established in this the Restart Time, and the session may be re-established in this
period. After the expiry of the Restart Time the session must be period. After the expiry of the Restart Time, the session must be
considered to have failed and the same security issue applies as considered to have failed, and the same security issue applies as
described above. described above.
However, the downstream LSR may declare the session as failed before However, the downstream LSR may declare the session as failed before
the expiration of its Restart Time. This increases the period during the expiration of its Restart Time. This increases the period during
which the downstream LSR might reallocate the label while the which the downstream LSR might reallocate the label while the
upstream LSR continues to transmit data using the old usage of the upstream LSR continues to transmit data using the old usage of the
label. To reduce this issue, this document requires that labels are label. To reduce this issue, this document requires that labels are
not re-used until for at least the Restart Time. not re-used until at least the Restart Time.
9. Intellectual Property Considerations
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 (2005).
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. Acknowledgments 9. Acknowledgments
We would like to thank Chaitanya Kodeboyina and Loa Andersson for We would like to thank Chaitanya Kodeboyina and Loa Andersson for
their review and comments. The approach described in Section their review and comments. The approach described in Section 5 is
"Alternative procedures for the restarting LSR" is based on the idea based on the idea suggested by Manoj Leelanivas.
suggested by Manoj Leelanivas.
12. Normative References 10. References
[1] "Graceful Restart Mechanism for BGP", work in progress 10.1. Normative References
[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 Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC2385 Signature Option", RFC 2385, August 1998.
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
3", RFC2026 Protocol 4 (BGP-4)", RFC 4271, January 2006.
13. Non-normative References [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
January 2007.
[RFC3107] Rekhter, Y., Rosen, E., "Carrying Label Information in 10.2. Informative References
BGP-4", RFC3107
14. Author Information [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
BGP-4", RFC 3107, May 2001.
Authors' Addresses
Yakov Rekhter Yakov Rekhter
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: yakov@juniper.net
EMail: yakov@juniper.net
Rahul Aggarwal Rahul Aggarwal
Juniper Networks Juniper Networks
1194 N.Mathilda Ave 1194 N.Mathilda Ave
Sunnyvale, CA 94089 Sunnyvale, CA 94089
e-mail: rahul@juniper.net
EMail: rahul@juniper.net
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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, THE IETF TRUST 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.
Intellectual Property
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 66 change blocks. 
231 lines changed or deleted 193 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/