Subject: [Idr] draft-jakma-mrai-dep-00 (fwd)

From: Yakov Rekhter <[email-masked]>
Date: Tue, 25 Nov 2008 15:29:29 -0800

Folks,

Please send your comments on the attached. The deadline for comments
is Dec 12, 2008.

Yakov.
------- Forwarded Message

Date:    Tue, 25 Nov 2008 23:14:49 +0000
From:    Paul Jakma <[email-masked]>
To:      Inter-Domain Routing List <[email-masked]>
cc:      [email-masked]
Subject: [Idr] draft-jakma-mrai-dep-00 (fwd)

Hi,

I wonder would the WG be interested in adopting the below document.

regards,
- -- 
Paul Jakma,

- ---------- Forwarded message ----------
Date: Tue, 25 Nov 2008 14:40:02 -0800 (PST)
From: IETF I-D Submission Tool <[email-masked]>
To: [email-masked]
Subject: New Version Notification for draft-jakma-mrai-dep-00

A new version of I-D, draft-jakma-mrai-dep-00.txt has been successfuly submitte
d by Paul Jakma and posted to the IETF repository.

Filename:	 draft-jakma-mrai-dep
Revision:	 00
Title:		 Revisions to the BGP 'Minimum Route Advertisement Interval'
Creation_date:	 2008-11-25
WG ID:		 Independent Submission
Number_of_pages: 5

Abstract:
This document revises the specification of the BGP MRAI timer, by
deprecating the previously recommended values and by allowing for
withdrawals to be exempted from the MRAI.

The IETF Secretariat.

_______________________________________________
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: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Nov 2008 19:16:53 -0500

IDR,

> Title:		 Revisions to the BGP 'Minimum Route Advertisement Interval'

I believe this document is largely what Yakov had called for at the IETF
73 session and I support its adoption.

I would suggest a minor change to the text:
"Implementations MAY exempt withdrawals from the MRAI timer." 
to
"Implementations MAY allow a distinct MRAI timer value on a per-peer and
a per-AFI/SAFI basis for Withdrawn Routes.  This value may be zero."

The text could probably use some normalization against RFC 4271
terminology but is otherwise fine.

Yakov,

Could you take your WG chair hat off for a second and comment on whether
you believe this document satisfies the requirements you suggested at
IETF 73?

-- Jeff

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 25 Nov 2008 17:40:33 -0800

Jeff,

> you believe this document satisfies the requirements you suggested at

With my WG chair hat off, I think the document more or less satisfies
the requirements. The only two change I would suggest to make are (a) to
eliminate a special case for Withdrawn Routes (this is based on
some discussion that happened few years ago initiated by Pedro Marques),
and (b) explicitly spell out that an implementation SHOULD/MUST allow
to configure MRAI to 0.

Yakov.

---

From: Danny McPherson <[email-masked]>
Date: Tue, 25 Nov 2008 20:46:23 -0700

> Please send your comments on the attached. The deadline for comments

I support as well, I've already provided comments on
the draft itself, and agree with both Jeff and Yakov's
comments.

-danny

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 25 Nov 2008 23:20:10 -0500

Yakov,

> some discussion that happened few years ago initiated by Pedro Marques),

By this, do you mean you don't believe that MRAI should be separately
configurable for reachability and unreachability?

If so, could you recount the gist of your conversation with Pedro?

-- Jeff

---

From: "Bhatia, Manav \(Manav\)" <[email-masked]>
Date: Wed, 26 Nov 2008 10:18:25 +0530

Jeff,

> If so, could you recount the gist of your conversation with Pedro?

The argument was that its impossible for BGP to differentiate between a
good/bad event as either can result in a UPDATE or a WITHDRAWN be sent.
A link going down could result in a new BGP UPDATE (an implicit
withdrawal), while a link coming up could result in a WITHDRAWN to be
sent. So, how do you decide what needs to be sent fast or slow.

Cheers, Manav

---

From: Pedro Marques <[email-masked]>
Date: Tue, 25 Nov 2008 22:07:33 -0800

> configurable for reachability and unreachability?

The rational for not treating them differently is that a single event  
as it propagates through the network gets expressed as both  
reachability and withdrawal information.

The typical example being an SP that acquires a newly preferred peer  
route which them causes it to send withdrawals to other peers  
(reachable converts to unreachable).

My understanding is that this behavior has been well document in  
practical observations of BGP convergence.

