Subject: [Idr] draft-jakma-mrai as IDR WG document.

From: Yakov Rekhter <[email-masked]>
Date: Sun, 02 Nov 2008 07:31:30 -0800

Folks,

While so far we received no objections, the number of folks who
expressed their support for accepting draft-jakma-mrai is not enough
to justify accepting it as IDR WG document.

With this in mind I'd like to extend the period of comments for
another week. If folks feel that this document should be accepted
as IDR WG document, please respond to this e-mail by no late than
Nov 10, 2008.

Yakov.
------- Forwarded Message

Date:    Thu, 16 Oct 2008 06:07:01 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] draft-jakma-mrai as IDR WG document.

Folks,

Please send your comments on the attached. The deadline for comments
is Oct 30, 2008.

Yakov.
- ------- Forwarded Message

Date:    Wed, 15 Oct 2008 13:50:46 +0100
From:    Paul Jakma <[email-masked]>
To:      Inter-Domain Routing List <[email-masked]>
cc:      [email-masked]
Subject: [Idr] Lowering the recommended, default MRAI time

Hi,

Based on various reports, there appears to be some reasonably 
low-hanging fruit wrt BGP convergence times (and possibly in reducing 
the effects of path-hunting slightly): reduce the MRAI time. There 
are probably better, long-term ways to achieve same - but none have 
the same potential for rapid deployment as reducing the MRAI.

The below is an initial attempt to cover the background, and so 
justify revised recommendations of 5s and 1s-or-less for eBGP and 
iBGP MRAI respectively.

I wonder if the WG has any interest in adopting this draft.

Filename:        draft-jakma-mrai
Revision:        00
Title:           Revised Default Values for the BGP 'Minimum Route
Advertisement Interval'
Creation_date:   2008-10-09
WG ID:           Independent Submission
Number_of_pages: 8

Abstract:

This document briefly examines what is known about the effects of the
BGP MRAI timer, particularly on convergence.  It highlights published
work which suggests the MRAI interval as deployed has an adverse
effect on the convergence time of BGP.

It then recommends revised, lower default values for the MRAI timer,
thought to be more suited to today's Internet environment.

