Network Working Group                               N. Dubois
                                                  B. Decraene
                                                B. Fondeviole
Internet Draft                                 France Telecom
                                                          R&D
Document: draft-dubois-bgp-pm-reqs-00.txt       February 2005
Expiration Date: August 2005


          Requirements for planned maintenance of BGP sessions

                      draft-dubois-bgp-pm-reqs-00.txt


Status of this Memo

 By submitting this Internet-Draft, I certify that any applicable
 patent or other IPR claims of which I am aware have been disclosed,
 and any of which I become aware will be disclosed, in accordance
 with RFC 3668.

 This document is an Internet-Draft and is in full conformance with
 all provisions of Section 10 of RFC2026. 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
 http://www.ietf.org/shadow.html.

Abstract

 To ease the maintenance of BGP-4 [BGP-4] sessions and limit the
 amount of traffic that is lost during planned maintenance operations
 on routers, a solution is required in order to gracefully shutdown a
 router or a session.


 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 [1].

Dubois                   Expires September 2004                 [Page 1]


Internet Draft    BGP planned maintenance requirements     February 2005





   Table of Contents

   1. Introduction.........................................2
   2. Problem statement....................................2
   3. Goal and requirements................................3
   4. Scope................................................4
   5. Example..............................................4
   6. Reference topologies.................................5
   6. Security Considerations..............................8
   7. Intellectual Property Statement......................9
   8. Security Considerations..............................9
   9. Acknowledgments......................................10
   10.References...........................................11
   11.Authors' Addresses:..................................11



   1.   Introduction


   The BGP-4 protocol is heavily used in service provider networks. For
   resiliency purposes, most of the IP network operators deploy
   redundant routers and BGP sessions to minimize the risk of BGP
   session breakdown toward their customers or peers.
   In a context where a Service Provider wants to upgrade or remove a
   particular router that maintains one or several BGP sessions, our
   requirement is to avoid customer or peer traffic loss as much as
   possible. It should be made possible to reroute the customer or peer
   traffic before the maintenance operation.

   Currently, the BGP-4 specification does not include any operation to
   prevent traffic loss in case of planned maintenance.

   A successful approach of such mechanism should indeed minimize the
   loss of traffic in most foreseen maintenance contexts and be easily
   deployable, if possible backward compatible.



   2.   Problem statement

   Currently, when one or more BGP session needs to be shut down, a BGP
   NOTIFICATION message is sent to the peer and the session is then
   closed. A protocol convergence is then triggered both in the local
   router and in the peer and if possible an alternate route to the
   destination is selected.

   This behavior is not satisfactory in a maintenance situation because
   customer traffic that was directed toward the removed next-hops is


Dubois                   Expires September 2004                 [Page 2]


Internet Draft    BGP planned maintenance requirements     February 2005


   lost until the BGP convergence. As it is a planned operation, a make
   before break solution should be possible.

   As maintenance operations are frequent in large networks, the global
   availability of the network is significantly impaired by the BGP
   maintenance issues.


        3.   Goal and Requirements


   When some or all BGP sessions of a router needs to be
   administratively shut down, instead of sending a BGP NOTIFICATION
   message and/or tearing the TCP session down, our goal is to have the
   following two-step behavior:

   Step 1:
   A mechanism is implemented in order to gracefully reroute traffic
   toward and from the next-hop that is going to be maintained.
   By doing so, customers' flows are rerouted before the maintenance
   and no traffic is lost for all the destination prefixes for which an
   alternate route is available.

   Step 2:
   Once customer traffic is correctly rerouted BGP-4 sessions are
   shutdown.

   As a result, if another router provides an alternate path towards a
   set of destination prefixes, the IP flows are re-routed before the
   session termination and no traffic is lost during rerouting, since
   both the forwarding and the Loc-RIB tables are maintained while the
   peers are re-computing their forwarding tables.

   From the above goal we can derivate the following requirements:

   a/ A mechanism to advertise the maintenance action to all relevant
   routers is required.
   Are considered as relevant routers all the routers that are sending
   traffic to any BGP-NLRI whose next hops are the router undergoing
   maintenance.

   b/ It is required that the router implements a mechanism to maintain
   the forwarding for the NLRI undergoing maintenance until all
   reroutable traffic has been rerouted.

   c/ A mechanism may be needed to indicate the end of the graceful
   maintenance operation.

   d/ An Internet wide convergence is not required. However the local
   AS and its direct peers must be able to gracefully converge before
   the service interruption.

Dubois                   Expires September 2004                 [Page 3]


