Use of Default in the DFZ: banned in philly, see it now on the net!
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 On Tue, Jun 23, 2009 at 3:51 PM, Randy Bush <randy@psg.com> wrote:
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.
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
On Wed, Jun 24, 2009 at 3:04 AM, Randy Bush<randy@psg.com> wrote:
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, acting like a petulant child in public is unbecoming. Take it off list. Drive Slow, Paul Wall
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
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 On Jun 24, 2009, at 6:44 AM, Jack Bates wrote:
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
OK,a buckety of salt. From my pov, a stub has zero downstreams. randy, on iPhone On Jun 24, 2009, at 10:39, Ricardo Oliveira <rveloso@cs.ucla.edu> 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
Thanks,
--Ricardo
On Jun 24, 2009, at 6:44 AM, Jack Bates wrote:
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
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.
-----Original Message----- 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
On Jun 24, 2009, at 10:39, Ricardo Oliveira <rveloso@cs.ucla.edu> 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
Thanks,
--Ricardo
On Jun 24, 2009, at 6:44 AM, Jack Bates wrote:
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
Iphone's. Are top posters :( Imiho a stub must only be foo$ randy On Jun 24, 2009, at 11:18, "Michael K. Smith - Adhost" <mksmith@adhost.com
wrote:
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.
-----Original Message----- 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
On Jun 24, 2009, at 10:39, Ricardo Oliveira <rveloso@cs.ucla.edu> 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
Thanks,
--Ricardo
On Jun 24, 2009, at 6:44 AM, Jack Bates wrote:
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
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
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
On Jun 24, 2009, at 11:04 AM, Pete Templin wrote:
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
Lixia Zhang wrote:
On Jun 24, 2009, at 11:04 AM, Pete Templin 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
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
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 On Jun 24, 2009, at 12:26 PM, Pete Templin wrote:
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
On Jun 24, 2009, at 11:04 AM, Pete Templin wrote: 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
8025, and thanks for labeling us small transit guys as stub. I have transit customers that have higher user counts than I do. :P 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:
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
participants (9)
-
Jack Bates -
Lixia Zhang -
Michael K. Smith - Adhost -
Paul Wall -
Pete Templin -
Randy Bush -
Ren Provo -
Ricardo Oliveira -
Ricardo Oliveira