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

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Mon, 8 Aug 2005 14:33:54 +0200

> > A final thought: Does the second case even require any protocol
work?
> > 
> > It strikes me that the second case can easily be handled entirely 
> > within the confines of existing specified BGP, by simply having an 
> > implementation take the relevant BGP session(s) down (ie sending a
> > CEASE) and just waiting a while to let the relevant remote peers 
> > update their routes, before proceeding with actually removing the 
> > routes from RIB and FIB and then restarting.
> > 
> > I reckon the most protocol work this needs is just to have 
> > implementations advertise a "I reckon I need X milliseconds to clear
Y 
> > number of routes" or even just "Hey, if you're going down, try give
me 
> > X seconds advance notice if you can" capability, which could be used

> > to supercede any implementation specific default.
> 
> As this mail is the closest to my line of understanding this 
> problem let me ask a very basic question of course assuming 
> that GR is for "the future" ...
> 
> Would it not be enough to simply withdraw the advertised 
> routes before bringing the session down towards given peer ? 
> If operator enters shutdown on BGP session this should not 
> trigger any immediate BGP/TCP action .. instead one could 
> send MP_UNREACH then at some decent timeout actually bring 
> the sessions down.

It's indeed a possible solution. In fact it's exactly what we proposed
in "draft-dubois-bgp-planned-maintenance-00.txt" in San Diego.
Unfortunately, it's not working for all the iBGP topologies:
- If you have a full iBGP mesh, all your peers already know the backup
path and will select it. So this will work fine.
- If you have RRs, iBGP routers (including your RR) may not have the
backup path. The RR will propagate the withdraw and the destination will
be removed from the RIB. 

> No protocol changes required.

There's lot of possible ways to improve the current eBGP shutdowns.
Could we possibly agree on a solution?
We would all prefer that this solution does require any protocol change.
In that case, a BCP could document the solution.

Then, each ISP could use that solution for each maintenance. Or
preferably, vendors will automate the solution.

> All it would take is a local implementation little twick ;).

That would be fine for me.

Cheers,
Bruno

> Cheers,
> R.

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

---

From: Paul Jakma <[email-masked]>
Date: Mon, 8 Aug 2005 14:09:23 +0100 (IST)

On Mon, 8 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> - If you have RRs, iBGP routers (including your RR) may not have 
> the backup path. The RR will propagate the withdraw and the 
> destination will be removed from the RIB.

So you'd need some kind of full-reflection extension to BGP...

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
They're giving bank robbing a bad name.
 		-- John Dillinger, on Bonnie and Clyde

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 08 Aug 2005 13:19:44 -0700

Paul,

Why do you ever need to shut IBGP session ? Those are to loopbacks and 
you have two choices:

* Take out an entire router (ISIS overload bit or OSPF max age LSA is 
your friend here)

* Take out a line card .. loopback should be still reachable via the IGP.

Cheers,
R.

>> backup path. The RR will propagate the withdraw and the destination 
>> will be removed from the RIB.
> 
>

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 14 Aug 2005 19:09:36 -0400

In message <[email-masked]>
> backup path. The RR will propagate the withdraw and the destination will

Use LOCAL_PREF instead of MP_UNREACH.  The RR will use the best route
it has with the high LOCAL_PREF until another router announces a route
with a lower LOCAL_PREF.

This is easy to do.  If the peering goes down a one liner sets the
LOCAL_PREF for the peer.  If its the entire router going down, its
easy enough to set the default LOCAL_PREF to a high number.  If you
already use LOCAL_PREF, then you'll need to remove LOCAL_PREF lines
but not write out the config so things go back to normal after the
router comes up again.

Curtis

ps - Sorry for the noise if this is already suggested.  Didn't read to
the end of this thread yet.