Internet Draft    BGP planned maintenance requirements     February 2005



   e/ The proposed solution should be applicable to all kinds of BGP-4
   sessions (e-BGP, i-BGP and i-BGP client) and any address family. If
   the BGP-4 implementation allows closing a sub-set of AFIs carried in
   a MP-BGP-4 session, this mechanism is applicable to this sub-set of
   AFI identifiers. However we see the two following particular case as
   a priority:
        -Case of the reload of one AS border router;
        -Case of the maintenance of one particular e-BGP sessions.

   f/The proposed solution should not degrade the BGP convergence
   properties.


        4.  Scope

   Purpose of this requirement is neither to solve all the convergence
   issues that may arise within the internet nor to modify the
   convergence properties of the BGP protocol.

   The example section illustrates one typical and important case where
   this requirement should be applicable and tries to make it more
   understandable.

   In addition a topologies section presents some BGP topologies (both
   i-BGP and e-BGP) and confronts them to the requirement. These
   topologies should be used to test the proper behavior of any
   proposed solution.

        5.   Example

   Purpose of this section is to give one typical example and help the
   reader understand how graceful maintenance will enhance the
   availability of the inter provider BGP connections.

   Let us consider the following example (Figure 1 below) where one
   customer router (denoted as "CUST" in the figure) is dual-homed to
   two SP routers, denoted as "ASBR1" and "ASBR2", ASBR1 and ASBR2 are
   in the same AS and owned by the same service provider.













Dubois                   Expires September 2004                 [Page 4]


Internet Draft    BGP planned maintenance requirements     February 2005





                   '
                   '
                   '
             AS1   '      AS2
                   '


             /-----------ASBR1-----P1----
            /                      |
           /                       |
       CUST                        |
           \                       |
    X.Y/16  \                      |
             \-----------ASBR2-----P2----


                   '
                   '
             AS1   '      AS2
                   '
                   Figure 1: Redundant peering example.

   Let's say traffic is normally conveyed by the CUST-ASBR1 link. and
   the SP wants to shutdown ASBR1 for maintenance purposes.

   The standard behavior is:
   1. ASBR1 tears all its BGP-4 sessions down.
   2. As a result, it removes all its BGP-4 routes from its RIB and FIB
   tables.
   3. Its BGP-4 peers remove all the routes that were announced by the
   shutting down peer.

   During its peers convergence :
        - CUST continues to send traffic to ASBR1. ASBR1 drops this
        traffic because it has no route to destination.
        - P1 continues to send traffic to ASBR1. ASBR1 drops this
        traffic because it has no route to X.Y/16.

   From the customer's point of view, the traffic is lost during BGP-4
   convergence time.


   With the new required behavior defined in this document:
   - On all its BGP-4 sessions, ASBR 1 signals a maintenance according
   to the requirement defined in a/
   - During this time it keeps forwarding customer traffic in both
   directions.
   - Once all reroutable traffic has been rerouted, ASBR1 closes its
   BGP-4 sessions with its peers.

Dubois                   Expires September 2004                 [Page 5]


Internet Draft    BGP planned maintenance requirements     February 2005


        No trafic is lost.


        6.   Reference topologies

   In order to qualify each proposed solutions, some typical BGP
   topologies are detailed.
   Proposed solutions should be applicable to all these BGP topologies.

       6.1   E-BGP topologies

   E-BGP topology 2PE <-> 1CE
                   '
             AS1   '      AS2
                   '
             /-----------Router
            /      '
           /       '
        Router    '
           \       '
            \      '
             \-----------Router
                   '
                   '
         AS1       '      AS2
                   '
   In this topology we have an asymmetric protection scheme between AS
   1 and AS 2:
        - On AS 2 side, two different routers have been used to connect
   to AS 1.
        - On AS 1 side, one single router with two BGP sessions is
   used.

   The requirement of section 4 should be applicable to:
        - Maintenance of one of the router of AS2
        - Maintenance of one of the two sessions between AS1 and AS2


   E-BGP topology 2PE <-> 2CE

                       '
                 AS1   '      AS2
                       '
          Router1,1-----------Router2,1
                       '
                       '
                       '
                       '
                       '
          Router1,2-----------Router2,2
                       '
             AS1       '      AS2

Dubois                   Expires September 2004                 [Page 6]


