Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc

From: [email-masked]
Date: Wed, 10 Aug 2005 01:30:45 -0400

Pls see some comments inline.
cheers,
Zubair

Zubair Ahmad
Equant - Network Technology & Architecture
13775 McLearen Road, Oak Hill VA
Phone: +1-703-375-8152

            Paul Jakma <[email-masked]>                                                                                                 
            Sent by: [email-masked]                                                                                              
            08/09/2005 03:46 PM                To: DECRAENE Bruno RD-CORE-ISS <[email-masked]>                       
                                               cc: [email-masked], vijay gill <[email-masked]>, Olivier Bonaventure                 
                                                  <[email-masked]>                                                         
                                               bcc:                                                                                    
                                               Subject:  RE: [idr] BGP planned maintenance requirements as an IDR WG doc               

On Tue, 9 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> And signaling the future unreachability of some destinations before
> closing the BGP session could be part of the BGP signaling.

Just to reiterate points made already (given above comment suggets it
doesn't seem to have gotten through):

- Means for signalling /already/ exist within BGP, either:
      - (NOTIFY,CEASE), an implicit withdraw of all advertised routes
           as per normal when you shutdown a session.
      - obviously, withdrawing individual specific prefixes

- Hence: No support in protocol is directly required for an
   implementation to signal shutdown well before it actually performs
   its shut down

ZA>> Well the signalling of maintenance action is definitely needed.
However, it may rely on implicit BGP behavior (such as implicit Withdraw as
you mention).  The draft already clearly mentions that such signalling
mechanism may be either "implicit" or "explicit" (see section 4 - Goals &
Requirements).  Since this is only a requirements draft, I believe we
should better focus on clarifying and refining the requirements for planned
maintenance and leave the discussion about potential solutions for the next
step (solution proposal/draft)..

There is no /immediate/ need for protocol changes for the one "trick"
we've discussed here so far.

The route-reflector case you raised is a different thing imho,
requires full-reflection really and there are other drafts looking at
that.

ZA>> I agree that it would be nice if we can achieve the desired behavior
(i.e. graceful shutdown that eliminates or minimizes packet loss during BGP
convergence) using the so called 'trick' implemented only locally (without
requiring any protocol extensions on the peers). However, such
implementation must cover the various topologies of interest that are
presented in the draft.  Again, I would suggest to leave this discussion on
possible soutions for the Solutions draft.

The main immediate thing to look at is interaction of above
implementation trick with the GR draft, maybe GR needs some changes
to allow it to work nicely with above. Immediate in the "while GR is
still a draft" sense ;). (this trick has some incompatibilies with GR
it seems to me. If GR is enabled, the remote peer will assume your
forwarding plane is staying up, initially at least).

ZA>> Interaction with GR is dependent on the type of solution (trick) that
gets implemented.  I think we should include this point in the requirement
draft that any solutions for BGP Graceful Shutdown must consider & ensure
compatibility with BGP GR (if GR capability is enabled).

Other considerations:

- The delay between signalling shutdown and shutting down forwarding
probably should be larger than the time for all routers in your iBGP
to converge on the new set of routes, not the time for your immediate
peers. This delay factor is likely something an operator can
empirically determine for themselves. It may be interesting to
examine how the protocol could determine this automatically at some
stage in the future (once the 'trick' is implemented widely and there
is experience of it).

- Another thing to consider (or even, is being actively considered by
others, at least for IGP) is stuff like that 'Ordered FIB removal'
work and whether some of its tricks could apply to iBGP. Eg, as we've
discussed that shutdown of protocol should ideally occur before
forwarding shutdown, that draft also suggests that on starting up it
might be a good idea to 'listen but not speak' initially, before
proceeding to announce anything (self-originated or not). Ie
stabilise your forwarding plane first, before telling anyone they may
forward through you (maybe).

I suspect right now what is needed are implementations of the 'wait
between CEASE and forwarding shutdown' and field experience of it,
given no protocol work is actually needed, before proceeding
contemplating what actual protocol changes/additions would or would
not be useful.

I.e., right now, this is probably something to discuss with your
vendor, no?

regards,
--
Paul Jakma  [email-masked]     [email-masked]    Key ID: 64A2FF6A
Fortune:
If *I* had a hammer, there'd be no more folk singers.

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "Alok" <[email-masked]>
Date: Wed, 10 Aug 2005 16:38:29 +0530

> compatibility with BGP GR (if GR capability is enabled).

Can someone please figure out how one can possibly *know* that there is no
traffic coming from peers?
How about: dont allow shutdown command if interface stats are increasing or
selective links, which can be specified are still up?

---

From: Paul Jakma <[email-masked]>
Date: Wed, 10 Aug 2005 13:17:17 +0100 (IST)

Hi Zubair,

On Wed, 10 Aug 2005, [email-masked] wrote:

> only a requirements draft, I believe we should better focus on 
> clarifying and refining the requirements for planned maintenance 
> and leave the discussion about potential solutions for the next 

Horse before cart please.

At least one signalling method exists (CEASE) - why not implement 
CEASE+wait first and get some experience of it before considering 
what protocol changes could make it work better?

I don't see how one can even know what the requirements are at this 
point in time.

Get some operational experience of the 'CEASE + wait + shutdown 
forwarding' solution, only then can you know what would be useful to 
add to the actual BGP protocol.

> ZA>> I agree that it would be nice if we can achieve the desired 
> behavior (i.e. graceful shutdown that eliminates or minimizes 
> packet loss during BGP convergence) using the so called 'trick' 
> implemented only locally (without requiring any protocol extensions 
> on the peers). However, such implementation must cover the various 
> topologies of interest that are presented in the draft.

It does. The wait period just has to be long enough to allow everyone 
else to converge.

> Again, I would suggest to leave this discussion on possible 
> soutions for the Solutions draft.

What solutions draft?

> ZA>> Interaction with GR is dependent on the type of solution 
> (trick) that gets implemented.  I think we should include this 
> point in the requirement draft that any solutions for BGP Graceful 
> Shutdown must consider & ensure compatibility with BGP GR (if GR 
> capability is enabled).

I'd like to see:

- implementation of the CEASE and wait solution
- some field experience of it
- maybe kind of informational ID discussing the previous two points

*Then* and only then is it sensible to start talking about a 
potential requirements draft for tackling any shortcomings in BGP wrt 
maintainance, and possible suitable changes to it.

Understand the problem first please (surely?).

My recursion detector is telling me i've now been here before several 
times in this thread, so I'll bow out.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	What is purple and concord the world?
A:	Alexander the Grape.

---

From: "Alok" <[email-masked]>
Date: Wed, 10 Aug 2005 18:06:04 +0530

hi Paul,

just a couple of questions?

Why cant you simply what for the GR timers to time out before actually
pulling the router out of service?

In other words GR makes the assumption AFAIK that the remote router has to
come up in sometime.

if it doesnt, BGP declares the peer as down.

Simply dont pull the router out of service till the timers expire?
The remote end would automatically discover the peer is down in that time.
(coupled with the other post where you could track the incoming traffic on
forwarding plane to ensure static/policy routed peers also change their
routes)

-thanks
Alok
----- Original Message ----- 
From: "Paul Jakma" <[email-masked]>
To: <[email-masked]>
Cc: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>;
<[email-masked]>; <[email-masked]>; "Olivier Bonaventure"
<[email-masked]>; "vijay gill" <[email-masked]>
Sent: Wednesday, August 10, 2005 5:47 PM
Subject: RE: [idr] BGP planned maintenance requirements as an IDR WG doc