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

From: "DECRAENE Bruno RD-CORE-ISS" <[email-masked]>
Date: Wed, 10 Aug 2005 19:32:08 +0200

Hi Paul,

> > Could you be a little more specific about your proposition?
> 
> Put a delay in between NOTIFY/CEASE and updating your FIB.
 
Fine. It's a possible solution.

To adress the other direction of the IP flow, it would probably require
that on reception of a BGP NOTIFY/CEASE, you activate the same trick.
And it would require some extra trick if you have multiple RR between
the 2 ASBR advertising the path to the destination. (for example
full-reflection as you mention, but that also has a cost).

If we come back to the requirement doc, it does not state that the BGP
protocol should necessarily be modified. It merely points out an issue
which could possibly be resolved with an informational or BCP doc. 
I guess most of us agree on the issue with the default behavior, but we
disagree on what should be done:
- Some expressed that it could already be solved now using specific
route policies, manually configured or scripted.
- I guess your point is that the issue could be resolved by an
implementation without requiring any BGP modification and as such IDR
should not be involved.
- Our point is that currently no popular implementation has addressed
this issue and that IDR could discuss this point. The result of this
discussion may be that it should be left to each implementation but why
presuppose the conclusion.

> This is all essentially what several people have been considering
already, eg the "Ordered FIB Updates" draft (i think you're aware of it,
no?):
> 	http://bgp.potaroo.net/ietf/idref/draft-francois-ordered-fib/

I'm aware of this draft which is indeed very interesting.
It deals with link state IGP. I'd be fine if someone wrote an equivalent
draft for BGP.

Regards,
Bruno

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

---

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

On Wed, 10 Aug 2005, DECRAENE Bruno RD-CORE-ISS wrote:

> To adress the other direction of the IP flow, it would probably 
> require that on reception of a BGP NOTIFY/CEASE, you activate the 
> same trick.

If P1 were to be shutdown? Yes, then you'd want P1 to support this 
"trick". However, it's still useful in a mixed environment. Eg, for 
your ASBR1 case, even if P1 doesn't support this, it still should 
enhance routing.

> And it would require some extra trick if you have multiple RR 
> between the 2 ASBR advertising the path to the destination. (for 
> example full-reflection as you mention, but that also has a cost).

Yes. I'd suggest looking at the 3 drafts which potentially could 
solve the full-reflection + "CEASE + wait" optimisation case.

> If we come back to the requirement doc, it does not state that the 
> BGP protocol should necessarily be modified. It merely points out 
> an issue which could possibly be resolved with an informational or 
> BCP doc.

Fair enough.

> implementation without requiring any BGP modification and as such IDR

Yes, or at least that one could implement "CEASE and wait" first and 
garner some experience first before attempting to see what needs to 
be done at IDR. (I'm an IETF/IDR process newbie though, so my opinion 
might be incompatible with IETF/IDR practice).

> - Our point is that currently no popular implementation has 
> addressed this issue and that IDR could discuss this point. The 
> result of this discussion may be that it should be left to each 
> implementation but why presuppose the conclusion.

Hmm, well, I don't know when I'll get around to it (no promises), but 
hacking CEASE+wait into a Free Software BGP implemention is now on my 
lower-priority TODO list.

Mightn't be useful for you for deployment, but likely would be useful 
for laboratory testing to see how well CEASE+wait could work.

> It deals with link state IGP. I'd be fine if someone wrote an 
> equivalent draft for BGP.

It deals with topology changes in general, and discusses them in 
context of IGP - the topology change stuff is obviously still 
applicable to BGP to some extent.. interesting stuff anyway.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
A New York City ordinance prohibits the shooting of rabbits from the
rear of a Third Avenue street car -- if the car is in motion.