Subject: [Idr] Fwd: I-D ACTION:draft-li-bgp-stability-01.txt

From: Tony Li <[email-masked]>
Date: Mon, 18 Jun 2007 13:07:58 -0700

Hi all,

Please note some significant changes since the previous version.  We  
now have some analysis that shows techniques that could possibly  
reduce churn by 20-35%.  Please see the draft for details.

Thanks,
Geoff & Tony

Begin forwarded message:

> From: [email-masked]
> Date: June 18, 2007 12:50:02 PM PDT
> To: [email-masked]
> Subject: I-D ACTION:draft-li-bgp-stability-01.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: BGP Stability Improvements
> 	Author(s)	: G. Huston, T. Li
> 	Filename	: draft-li-bgp-stability-01.txt
> 	Pages		: 23
> 	Date		: 2007-6-18
> 	
> BGP is the routing protocol used to tie the Autonomous Systems (ASes)
>    of the Internet together.  The ongoing stability of BGP in the face
>    of arbitrary inputs, both malicious and unintentional, is of  
> primary
>    importance to the overall stability of the Internet.  The overall
>    issue is not a new one.  Previously, one aspect of stability, known
>    as route flap damping was originally discussed in RFC 2439.  In the
>    intervening years, a great deal of experience with flap damping and
>
>    other stability concerns has been accumulated.  Most recently, the
>    issue of BGP stability has been highlighted in RAWS.  This document
>    describes the experience that has been gained concerning  
> stability in
>    the intervening years, hypotheses about remaining problems,
>    suggestions for experiments to be performed, and proposals for
>    possible alternatives.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-li-bgp-stability-01.txt
>
> To remove yourself from the I-D Announcement list, send a message to
> [email-masked] with the word unsubscribe in the body of
> the message.
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
> to change your subscription settings.
>
> Internet-Drafts are also available by anonymous FTP. Login with the
> username "anonymous" and a password of your e-mail address. After
> logging in, type "cd internet-drafts" and then
> "get draft-li-bgp-stability-01.txt".
>
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
> Internet-Drafts can also be obtained by e-mail.
>
> Send a message to:
> 	[email-masked].
> In the body type:
> 	"FILE /internet-drafts/draft-li-bgp-stability-01.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> Content-Type: text/plain
> Content-ID: <[email-masked]>
>
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/i-d-announce

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

---

From: "Vishwas Manral" <[email-masked]>
Date: Mon, 18 Jun 2007 22:36:55 -0700

Hi Tony,

The draft looks very good to me.

One small comment was that all along in the draft some numbers have
been mentioned. It would be good to further characterize the
measurements, like  for how long the measurements were done and the
methodology in brief.

thanks,
Vishwas

On 6/18/07, Tony Li <[email-masked]> wrote:
>
>
> Hi all,
>
> Please note some significant changes since the previous version.  We now
> have some analysis that shows techniques that could possibly reduce churn by
> 20-35%.  Please see the draft for details.
>
> Thanks,
> Geoff & Tony
>
>
> Begin forwarded message:
>
>    of arbitrary inputs, both malicious and unintentional, is of primary
>    describes the experience that has been gained concerning stability in
> You can also visit
> https://www1.ietf.org/mailman/listinfo/I-D-announce

---

From: Geoff Huston <[email-masked]>
Date: Wed, 20 Jun 2007 10:11:10 +1000

Hi,

The numbers in section 4.3.1 were based on a data collection of the 
entire set of BGP updates gathered from 1 April 2007 0000 UTC+1000 until 
1 May 2007 0000 UTC+1000, using a single eBGP feed from AS4637 that 
provided a full route set to the data collector. AS4637 has a footprint 
across Asia and parts of North America, as I understand it, and it 
operates as a transit provider.

The eBGP feed was from a Cisco router that (by default) used a 30 second 
MRAI Timer.

The data collection BGP engine was a Cisco router using an update 
collection configuration via logging debug bgp updates through syslog.

regards,

     Geoff

---

From: Tony Li <[email-masked]>
Date: Tue, 19 Jun 2007 17:21:25 -0700

On Jun 19, 2007, at 5:11 PM, Geoff Huston wrote:

> entire set of BGP updates gathered from 1 April 2007 0000 UTC+1000  
> until 1 May 2007 0000 UTC+1000, using a single eBGP feed from  
> AS4637 that provided a full route set to the data collector. AS4637  
> has a footprint across Asia and parts of North America, as I  
> understand it, and it operates as a transit provider.
>
> The eBGP feed was from a Cisco router that (by default) used a 30  
> second MRAI Timer.
>

And I corroborated this data by examining the update logs from AS4637  
from 24-May 2007 00:30 UTC to 6-Jun 2007 23:02 for the set of known,  
active beacon sites.

The numbers in section 3.6 were also based on analysis of the beacon  
data set.

Note that my analysis was independently formulated from Geoff's, so  
it's not only separate, non-intersecting data sets, it also is two  
completely independent implementations.

Tony

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 21 Jun 2007 23:03:03 +0200

Hi Tony,

In the text of section 3.4 I found the below when discussing how to
differentiate if the prefix is from stub or from multihomed site.

            Unfortunately, it seems difficult to distinguish between stub
            prefixes and non-stub prefixes.  To do so would seem to
            require require explicit annotation that could only be
            reasonably generated by manual configuration and would likely
            be incorrect.

Wouldn't one way of automatically addressing this problem result in an
extension to BGP where ASBR or RR when learning two disjoined paths for
a given prefix automatically mark it with some new transitive attribute
or well known community ? Once marked as such given prefix marking would
not be removable .. pretty much just like ORIGINATOR is applied today by 
RRs for other purposes ?

Cheers,
R.

---

From: Tony Li <[email-masked]>
Date: Thu, 21 Jun 2007 15:04:53 -0700

On Jun 21, 2007, at 2:03 PM, Robert Raszuk wrote:

> not be removable .. pretty much just like ORIGINATOR is applied  
> today by RRs for other purposes ?

Hi Robert,

Interesting idea.  I think you really mean that you want to have two  
different penultimate AS'es in the path.  That's certainly a hint.   
What about domains that are dual-homed to the same provider?
What happens when the alternate path is withdrawn?

Regards,
Tony

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 Jun 2007 00:46:13 +0200

Tony,

> different penultimate AS'es in the path.  That's certainly a hint.  

Yes that was the scenario I had in mind.

> What about domains that are dual-homed to the same provider?

Wouldn't that provider in most cases mask the immediately connected to 
the end AS link failure within his own AS ? I think we could treat those 
therefor as stub in the bigger picture of the 3.4 proposal.

> What happens when the alternate path is withdrawn?

I think we could solve that with some long enough timer ... if the 
alternate path is withdrawn for sufficiently long time the non-stub site 
  becomes stub by the ASBR/RR which did the original marking or has had 
all the info to be a marker candidate.

Cheers,
R.