Internet Draft    BGP planned maintenance requirements     February 2005


                       '
   In this topology we have a symmetric protection scheme between AS 1
   and AS 2:
        - On both sides, two different routers have been used to
   connect AS 1 to AS 2.

   The requirement of section 4 should be applicable to:
        - Maintenance of any of the routers (in AS 1 or 2);
        - Maintenance of one of the two sessions between AS1 and AS2;

   E-BGP topology 2ISP <-> 2CE

                       '
                 AS1   '      AS2
                       '
          Router1-----------Router2,1
             |         '
             |         '
        '''''|''''''''''
             |         '
             |         '
          Router3-----------Router2,2
                       '
             AS3       '      AS2

   In this topology the protection scheme between AS 1 and AS 2 is not
   as clear as in the two previous topologies:
        - Depending on which routes are exchanged between the 3 ASes,
          some protection for some of the traffic may be possible.
        -
   The requirement of section 4 does not translate as easily as in the
   two previous topologies, as we do not require to propagate the
   maintenance advertisement in the internet.
   For instance if router2,2 requires a maintenance impacting router 3,
   router3 will be notified, however we do not require for Router1 to
   be notified.


       6.2. I-BGP topologies:

   We describe here some frequent i-BGP topologies, as the solution
   efficiency may vary depending on the i-BGP deployment choices. One
   can remark that having a maintenance advertisement for maintenance
   of the i-BGP session is not necessary: the administrator of one AS
   can use a lot of various means to gracefully reroute traffic.
   However maintenance of an e-BGP session needs to be propagated
   within the AS, so a solution to the requirement should work in any
   of the below topologies.

   i-BGP topology Full-Mesh


Dubois                   Expires September 2004                 [Page 7]


Internet Draft    BGP planned maintenance requirements     February 2005


 It is a full-mesh topology as represented below.


         P1 -------- P2
         |\         /|
         |  \     /  |
         |    \ /    |     AS 1
         |    / \    |
         |  /     \  |
        ASBR1------ASBR2
          \          /
           \        /
      ''''''\''''''/''''''''''''
             \    /
              \  /        AS 2
               CE

 We consider there is a full-mesh of i-BGP sessions between all
 routers.
 In case the session between CE and ASBR1 undergoes maintenance, it
 is required that all iBGP peers of ASBR1 reroute traffic to ASBR2
 before the session between ASBR1 and ASBR2 is shut down.

 i-BGP topology RR

         P1 RR----- P2 RR
         |\         /|
         |  \     /  |
         |    \ /    |     AS 1
         |    / \    |
         |  /     \  |
        ASBR1      ASBR2
          \          /
           \        /
      ''''''\''''''/''''''''''''
             \    /
              \  /        AS 2
               CE




 It is the case where some route reflectors are used to limit the
 number of i-BGP sessions.


 i-BGP topology hierarchical RR

 It is the case where some hierarchical route reflectors are used to
 limit the number of i-BGP sessions.


Dubois                   Expires September 2004                 [Page 8]


Internet Draft    BGP planned maintenance requirements     February 2005





        P1/hRR --------  P2/hRR
           |               |
           |               |
           |               |   AS 1
           |               |
           |               |

         P1/RR --------  P2/RR
           |               |
           |               |
           |               |   AS 1
           |               |
           |               |
          ASBR1           ASBR2
            \             /
             \           /
        ''''''\'''''''''/''''''''''''
               \       /
                \     /        AS 2
                   CE




   7.        Security Considerations

      Eventual security issues will be addressed in future versions of
   this draft.


   8.        Intellectual Property Statement

 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



Dubois                   Expires September 2004                 [Page 9]


Internet Draft    BGP planned maintenance requirements     February 2005


 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..

   8.1.        IPR Disclosure Acknowledgement

 By submitting this Internet-Draft, I certify that any applicable
 patent or other IPR claims of which I am aware have been disclosed,
 and any of which I become aware will be disclosed, in accordance
 with RFC 3668.


   9.        Acknowledgments

   The author would like to thank Christian Jacquenet, Vincent Gillet
   and Jean-Louis le Roux for the useful discussions on this subject,
   their review and comments.

   10.         References

     [BGP-4] Rekhter, Y. and T. Li (editors),
           "A Border Gateway protocol 4 (BGP-4)", Internet Draft
           draft-ietf-idr-bgp4-23.txt.


   11.         Author's Addresses

   Nicolas Dubois
   France Telecom R&D
   38-40 rue de general Leclerc
   92794 Issy Moulineaux cedex 9
   France
   Email: nicolas.dubois@francetelecom.com

   Bruno Decraene
   France Telecom R&D
   38-40 rue de general Leclerc
   92794 Issy Moulineaux cedex 9
   France
   Email: bruno.decraene@francetelecom.com

   Benoit Fondeviole
   France Telecom R&D

Dubois                   Expires September 2004                [Page 10]


Internet Draft    BGP planned maintenance requirements     February 2005


   38-40 rue de general Leclerc
   92794 Issy Moulineaux cedex 9
   France
   Email: benoit.fondeviole@francetelecom.com


   Full Copyright Statement

   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.





























                      Dubois                   Expires September 2004                [Page 11]