Re: From: Todd Underwood <firstname.lastname@example.org>
but, the geolocation stuff is cool. could it have told us, in
an operationally useful/timely manner, that at&t had moved from
new jersey to spain the other day?
yes, within about 30s. but randy, you should know better than to
think that requires any geolocation. 12/8 didn't move to spain, it
moved to bolivia (AS26210). and since '12956 26210' was a novel
origination pattern for 12/8 (and the other /8s involved), no
geolocation required. simple analysis of bgp updates tells the
story. anyone who can process updates from a large peerset and
compare those to recent routing history or routing policy can report
that as an anomaly.
> 1) the multi-hop issue is bogus, i believe. i'll ignore it
> unless randy chooses to say what he means here.
maybe use <http://nanog.org/mtg-0210/wang.html>. some siteseer
entries seem a bit mangled, but  seems ok.
i'm familiar with the presentation, but thanks for citing it. as you
know jim cowie, andy ogielski and bj premore did some related work for
these are all interesting work regarding whether bgp session resets
during large-scale worms are the cause of monitoring artifacts or
whether those worms cause instability themselves. there are
differences of opinion about the results, but it's all interesting and
good stuff. but off topic here, i believe.
randy: why do you think resets of multi-hop sessions has anything to
do with these results reporting individual prefix outages in the
Katrina-affected regions? sorry for being slow, but i'm just not
seeing any connection. maybe someone smarter than me can spell it out
in small words for me.
> 2) yes, indeed. we chose only to comment on changes in the
> routing table as changes in the routing table. inferences
> about unreachability of end interfaces is left entirely to
> the reader
but reachability is what it's all about. the folk here are
paid to deliver packets. the control plane (routing) is one of
the tools we use to achieve that end.
yes, of course. prefixes with no entry in a routing table are not
reachable from that device. what i am saying is that we are not
implying that the end interface went down or that the point to point
link between the end user and their provider went down (although both
of these seem likely). we are saying that there was not a routed path
from a consensus of our peers to that prefix. so that is definitely
unreachable from that consensus of those peers.
Re: From: George William Herbert <email@example.com>
> Looking at the routing tables you see failures. If a prefix
> goes away completely and utterly, and is truly unreachable,
> then anyone trying to see it is going to see an outage.
not if a covering or more specific tells us how to get packets
to the destination. but perhaps that's what you mean by a
prefix being unreachable and i am being too picky.
i think you may be being picky, but i've already admitted that i'm
having trouble following your points.
we can look in more detail at coverings and more specifics. but the
depressing fact of the matter is that there are very few covering
prefixes for many of these that are effective (which i define to mean:
have the same origination pattern). my claim, and anyone with
routeviews/ripe data and a few hundred MB of space can verify this, is
that these prefixes are really and truly outaged. not reachable from
pretty much anywhere on the Internet. i think that at the higher
level, this is probably not as controversial as it seems to be in
nanog so far.