[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                              N. Dubois
                                                  B. Decraene
                                                B. Fondeviole
Internet Draft                                France Telecom R&D



Document: draft-dubois-bgp-pm-reqs-01.txt            February 2005


Expiration Date: August 2005


          Requirements for planned maintenance of BGP sessions

                      draft-dubois-bgp-pm-reqs-01.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 end of 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. If possible, the proposed solution
   should be designed in order to avoid transient routing loops.

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

   Step 3:
   Once maintenance is terminated, if possible a mechanism should be
   implemented to gracefully restore to the original state avoiding
   transient routing loops.

   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 in both ASes 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. If possible, the proposed solution should be designed
   in order to avoid transient routing loops.





Dubois                   Expires September 2004                 [Page 3]


Internet Draft    BGP planned maintenance requirements     February 2005


   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. If possible, the proposed solution should be
   designed in order to avoid transient routing loops.


   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.

   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;
        -Case of PE <-> CE links in a MPLS-VPN environment.

   f/The proposed solution should not change the BGP convergence
   behaviour for the ASes exterior to the maintenance process. An
   incremental deployment on a per AS basis must be possible.


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

Dubois                   Expires September 2004                 [Page 4]


Internet Draft    BGP planned maintenance requirements     February 2005


   two SP routers, denoted as "ASBR1" and "ASBR2", ASBR1 and ASBR2 are
   in the same AS and owned by the same service provider.



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


Dubois                   Expires September 2004                 [Page 5]


Internet Draft    BGP planned maintenance requirements     February 2005


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


Dubois                   Expires September 2004                 [Page 6]


Internet Draft    BGP planned maintenance requirements     February 2005



   E-BGP topology "2PE <-> 2CE"

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

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


Dubois                   Expires September 2004                 [Page 7]


Internet Draft    BGP planned maintenance requirements     February 2005


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"

   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

Dubois                   Expires September 2004                 [Page 8]


Internet Draft    BGP planned maintenance requirements     February 2005



   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.




        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

Dubois                   Expires September 2004                 [Page 9]


Internet Draft    BGP planned maintenance requirements     February 2005


   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.

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, Olivier
   Bonaventure, Xavier Vinet, 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.




Dubois                   Expires September 2004                [Page 10]


Internet Draft    BGP planned maintenance requirements     February 2005


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
   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 (2004).  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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/