Subject: [GROW] Meeting Request for Stockholm?

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 May 2009 09:18:48 -0400

Grow folk,
Do we have topics to discuss at this upcoming meeting?
I believe Paul's VA proposal is getting rev'd and added as a grow-wg
document, do we have other things to discuss as well?

-Chris
(Note that the cutoff for scheduling is 5/25)

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 22 May 2009 10:52:26 -0700

Hi Chris,

I would like to present an idea for new diverse BGP path distribution 
scheme which does not require any bgp protocol changes. It would be 
15-20 min.

Draft will be posted before the cut off date.

Many thx,
R.

> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow
> 
>

---

From: Christopher Morrow <[email-masked]>
Date: Fri, 22 May 2009 14:18:13 -0400

On Fri, May 22, 2009 at 1:52 PM, Robert Raszuk <[email-masked]> wrote:
> Hi Chris,
>
> I would like to present an idea for new diverse BGP path distribution scheme
> which does not require any bgp protocol changes. It would be 15-20 min.
>

excellent, 2 topics, more?

---

From: Paul Francis <[email-masked]>
Date: Sat, 23 May 2009 16:12:03 +0200

Yes, VA will be added as grow wg items and require discussion in IETF. 
(Actually, would like to be able to give a more detailed presentation this 
time, so a full hour would be much appreciated.)

PF

From:
Robert Raszuk <[email-masked]>
To:
Christopher Morrow <[email-masked]>
Cc:
"[email-masked] [email-masked]" <[email-masked]>
Date:
05/22/2009 07:54 PM
Subject:
Re: [GROW] Meeting Request for Stockholm?
Sent by:
[email-masked]

Hi Chris,

Many thx,
R.

---

From: Lixia Zhang <[email-masked]>
Date: Sun, 24 May 2009 20:50:25 -0700

> excellent, 2 topics, more?

I sent the following two presentation requests to the co-chairs only,  
now forwarded here.  I suppose each talk can take 15-20 min, depending  
on time availability.

The first one is about measurement results on BGP duplicate messages  
and the causes.

The second one is the measurement results of BGP session resets  
between ISP routers and RIPE/RouteViews collectors. Those who have  
connections to RIPE/RV and those who use RIPE/RV data may be  
interested in the results.

Lixia
----------------
Investigating occurrence of duplicate updates in BGP announcements
Jong Han Park, Dan Jen, Mohit Lad, Shane Amante, Danny McPherson,  
Lixia Zhang

ABSTRACT
BGP is a hard-state protocol that uses TCP connections to reliably  
exchange routing state updates between neighbor BGP routers. According  
to the protocol, only routing changes should trigger a BGP router to  
generate updates; updates that do not express any routing changes are  
superfluous and should not occur. Nonetheless, such ‘duplicate’ BGP  
updates have been observed in reports as early as 1998 and as recently  
as 2007. To date, no quantitative measurement has been conducted on  
how many of these duplicates get sent,
who is sending them, when they are observed, what impact they have on  
the global health of the Internet, or why these ‘duplicate’ updates  
are even being generated. In this paper, we address all of the above  
through a systematic assessment on the BGP duplicate updates. We first  
show that duplicates have a negative impact on reachability and router  
processing loads. We then reveal that there is a significant number of  
duplicates on the Internet - about 13% of all BGP routing updates are  
duplicates. Finally, through a detailed investigation of duplicate  
properties, we manage to discover the major cause behind the  
generation of pathological duplicate BGP updates.

-----
Longitudinal Study of BGP Monitor Session Failures
Pei-chun Cheng, Xin Zhao, Beichuan Zhang, Lixia Zhang

ABSTRACT
BGP monitoring projects such as RouteViews and RIPE RIS have been  
collecting BGP routing tables and updates for over a decade, and the  
data have become an invaluable asset to the research community as well  
as the network operation community. Maintaining robust BGP sessions  
between the data collectors and their ISP peers is essential to ensure  
the quality of the data and the fidelity of works based on these data.  
In this paper, we present the first systematic assessment on BGP  
session failures of RouteViews and RIPE data collectors over the past  
eight years. Our results show that monitoring session failures are  
relatively frequent, averaging a few times a month for a session. Most  
session downtimes last within tens of minutes and the table transfers  
after session
re-establishment usually complete within minutes. By correlating  
session failures across different peers occurring at the same time, we  
find that a significant number of failures are caused by the  
collectors’ local problems. Furthermore, for RIPE monitoring sessions,  
we investigate the impact of the historical decision of disabling BGP  
Keepalive and Holddown timers. We find that disabling the timers had  
an unexpected effect of increased session downtime, since some  
failures went unnoticed, which left long gaps in collected routing  
updates. Our results highlight the importance of taking data  
deficiency into consideration when using the BGP data, as well as the  
importance of improving BGP session stability.