http://stupid.domain.name/ietf/

One document matched: draft-dubois-bgp-pm-reqs-00.txt

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

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

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]

PAFTECH AB 2003-2026

2026-04-23 05:59:35