(See: http://tools.ietf.org/html/draft-jakma-mrai-00)

regards,
- - -- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
God was satisfied with his own work, and that is fatal.
  		-- Samuel Butler
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

- ------- End of Forwarded Message

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

------- End of Forwarded Message

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

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 02 Nov 2008 08:54:47 -0800

Support.

Thx,
R.

---

From: "Glen Kent" <[email-masked]>
Date: Sun, 2 Nov 2008 23:30:32 +0530

+1

---

From: Jeffrey Haas <[email-masked]>
Date: Sun, 2 Nov 2008 20:19:33 -0500

> as IDR WG document, please respond to this e-mail by no late than

I'd like to express my reservations with this document.

I believe, in general, that we could lower MRAI and this would have good
benefits on convergence.

I also believe that various entities such as RIPE are basically telling
people "flap damping is likely bad and you should probably turn it off."
However, many people may still have defaults that would only have
damping exacerbated by these lower timers.

I was somewhat disappointed when previous language regarding what's
being called WRATE in the draft wasn't included in RFC 4271.  I believe
we can get most of the benefits of faster pruning of non-viable paths by
not limiting withdrawals with MRAI.  This would reduce overall churn of
paths that appear viable but are actually just waiting for a withdrawal
to show up.

So... I hear Yakov asking again, "Do you support this?"

In it's current form, no.  I'd love to see a different version
recommending WRATE and perhaps a modestly lower MRAI.

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Nov 2008 08:38:43 +0000 (GMT)

On Sun, 2 Nov 2008, Jeffrey Haas wrote:

> I also believe that various entities such as RIPE are basically 
> telling people "flap damping is likely bad and you should probably 
> turn it off." However, many people may still have defaults that 
> would only have damping exacerbated by these lower timers.

That is indeed a risk. So to avoid falling afoul of damping any 
revised MRAI would have to err on the side of being above the 
optimum. The papers by Qui et al suggest the optimum internet MRAI is 
somewhere around 3s to 5s, so the revised suggestion of 5s is 
(hopefully) conservative.

> being called WRATE in the draft wasn't included in RFC 4271.  I 
> believe we can get most of the benefits of faster pruning of 
> non-viable paths by not limiting withdrawals with MRAI.  This would 
> reduce overall churn of paths that appear viable but are actually 
> just waiting for a withdrawal to show up.

We could suggest that implementations MAY choose not to apply MRAI to 
withdrawals (the draft already points out the negative effect WRATE 
has on the optimum). There's little point making stronger 
recommendations, given 4271 changed this (presumably because of 
deployed reality?). (?)

E.g. we could extend the 2nd paragraph of 'known effects' with:

       The scale of this increase is significantly worse with WRATE,
       i.e. applying the MRAI to withdrawals has an adverse effect on
       BGP convergence time.

And add to the recommendations:

     Given the beneficial effects on convergence time, implementations MAY
     exempt withdrawals from the MRAI timer.

?

> recommending WRATE and perhaps a modestly lower MRAI.

The -01 draft now says "5s-or-less". So it's more an upper-bound, 
allowing implementations to judge the risks for themselves. Does that 
help?

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
Q:	How was Thomas J. Watson buried?
A:	9 edge down.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "UTTARO, JAMES, ATTLABS" <[email-masked]>
Date: Mon, 3 Nov 2008 09:12:40 -0500

Are the MRAI settings listed in this draft specific to internet MRAI?
Should they be different for other address families? I believe SPs have
already taken steps to change the default to satisfy VPN customer
convergence requirements.. This draft should reflect why and how the
settings should be different for different address families and not only
rely on papers that reflect the optimum timers for the internet..

Jim Uttaro

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Jakma
Sent: Monday, November 03, 2008 3:39 AM
To: Jeffrey Haas
Cc: Inter-Domain Routing List; [email-masked]
Subject: Re: [Idr] draft-jakma-mrai as IDR WG document.

     Given the beneficial effects on convergence time, implementations
MAY
     exempt withdrawals from the MRAI timer.

?

regards,

---

From: Danny McPherson <[email-masked]>
Date: Mon, 3 Nov 2008 07:57:34 -0700

> rely on papers that reflect the optimum timers for the internet..

In that case, I trust you have some information on what you're
doing and why that could feed into such considerations?

I believe recommended defaults with some logic applied is important,
but per-peer per-AFI/SAFI configurability is critical, given that
every network is going to be different.

-danny

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Nov 2008 14:58:58 +0000 (GMT)

> Are the MRAI settings listed in this draft specific to internet 

Yes they are. I've tried to be careful to make it clear that certain 
parts of the document (anything mentioning specific values, e.g.) 
refer only to internet-class BGP, but obviously not clear enough.

> Should they be different for other address families? I believe SPs 
> have already taken steps to change the default to satisfy VPN 
> customer convergence requirements.. This draft should reflect why 
> and how the settings should be different for different address 
> families and not only rely on papers that reflect the optimum 
> timers for the internet..

Yes, indeed. This was commented on (in private), leading to the 
addition of a paragraph in the final, recommendations section of:

    These values may not be suitable for topologies which differ from the
    internet, be that in scale, arrangement or otherwise.  Such non-
    internet, BGP topologies very likely would have significantly lower
    optimum values, assuming they are always significantly smaller in
    scale than the Internet BGP topology.

along with the change from "5s" to "5s or less". (Probably not the 
most elegant of paragraphs, I'll try clean it up).

Please see the updated, -01 version of the document. Hopefully it's 
more clear (??).

Thanks :)

--paulj

-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Religion is something left over from the infancy of our intelligence, it will
fade away as we adopt reason and science as our guidelines."
-- Bertrand Russell
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 Nov 2008 10:00:17 -0500

On Mon, Nov 03, 2008 at 08:38:43AM +0000, Paul Jakma wrote:
> withdrawals (the draft already points out the negative effect WRATE has on 
> the optimum). There's little point making stronger recommendations, given 
> 4271 changed this (presumably because of deployed reality?). (?)

As of the time 4271 was being finalized, I was aware of two
implementations that didn't apply timers to withdrawals.  I can't find a
version of the draft that had this recommendation in it and at this
point I'm tempted to try to find the relevant conversation in the
archives.

Going to a MAY would certainly be better than the SHALL that's in
9.2.1.1 of RFC 4271.

>       i.e. applying the MRAI to withdrawals has an adverse effect on

I should be clear that I don't think a shorter MRAI will have poor
effects on convergence time.  I believe that convergence time will be
overall better.  

I do, however, believe that this will lead to a lot more churn as the
routing system is converging and probably result in more transitory
forwarding loops in that churn.

>     exempt withdrawals from the MRAI timer.

That would certainly be better IMO.

> The -01 draft now says "5s-or-less". So it's more an upper-bound, allowing 
> implementations to judge the risks for themselves. Does that help?

Given that I spent much of my time working on an implementation that
used 0 second by default... :-)

