doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc4781.txt b/doc/rfc/rfc4781.txt
new file mode 100644
index 0000000..9811c10
--- /dev/null
+++ b/doc/rfc/rfc4781.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group                                         Y. Rekhter
+Request for Comments: 4781                                   R. Aggarwal
+Category: Standards Track                               Juniper Networks
+                                                            January 2007
+
+
+              Graceful Restart Mechanism for BGP with MPLS
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2007).
+
+Abstract
+
+   A mechanism for BGP that helps minimize the negative effects on
+   routing caused by BGP restart has already been developed and is
+   described in a separate document ("Graceful Restart Mechanism for
+   BGP").  This document extends this mechanism to minimize the negative
+   effects on MPLS forwarding caused by the Label Switching Router's
+   (LSR's) control plane restart, and specifically by the restart of its
+   BGP component when BGP is used to carry MPLS labels and the LSR is
+   capable of preserving the MPLS forwarding state across the restart.
+
+   The mechanism described in this document is agnostic with respect to
+   the types of the addresses carried in the BGP Network Layer
+   Reachability Information (NLRI) field.  As such, it works in
+   conjunction with any of the address families that could be carried in
+   BGP (e.g., IPv4, IPv6, etc.).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 1]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Specification of Requirements ..............................3
+   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
+
+   In the case where a Label Switching Router (LSR) could preserve its
+   MPLS forwarding state across restart of its control plane, and
+   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
+   the LSPs going through that LSR (and specifically, the LSPs
+   established by BGP) after failure or restart of the BGP component of
+   the control plane.  In this document, we describe a mechanism that
+   allows this goal to be accomplished.  The mechanism described in this
+   document works in conjunction with the mechanism specified in
+   [RFC4724].  The mechanism described in this document places no
+   restrictions on the types of addresses (address families) that it can
+   support.
+
+   The mechanism described in this document is applicable to all LSRs,
+   both those with the ability to preserve forwarding state during BGP
+   restart and those without it (although the latter need to implement
+   only a subset of this mechanism).  Supporting a subset of the
+   mechanism described here by the LSRs that cannot preserve their MPLS
+   forwarding state across the restart would not reduce the negative
+   impact on MPLS traffic caused by their control plane restart.
+   However, the impact would be minimized if their neighbor(s) are
+   capable of preserving the forwarding state across the restart of
+   their control plane, and if they implement the mechanism described
+   here.  The subset includes all the procedures described in this
+   document, except the procedures in Sections 4.1, 4.2, 4.3, and 5.
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 2]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+   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>
+
+   In the context of this document, the forwarding state that is
+   referred to in [RFC4724] means MPLS forwarding state, as defined
+   above.  The term "next hop" refers to the next hop as advertised in
+   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
+   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)
+   to create new <FEC -> label> bindings after restart, while
+   temporarily maintaining MPLS forwarding state corresponding to both
+   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 forwarding state that the LSR preserved across the restart, the
+   labels from that state cannot be used to create new local label
+   bindings (but could be used to reconstruct the existing bindings, as
+   per procedures in Section 4).  Finally, for each next hop, if the
+   next hop is reachable via a Label Switched Path (LSP), then the
+   restarting LSR MUST be able to preserve the MPLS forwarding state
+   associated with that LSP across the restart.
+
+   In the scenario where label binding on an LSR is created/maintained
+   not only by the BGP component of the control plane, but also by other
+   protocol components (e.g., LDP, RSVP-TE), and where the LSR supports
+   restart of the individual components of the control plane that
+   create/maintain label binding (e.g., restart of BGP, but no restart
+   of LDP), the LSR MUST be able to preserve across the restart the
+   information about which protocol has assigned which labels.
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 3]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+   After the LSR restarts, it MUST follow the procedures as specified in
+   [RFC4724].  In addition, if the LSR is able to preserve its MPLS
+   forwarding state across the restart, the LSR SHOULD advertise this to
+   its neighbors by appropriately setting the Flag for Address Family
+   field in the Graceful Restart Capability for all applicable AFI/SAFI
+   pairs.
+
+3.  Capability Advertisement
+
+   An LSR that supports the mechanism described in this document
+   advertises this to its peer by using the Graceful Restart Capability,
+   as specified in [RFC4724].  The Subsequent Address Family Identifier
+   (SAFI) in the advertised capability MUST indicate that the Network
+   Layer Reachability Information (NLRI) field carries not only
+   addressing Information, but also labels (see [RFC3107] for an example
+   of where NLRI carries labels).
+
+4.  Procedures for the Restarting LSR
+
+   Procedures in this section apply when a restarting LSR is able to
+   reconstruct the same <FEC -> label> bindings as the LSR had prior to
+   the restart.
+
+   The procedures described in this section are conceptual and do not
+   have to be implemented precisely as described, as long as the
+   implementations support the described functionality and their
+   externally visible behavior is the same.
+
+   Once the LSR completes its route selection (as specified in Section
+   4.1, "Procedures for the Restarting Speaker", of [RFC4724]), then in
+   addition to the those procedures, the LSR performs one of the
+   following:
+
+4.1.  Case 1
+
+   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
+   (c) the LSR advertises this route with itself as the next hop.
+
+   In this case, the LSR searches its MPLS forwarding state (the one
+   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
+   found, the LSR no longer marks the entry as stale.  In addition, if
+   the entry is of type <incoming label, (outgoing label, next hop)>
+   rather than <Forwarding Equivalence Class (FEC), (outgoing label,
+   next hop)>, the LSR uses the incoming label from the entry when
+   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
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 4]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+   label when advertising the route to its neighbors (assuming that
+   there are neighbors to which the LSR has to advertise the route with
+   a label).
+
+4.2.  Case 2
+
+   The following applies when (a) the best route selected by the LSR was
+   received either without a label, with an Implicit NULL label, or the
+   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-
+   Implicit NULL) label for the route.
+
+   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
+   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
+   when advertising the route to its neighbors.  If no such entry is
+   found, the LSR allocates a new label when advertising the route to
+   its neighbors.
+
+   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
+   not the case and the LSR generates a unique label per each such
+   route, then the LSR needs to preserve across the restart not only
+   <incoming label, (outgoing label, next hop)> mapping, but also the
+   Forwarding Equivalence Class (FEC) associated with this mapping.  In
+   such a case the LSR would search its MPLS forwarding state for an
+   entry that (a) indicates label pop (means no outgoing label), (b)
+   indicates that the next hop equal to the next hop of the route, and
+   (c) has the same FEC as the route.  If such an 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 found, the LSR allocates
+   a new label when advertising the route to its neighbors.
+
+4.3.  Case 3
+
+   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
+   particular NLRI, just uses the label that was received with that
+   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
+   not allocate a label for that route.
+
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 5]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+5.  Alternative Procedures for the Restarting LSR
+
+   In this section, we describe an alternative to the procedures
+   described in Section "Procedures for the restarting LSR".
+
+   Procedures in this section apply when a restarting LSR does not
+   reconstruct the same <FEC -> label> bindings as the LSR had prior to
+   the restart, but instead creates new <FEC -> label> bindings after
+   restart, while temporarily maintaining MPLS forwarding state
+   corresponding to both the bindings prior to the restart, as well as
+   to the newly created bindings.
+
+   The procedures described in this section require that for the use by
+   BGP graceful restart, the LSR SHOULD have (at least) as many
+   unallocated labels as labels allocated for the <FEC -> label>
+   bindings distributed by BGP.  The latter forms the MPLS forwarding
+   state that the LSR managed to preserve across the restart.  The
+   former is used for allocating labels after the restart.
+
+   To create (new) local label bindings after the restart, the LSR uses
+   unallocated labels (this is pretty much the normal procedure).
+
+   The LSR SHOULD retain the MPLS forwarding state that the LSR
+   preserved across the restart at least until the LSR sends an
+   End-of-RIB marker to all of its neighbors (by that time the LSR
+   already completed its route selection process, and also advertised
+   its Adj-RIB-Out to its neighbors).  The LSR MAY retain the forwarding
+   state even a bit longer (the amount of extra time MAY be controlled
+   by configuration on the LSR), so as to allow the neighbors to receive
+   and process the routes that have been advertised by the LSR.  After
+   that, the LSR SHOULD delete the MPLS forwarding state that it
+   preserved across the restart.
+
+   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 --
+   one that was retained from prior to restart, and another that was
+   created after the restart.  Once the LSR completes its restart, the
+   former will be deleted.  However, both of these bindings would have
+   the same outgoing label (and the same next hop).
+
+6.  Procedures for a Neighbor of a Restarting LSR
+
+   The neighbor of a restarting LSR (the receiving router terminology
+   used in [RFC4724]) follows the procedures specified in [RFC4724].  In
+   addition, the neighbor treats the MPLS labels received from the
+   restarting LSR the same way that it treats the routes received from
+   the restarting LSR (both prior and after the restart).
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 6]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+   Replacing the stale routes by the routing updates received from the
+   restarting LSR involves replacing/updating the appropriate MPLS
+   labels.
+
+   In addition, if the Flags in the Graceful Restart Capability received
+   from the restarting LSR indicate that the LSR wasn't able to retain
+   its MPLS state across the restart, the neighbor SHOULD immediately
+   remove all the NLRI and the associated MPLS labels that it previously
+   acquired via BGP from the restarting LSR.
+
+   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
+   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,
+   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.
+
+   To minimize the potential misrouting caused by the label change, when
+   creating a new <label, FEC> binding, the LSR SHOULD pick up the least
+   recently used label.  Once an LSR releases a label, the LSR SHALL NOT
+   re-use this label for advertising a <label, FEC> binding to a
+   neighbor that supports graceful restart for at least the Restart
+   Time, as advertised by the neighbor to the LSR.  This rule SHALL
+   apply to any label release at any time.
+
+7.  Comparison between Alternative Procedures for the Restarting LSR
+
+   Procedures described in Section 4 involve more computational overhead
+   on the restarting router than do the procedures described in Section
+   5.
+
+   Procedures described in Section 5 require twice as many labels as
+   those described in Section 4.
+
+   Procedures described in Section 4 cause fewer changes to the MPLS
+   forwarding state in the neighbors of the restarting router than the
+   procedures described in Section 5.
+
+   In principle, it is possible for an LSR to use procedures described
+   in Section 4 for some AFI/SAFI(s) and procedures described in Section
+   5 for other AFI/SAFI(s).
+
+
+
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 7]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+8.  Security Considerations
+
+   The security considerations pertaining to the BGP protocol [RFC4271]
+   remain relevant.
+
+   In addition, the mechanism described here renders LSRs that implement
+   it vulnerable to additional denial-of-service attacks as follows:
+
+      An intruder may impersonate a BGP peer in order to force a failure
+      and reconnection of the TCP connection, where the intruder sets
+      the Forwarding State (F) bit (as defined in [RFC4724]) to 0 on
+      reconnection.  This forces all labels received from the peer to be
+      released.
+
+      An intruder could intercept the traffic between BGP peers and
+      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.
+
+   All of these attacks may be countered by use of an authentication
+   scheme between BGP peers, such as the scheme outlined in [RFC2385].
+
+   As with BGP carrying labels, a security issue may exist if a BGP
+   implementation continues to use labels after expiration of the BGP
+   session that first caused them to be used.  This may arise if the
+   upstream LSR detects the session failure after the downstream LSR has
+   released and re-used the label.  The problem is most obvious with the
+   platform-wide label space and could result in misrouting of data to
+   destinations other than those intended; and it is conceivable that
+   these behaviors may be deliberately exploited, either to obtain
+   services without authorization or to deny services to others.
+
+   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
+   period.  After the expiry of the Restart Time, the session must be
+   considered to have failed, and the same security issue applies as
+   described above.
+
+   However, the downstream LSR may declare the session as failed before
+   the expiration of its Restart Time.  This increases the period during
+   which the downstream LSR might reallocate the label while the
+   upstream LSR continues to transmit data using the old usage of the
+   label.  To reduce this issue, this document requires that labels are
+   not re-used until at least the Restart Time.
+
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 8]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+9.  Acknowledgments
+
+   We would like to thank Chaitanya Kodeboyina and Loa Andersson for
+   their review and comments.  The approach described in Section 5 is
+   based on the idea suggested by Manoj Leelanivas.
+
+10.  References
+
+10.1.  Normative References
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
+             Signature Option", RFC 2385, August 1998.
+
+   [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
+             Protocol 4 (BGP-4)", RFC 4271, January 2006.
+
+   [RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J., and Y.
+             Rekhter, "Graceful Restart Mechanism for BGP", RFC 4724,
+             January 2007.
+
+10.2.  Informative References
+
+   [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in
+             BGP-4", RFC 3107, May 2001.
+
+Authors' Addresses
+
+   Yakov Rekhter
+   Juniper Networks
+   1194 N.Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: yakov@juniper.net
+
+
+   Rahul Aggarwal
+   Juniper Networks
+   1194 N.Mathilda Ave
+   Sunnyvale, CA 94089
+
+   EMail: rahul@juniper.net
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                     [Page 9]
+
+RFC 4781           Graceful Restart Mechanism for BGP       January 2007
+
+
+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.
+
+
+
+
+
+
+
+Rekhter & Aggarwal          Standards Track                    [Page 10]
+