In general my recommendation for MRAI values would be 0 for eBGP and 0  
for iBGP. As the draft correctly explains calculating a value that  
best fits the network is a very tricky business.

regards,
   Pedro.

---

From: Olivier Bonaventure <[email-masked]>
Date: Wed, 26 Nov 2008 08:59:04 +0100

Pedro,
> for iBGP. As the draft correctly explains calculating a value that best
> fits the network is a very tricky business.

I would not recommend using the same MRAI timer for iBGP and eBGP. In a
large AS using route reflectors or confederations, we are often in a
situation where some routers of the AS learned an alternate path but did
not distribute it widely due to the alternate paths being hidden by
border routers (e.g. different local-pref or longer AS-Path), router
reflectors or at the borders of confederations. See e.g.
http://inl.info.ucl.ac.be/publications/quantifying-bgp-routes-diversity-insi
but discussions with operators showed that this is true for other networks.

In such large ASes, when a link fails iBGP should converge first in
order to allow all routers to learn the alternate path and advertise the
alternate path over eBGP sessions. This can be achieved, at least
partially, by using a longer MRAI timer for eBGP compared to iBGP.
As you note, the situation is different in BGP/MPLS VPNs environments or
when draft-walton-bgp-add-paths-06.txt is used.

I would not personally recommend to exempt withdraws from the MRAI on
eBGP sessions in large ASes.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 26 Nov 2008 10:23:25 -0500

On Tue, Nov 25, 2008 at 10:07:33PM -0800, Pedro Marques wrote:
> The typical example being an SP that acquires a newly preferred peer route 
> which them causes it to send withdrawals to other peers (reachable converts 
> to unreachable).
>
> My understanding is that this behavior has been well document in practical 
> observations of BGP convergence.

That was the example I needed.

Part of the reason why I suggested separate timers is that the above
scenario is within the scope of iBGP convergence.  This means that
within the expcted iBGP MRAI you should be able to safely send
unreachables quicker to your eBGP peers than you'd otherwise be able to
if you were waiting on the (typically longer) eBGP MRAI.

I'd still recommend different timers but I think I've just been
convinced that the withdraw timer should have a lower bound of the iBGP
MRAI value.

> In general my recommendation for MRAI values would be 0 for eBGP and 0 for 
> iBGP. As the draft correctly explains calculating a value that best fits 
> the network is a very tricky business.

And, as long as you're not worrying about route flap dampening, TCP
queue lengths and processing delays is often enough to squelch a lot of
the updates in networks that are "busy enough".

-- Jeff

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 26 Nov 2008 12:17:26 -0500

Hi Pedro,

Your assessment is correct. 

However, within a particular network (say, providing BGP/VPN service),
the reachability and unreachability may not translate to a single event.
In the below simplified topology, CE1 is dual-homed to PE1 and PE2
(having the VRFs with unique RDs) -

      CE1-----PE1------------PE3-----CE
	 \------PE2------------/

CE1-PE1 link failure results in withdrawn of bunch of routes from PE1 to
PE3, which needs to receive this event as quickly as possible (related
to any other previous advertisements PE1 may have sent to PE3). 

This stays as a single event, even if there are RR in the network (given
the unique RD per VRF per PE).

Needless to say that the above scenario becomes trivial with MRAI = 0
for iBGP.

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Pedro Marques
> Sent: Wednesday, November 26, 2008 1:08 AM
> To: Jeffrey Haas
> Cc: Yakov Rekhter; [email-masked]
> Subject: Re: [Idr] draft-jakma-mrai-dep-00 (fwd)
> 
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Wed, 26 Nov 2008 12:30:23 -0500

Jeff,

Pls see inline,

> Jeffrey Haas
> Sent: Wednesday, November 26, 2008 10:23 AM
> To: Pedro Marques
> route

Agreed.

> convinced that the withdraw timer should have a lower bound of the
iBGP

You mean - separate reachable and withdrawl timer for any BGP peer (I or
E) !! Right?

Cheers,
Rajiv

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 26 Nov 2008 12:41:46 -0500

Rajiv,