But in all seriousness, the apparent purpose of the MRAI timer was to
allow an AS to receive some number of eBGP announcements and internally
converge within a shorter window than the announcement back to a given
eBGP peer.  Any recommendation should be heavily tempered by this
presumption.  Given the presence internally of additional reachability
such as BGP VPNs 5seconds may be a little too small for some networks.

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Mon, 3 Nov 2008 15:02:26 +0000 (GMT)

On Mon, 3 Nov 2008, Danny McPherson wrote:

> I believe recommended defaults with some logic applied is 
> important, but per-peer per-AFI/SAFI configurability is critical, 
> given that every network is going to be different.

I've added that recommendation to the draft, as the following text:

     Hence, implementations SHOULD allow the MRAI value to be configured
     administratively on a per-AFI/SAFI basis, as well as a per-peer basis.

added to the paragraph I quoted in my previous mail to James.

I have that + Jeff's comment pending - will update the draft soon.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
We need a licensed electrician to replace the light bulbs in the computer room.
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 3 Nov 2008 10:02:57 -0500

> every network is going to be different.

To add to the point I made in my previous message, since BGP sends
multiple topologies across a single TCP session, an implementation has
to choose which reachability to send at any given time.  This means that
IPv4 reachability may log-jam behind some other reachability depending
on the queueing mechanism in question.

I believe this was one of the arguments for multi-session BGP although
certainly not one of the primary ones.

-- Jeff

---

From: Paul Jakma <[email-masked]>
Date: Mon, 03 Nov 2008 15:44:35 +0000 (GMT)

> implementations that didn't apply timers to withdrawals.  I can't find 
> a version of the draft that had this recommendation in it and at this 

> Going to a MAY would certainly be better than the SHALL that's in

Seems reasonable, yes.

> effects on convergence time.  I believe that convergence time will be 

Ok, then the above paragraph must be poorly worded, cause it wasn't 
intended to disagree with you on this ;).

That particular paragraph is just stating that MRAI applied to 
/withdrawals/ (WRATE) is worse for convergence, than otherwise - where 
MRAI is already > optimum.

> forwarding loops in that churn.

There is a risk of that, though only if we go below the 'optimum' though 
(which Qui, et al, estimated to be 3s to 5s).

We've actually got a lot of 'travel' where we can reduce the MRAI and, 
assuming internet BGP is effectively WRATE-enabled, actually expect that 
it will /reduce/ churn - in addition to improving convergence.

> used 0 second by default... :-)

FWIW, the literature suggests 0 isn't a good idea :). It leads to O(n!) 
messages to converge.

> allow an AS to receive some number of eBGP announcements and 
> internally converge within a shorter window than the announcement back 
> to a given eBGP peer.  Any recommendation should be heavily tempered 
> by this presumption.  Given the presence internally of additional 
> reachability such as BGP VPNs 5seconds may be a little too small for 
> some networks.

Yeah. The previous iBGP recommendation of 5s was another factor in 
picking 5s as the revised eBGP value. Do implementations use different 
values for VPN from iBGP?

regards,
-- 
Paul Jakma,
Solaris Networking                       Sun Microsystems, Scotland
http://opensolaris.org/os/project/quagga tel: EMEA x73150 / +44 15066 73150
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 3 Nov 2008 11:24:20 -0500

On Nov 3, 2008, at 10:44 AM, Paul Jakma wrote:
> FWIW, the literature suggests 0 isn't a good idea :). It leads to  
> O(n!) messages to converge.

The real world disagrees with the literature in this case :-).  The  
existence proof (or rather, refutation) is that there have been MRAI 0  
implementations deployed for a long, long time and the Internet hasn't  
melted.  IIRC, the theoretical O(n!) result has implicit assumptions  
including zero protocol processing latency and zero transmission  
latency for BGP PDUs.

--John