due to nanog pc silliness, my lightning talk on $subject was not given
in philly. i had promised to report to nanog the results of our winter
experiment which used as path poisoning. here is the lightning talk i
would have given.
http://archive.psg.com/090615.nanog-default.pdf
this is really meant to be a talk, so the slides can be a bit hard.
on slide 6
/20 is the as path length of a /20, i.e. a 'normal' distribution,
as seen from bgp monitors at RV, RIS, and a jillion others
/25 is the as path length distribution we saw pinging from the /25
BGP is the as path length distribution we saw from RV/RIS
i.e. BGP views are significantly skewed. but most of us knew that.
on slides 10 and 11, the categories stub, small isp, large isp are from
a ucla study. imiho, you should take them with a grain of salt.
on 12, the reason for the funniness around 30 test points is because, we
really wanted >= 30 test points in an AS. so if we got close, we
scanned harder to find them.
please do check your as at <http://psg.com/default/> and then actually
look at your router config. i found one of my routers still had a
default from when i was bringing it up.
randy
One point of clarity here. Lightning talks are scheduled in a more spur of
the moment fashion than the traditional submission process for general
sessions. We often schedule lightning talks around a topic with potential
to run short if Q&A isn't significant or we have a 15 minute gap before a
break. Unfortunately that means dates, or times, have the potential to
shift and flexibility is required by the party presenting. Randy was
offered an alternative as soon as it was discovered the original time slot
on Monday was not going to prove viable. Options later in the meeting were
not chosen by Randy due to his schedule constraints. If a specific date is
required on the NANOG agenda please consider submitting a presentation well
in advance of posted deadlines for the general sessions. The NANOG PC does
consider comments made in the tool at http://pc.nanog.org when scheduling
the agenda. Short duration presentations have been accepted well in advance
of the meeting for about a year now and we welcome interesting topics, much
like Randy details below. We hope to see Randy back up at the microphone on
stage at future NANOG meetings. Cheers! -ren
One point of clarity here. Lightning talks are scheduled in a more
spur of the moment fashion than the traditional submission process for
general sessions.
which was why this one was on the web agenda at as specific time? 
sorry my attempt at dealing with todd's screw-up with humor evoked such
a defensive reaction. apology accepted.
randy
Randy Bush wrote:
please do check your as at <http://psg.com/default/> and then actually
look at your router config. i found one of my routers still had a
default from when i was bringing it up.
Ick. Nothing was right. Reported as mixed, though that may be my fault and not your testing. Hmmm. Or your test didn't take some things into account like changes over time. Normally I keep a default route available, but due to changing IGP internally I actually have a default which points interior from the edge routers. So when I shut down the last BGP session on the old cisco, the defaults to the transits went away.
Was also reported as a stub. Glad to know that I don't have BGP customers. Oh, wait, I do.
Jack
Randy, acting like a petulant child in public is unbecoming. Take it off list.
Drive Slow,
Paul Wall
Was also reported as a stub. Glad to know that I don't have BGP
customers. Oh, wait, I do.
talk to ucla. as i said, we take their classification with a grain of
salt.
randy
Jack,
Please give me your ASN and i'll double check our data. As long as the network has 4 or less downstreams, it's being labeled as "stub".
More details here:
http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf
Thanks,
--Ricardo
Ricardo Oliveira wrote:
Jack,
Please give me your ASN and i'll double check our data. As long as the network has 4 or less downstreams, it's being labeled as "stub".
More details here:
http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf
I guess the old adage, "In theory, theory and practice are the same. In practice, they're not.", comes into play here.
In (your) theory, your paper may hold up. In practice, your definition of stub network is most likely considered wrong, and that likely shifts a lot of the assumptions in your paper.
pt
That was my assumption when I checked the "UCLA is wrong" button on the
form. We only have one downstream, but it's a distinct ASN so that says
"not stub" to me.
Mike
Randy top posting - will wonders never cease.
From: Randy Bush [mailto:randy@psg.com]
Sent: Wednesday, June 24, 2009 10:58 AM
To: Ricardo Oliveira
Cc: NANOG list
Subject: Re: Use of Default in the DFZ: banned in philly,see it now on
the net!
OK,a buckety of salt.
From my pov, a stub has zero downstreams.
randy, on iPhone
> Jack,
> Please give me your ASN and i'll double check our data. As long as
> the network has 4 or less downstreams, it's being labeled as
"stub".
8025, and thanks for labeling us small transit guys as stub. I have transit customers that have higher user counts than I do. 
Randy's page just mentioned stub as not having transit customers.
By your definition, we are stub. 4 ASNs under mine, since customers not needing BGP don't use it and we inject their routes into our AS. Some may be undetectable due to routing policies.
Jack
Ricardo Oliveira wrote:
Iphone's. Are top posters 
Imiho a stub must only be foo$
randy
Ricardo Oliveira wrote:
Jack,
Please give me your ASN and i'll double check our data. As long as the network has 4 or less downstreams, it's being labeled as "stub".
More details here:
http://www.cs.ucla.edu/~rveloso/papers/completeness-ton.pdf
I guess the old adage, "In theory, theory and practice are the same. In practice, they're not.", comes into play here.
I agree completely.
In a private reply I just sent to Randy, I said "have you heard my
paraphrase of murphy's law: the internet is so large, so anything
imaginable can happen:-)"
the world cannot be sorted to just black-white, or any limited number of simple definitions
In (your) theory, your paper may hold up. In practice, your definition of stub network is most likely considered wrong, and that likely shifts a lot of the assumptions in your paper.
But I also believe that there are a few common practical patterns that cover majority of reality.
We need to be mindful of diversity in real world but also capture basic common patterns (I'd agree that the paper perhaps should have said a few more words about the former).
Lixia
That was my assumption when I checked the "UCLA is wrong" button on the
form. We only have one downstream, but it's a distinct ASN so that says
"not stub" to me.
this ucla fantasy imposing their social model on actual measurements is
merely amusing and does little damage.
researchers seem to have fantasies about the internet. the $subject
breaks all our fantasies about the 'default free' zone. but it also
shows that all the bgp feeds in the world only give you the ability to
spew bs fast at the nanog podium, and have little to do with reality.
but my favorite researcher fantisy is called the gao-rexford model. it
assumes valley free customer preferred. valley free means no peer
offers transit to peers and no customers offers transit between their
upstreams. we know this to be violated in numerous cases. but the
really good giggle is customer preferred, when the fact is that some
really really large providers prefer peer routes and have since 1948.
randy
Lixia Zhang wrote:
In (your) theory, your paper may hold up. In practice, your definition of stub network is most likely considered wrong, and that likely shifts a lot of the assumptions in your paper.
But I also believe that there are a few common practical patterns that cover majority of reality.
We need to be mindful of diversity in real world but also capture basic common patterns (I'd agree that the paper perhaps should have said a few more words about the former).
Skimming the paper turns up a key sentence, "Stub networks, on the other hand, do not forward packets for other networks." What part of that led you to think that stub networks forward packets for 1-4 downstream ASNs?
pt
Pete Templin wrote:
Skimming the paper turns up a key sentence, "Stub networks, on the other hand, do not forward packets for other networks." What part of that led you to think that stub networks forward packets for 1-4 downstream ASNs?
That's where the confusion sets in, and Randy even stated that the UCLA data is suspect; partially because it considers a stub to be 4 or less downstream ASNs. I think Randy's data would be better reflected without the UCLA information which just confuses it.
Jack
Hi,
The classification we have is one possible classification, it's hard (if not impossible) to capture the diversity of the network in 4 classes without having mislabels. We noticed that there were a considerable number of networks with special arrangements (i.e. a very small number of local downstreams mostly non-profit), specially in academic campus networks. Because these networks are not ISPs in the traditional sense (not their main business), we relaxed the stub threshold at the cost of including some other cases of networks that are actual ISPs (e.g. Jack Bates). Looking forward to see Randy's survey results to see how often this happened.
Thanks,
--Ricardo
That's where the confusion sets in, and Randy even stated that the UCLA
data is suspect; partially because it considers a stub to be 4 or less
downstream ASNs. I think Randy's data would be better reflected without
the UCLA information which just confuses it.
the first pie chart uses no classification. if we had to classify, we
would have stubs only end as paths (_foo$) and transits are all the
rest.
i do not know how we would separate small and large transits in any
rigorous fashion. so it was easier to use the ucla taxa as a rough
approximation and blame anything weird on them
we could do a quick run using the definition of stub and transit as
above if folk are really interested.
randy