Subject: Re: [GROW] I-D ACTION:draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt

From: "UTTARO, JAMES (ATTLABS)" <[email-masked]>
Date: Tue, 4 May 2010 10:46:23 -0400

Could the authors provide further clarification on the following.

Is the intent to tie path availability and this functionality? I could
see other uses for path availability ie Load Balancing, Fast
Convergence, Minimize Path Hiding..

Availability of Paths. Is the draft proposing a mechanism for a speaker
to discover alternative paths ? There are a number of existing drafts
BGP Best External and Add-Paths for IPV4 and BGP Best External and a
Unique RD ( Not a draft ) per VRF Context ensure that we get the second
best paths to a ASBR Speaker ( Either PE or ASBR ). The draft does not
speak to the approach..

Make before Break. Is this a capabilities negotiation on a per session
basis? I would guess so.. 

Will the set of affected prefixes need to be sent in a BGP Withdrawal
message to the RRs from the initiator? If so what is the behavior? It
seems that all speakers would then select ASBR2 ( Your Example ).. So
there would be no change from the RR towards the iBGP topology?

Jim Uttaro 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, April 30, 2010 5:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [GROW] I-D
ACTION:draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts 
directories.
This draft is a work item of the Global Routing Operations Working Group
of the IETF.

	Title		: Requirements for the graceful shutdown of BGP
sessions
	Author(s)	: T. Takeda, B. Decraene, P. Francois, c.
pelsser, Z. Ahmad, A. Armengol
	Filename	:
draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt
	Pages		: 16
	Date		: 2010-4-30
	
The BGP protocol is heavily used in Service Provider networks both 
   for Internet and BGP/MPLS VPN services. For resiliency purposes, 
   redundant routers and BGP sessions can be deployed to reduce the 
   consequences of an AS Border Router or BGP session breakdown on 
   customers' or peers' traffic. However simply taking down or even 
   bringing up a BGP session for maintenance purposes may still induce 
   connectivity losses during the BGP convergence. This is no more 
   satisfactory for new applications (e.g. voice over IP, on line 
   gaming, VPN). Therefore, a solution is required for the graceful 
   shutdown of a (set of) BGP session(s) in order to limit the amount of
traffic loss during a planned shutdown. This document expresses 
   requirements for such a solution.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-bgp-graceful-shutdow
n-requirements-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: <[email-masked]>
Date: Wed, 12 May 2010 11:43:11 +0200

Hi Jim,

Thanks for your comments on the draft.

First of all, as your email is mostly discussing about solutions, I'd
like to remind that this draft defines the _requirements_ to gracefully
shutdown a BGP session. Then, indeed you're right that the next step for
these requirements is to initiate work and discussion about solutions to
fulfil them.

> UTTARO, JAMES (ATTLABS)
> Convergence, Minimize Path Hiding.

This draft expresses requirements to be able to shutdown a BGP session
with no / limited impact on the traffic. It does not take position
regarding solutions to achieve these requirements.

I'm not sure to exactly see what you mean by "tie path availability and
this functionality". I can see 2 interpretations for your "path
availability":
1) Indeed, as indicated in the draft (section 3.2. Causes of packet
loss) one reason for the packets loss is the "lack of an alternate path
on some routers".
2) One (range of) solutions to address this is to advertise (all the
time), multiple paths per prefix (and more specifically the back up
path). But there could be also other solutions. Such as to get those
backup paths only at the time of the shutdown, and only for the specific
prefixes needing a backup path. 

On a side note, I also agree with you that path availability has
multiple applicabilities (possibly depending on which additional path
you select to advertise).

> speak to the approach.

The draft does not propose a mechanism to discover alternative path as
the draft is a requirement draft and not a solution one.
It does say that one reason for packet loss when shutting down or even
setting up a BGP session is path unavailability. Indeed, as you pointed
out, there are existing and proposed new ways to advertise multiple path
per prefixes. The draft was not meant to compare existing solutions or
propose new ones but to define the requirements. Then, hopefully, there
will be a discussion about solutions. We'd be happy to discuss the
solutions with you if you want. I would suggest a different thread as
this is not really related to the requirements draft. May be more
related to the following drafts
http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-01 or
http://tools.ietf.org/html/draft-vvds-add-paths-analysis-00
 or
http://tools.ietf.org/id/draft-uttaro-idr-add-paths-guidelines-00.txt 

I think section 4.1 of draft-ietf-grow-bgp-gshut-01 would be
specifically relevant to initiate the discussion.

> basis? I would guess so.

You're right that this is enabled on a per session basis. And besides,
the draft call for a possible incremental deployment with incremental
benefit on a per AS and BGP session basis: " e)   An incremental
deployment on a per AS or per BGP session basis SHOULD be made possible.
In case of partial deployment the proposed solution SHOULD incrementally
improve the maintenance process."

If by "capabilities negociation" you mean a BGP capability, again this
draft is not about solution. As an example of solution,
draft-ietf-grow-bgp-gshut-01 does not use BGP capability.

> there would be no change from the RR towards the iBGP topology?

This requirement draft does not propose a solution. You may wish to look
at the draft http://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-01
which seem related to your question. We would welcome comments on it.

Thanks
Regards,
Bruno

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

---

From: <[email-masked]>
Date: Wed, 12 May 2010 11:53:49 +0200

Hi all,

This new version should take into account all comments received during
the WG last call.
More specifically all comments received on the list and off line up to
Friday, April 30, 2010.
Please tell me if I missed one of your comments.

Thanks
Regards,
Bruno

> Sent: Friday, April 30, 2010 11:15 PM
> Subject: [GROW] I-D ACTION:draft-ietf-grow-bgp-graceful-shutdown-
> requirements-02.txt
> 
sessions
> 	Author(s)	: T. Takeda, B. Decraene, P. Francois, c.
pelsser, Z.
> Ahmad, A. Armengol
draft-ietf-grow-bgp-graceful-shutdown-requirements-
> 02.txt
n-
> requirements-02.txt