> You mean - separate reachable and withdrawl timer for any BGP peer (I or

Yes.  Specifically for explicit withdrawals rather than implicit
withdrawals.

-- Jeff

---

From: Pedro Marques <[email-masked]>
Date: Wed, 26 Nov 2008 00:32:01 -0800

On Nov 25, 2008, at 11:59 PM, Olivier Bonaventure wrote:

>> best
> border routers

How does applying MRAI help in this case ? And how does having an  
higher value for eBGP rather than iBGP help ?

It seems that in your scenario the faster the route propagation the  
better.

> (e.g. different local-pref or longer AS-Path), router
> alternate path over eBGP sessions.

What if your alternate path happens to be being an eBGP peer ?

Dest prefix  is source by AS A

AS A connects to AS B preferentially and has fallback routing though  
AS C. Where C only advertises destination prefix if it is not  
otherwise know. AS D is transit for both B and C.

Convergence requires D to send withdrawal to C to receive the  
alternate path back.

It is not unheard off to have such arrangements.

Please do keep in mind that i didn't suggest that the values (0, 0)  
are the best for your network and for the scenario that you are trying  
to optimize. I'm merely suggesting that as general values for the  
generic case (0, 0) are hard to beat... and they work just fine.

> This can be achieved, at least

---

From: Pedro Marques <[email-masked]>
Date: Wed, 26 Nov 2008 10:12:55 -0800

Pedro,

border routers

How does applying MRAI help in this case ? And how does having an higher value for eBGP rather than iBGP help ?

It seems that in your scenario the faster the route propagation the better.

AS A connects to AS B preferentially and has fallback routing though AS C. Where C only advertises destination prefix if it is not otherwise know. AS D is transit for both B and C.

Convergence requires D to send withdrawal to C to receive the alternate path back.

Please do keep in mind that i didn't suggest that the values (0, 0) are the best for your network and for the scenario that you are trying to optimize. I'm merely suggesting that as general values for the generic case (0, 0) are hard to beat... and they work just fine.

Olivier

--

Idr mailing list

[email-masked]

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 26 Nov 2008 15:03:03 -0500

I support adopting the draft.

--John

---

From: "PAPADIMITRIOU Dimitri" <[email-masked]>
Date: Thu, 27 Nov 2008 02:16:51 +0100

I support adopting the doc.

I suggest the following additions 

- in conformance with RFC 4271, section 9.2.1.1., par.3:

"The MRAI timer set on iBGP connection SHOULD be shorter than the MRAI
timer set on eBGP connection."  

- binding statement:

"Other aspects related to UPDATE message rate limiting are left
unchanged by this recommendation and MUST stay conformant to RFC 4271."

As Jeff also reflected in his comments, following should be replaced:

by

"MRAI timer MAY be configured separately on a per-BGP peer basis for
explicitly withdrawn routes (implementation SHOULD support separately
configurable timers on a per-BGP peer basis for explicitly withdrawn
routes). This timer MAY be set to 0."

thanks,
-d.

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Yakov Rekhter
> Sent: Wednesday, November 26, 2008 12:29 AM
> To: [email-masked]

---

From: Paul Jakma <[email-masked]>
Date: Thu, 27 Nov 2008 10:44:23 +0000 (GMT)

On Wed, 26 Nov 2008, Pedro Marques wrote:

> are the best for your network and for the scenario that you are 
> trying to optimize. I'm merely suggesting that as general values 
> for the generic case (0, 0) are hard to beat... and they work just 
> fine.

I'm probably misunderstanding your point here, but...

While a 0 MRAI may seem very attractive for certain examples, the 
studies with simulations of larger-scale topologies (Griffin and 
others) suggests some appreciable amount of an MRAI is required to 
avoid an explosion in the number of messages. Additionally these 
simulations show convergence time /increases/ proportionally with the 
number of messages (as the MRAI is lowered from optimum toward 0) - 
presumably due to processing and messaging overheads.

(Course, as someone pointed out to me in private, even a nominally-0 
MRAI still implies some amount of per-node processing delay).

So it seems like the studies available suggest it could be quite bad 
if all speakers on the internet were to switch to 0/0, even where 
such values might be of benefit to subsets of the internet.

On a different note:

While it seems everyone is agreed the existing 30s/5s MRAI 'SHOULD' 
values are too high and should be revised in some way, it's also 
apparent there is no agreement on what those specific values should 
be (some think 0/0, some max-5/max-1, some think those values aren't 
conservative enough).

So it seems like just removing/deprecating any specific recommended 
values is the most we can hope to achieve consensus on.

regards,
-- 
Paul Jakma	[email-masked]	[email-masked]	Key ID: 64A2FF6A
Fortune:
"Aww, if you make me cry anymore, you'll fog up my helmet."
-- "Visionaries" cartoon
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr