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

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Tue, 9 Aug 2005 20:26:04 +0200

> > > If you send an email, you warn the human operators. If you send
BGP 
> > > messages, you warn the routers. I would prefer a model where BGP 
> > > routers  can automatically react to planned failures compared to a

> > > model where a human intervention is required to handle a planned
failure elsewhere.
> > >
> >
> > We do a lot of maintenances on our routers and we have a tool that 
> > automatically sends out mail to each contact that is on that 
> > particular router. The reason we do this is that people get irate
when 
> > sessions or traffic flows get disrupted (notice I said people, not 
> > routers) and they would like for prior notification so they aren't 
> > surprised when something alarms on their monitoring system. As
someone 
> > who is on-call, having a BGP session flap will almost always result
in 
> > a page. I'd rather my monitoring desk already be aware that there
will 
> > be an event and therefore, not page me.
> >
> > Also, for major peers etc, it is important to get notification, 
> > because it could be that we are in scheduled jeopardy and as such,
we 
> > can disallow that maintenance if necessary, esp. if we have backup 
> > capacity being down. Eg, one of my peers is upgrading code in 
> > frankfurt, and I'm upgrading code in london and frankfurt is acting
as a backup for london.
> > Having the routers understand the failure is completely useless to
me. 
> > I want people to understand so I can plan around the issue.
> 
> Well said Vijay.  This captures exactly why automation (signalled or
> invoked) can burn you.  Large networks where large amounts of 
> traffic will swing ( 500M to 1G+ ) when circuits go down 
> because of planned events must be coordinated at the human level.

I see two independent steps:
-1- Coordination at the human level using e-mail/phone/fax/letters.
-2- Having the networks/routers/BGP reroute the traffic with minimal
impact/loss.

The draft only deals with step 2. It doesn't mention that step 1 should
be skipped.

Coordination and carefull planification can only be done by humans.
IMO, BGP signaling can be done by routers without human intervention.
And signaling the future unreachability of some destinations before
closing the BGP session could be part of the BGP signaling. 

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

---

From: Paul Jakma <[email-masked]>
Date: Tue, 9 Aug 2005 20:46:09 +0100 (IST)

> 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

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.

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

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.