Re: www.usenetabuse.com?

[Andrew - Supernews]

> "Howard" == Howard C Berkowitz <[EMAIL PROTECTED]> writes:

 Howard> I'm assisting in trying to deal with a group of
 Howard> flooders/trolls. One remailer directs complaints to
 Howard> www.usenetabuse.com.  Does anyone know if this is a
 Howard> legitimate anonymizer abuse desk, or phishing for details of
 Howard> exploits?

usenetabuse.com is a domain run by Steve Walker, nntpserver.com, who
provides usenet service under a variety of reseller names, some of
which are actually separate resellers while others he apparently runs
himself. He uses the usenetabuse.com domain for handling abuse reports
regarding his service, but of course this does not excuse him from the
normal responsibility to handle emailed abuse reports.

-- 
Andrew, Supernews
http://www.supernews.com

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Patrick W . Gilmore]

On Sep 11, 2005, at 12:32 AM, Mikael Abrahamsson wrote:


On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:

Content providers and other large business, without who's funds  
the Internet would fail, have a right not to be tied to a single  
provider.  And while I


Giving each entity who wants to multihome an AS of their own and  
own address block, doesn't scale. Think this in the way of each  
home in the world being multihomed, it just doesn't scale.


We disagree.  And your hyperbole doesn't come close to proving your  
argument.



IPv6 solved the addressing problem, not the routing problem, in the  
current model. Let's try to fix the routing problem NOW instead of  
5-10 years down the road.


Yes, let's.

See you on shim6.

--
TTFN,
patrick

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Christopher L. Morrow]

On Sun, 11 Sep 2005, Mikael Abrahamsson wrote:

>
> On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:
>
> > Content providers and other large business, without who's funds the Internet
> > would fail, have a right not to be tied to a single provider.  And while I
>
> The "shimming" model is a way to solve this by the endsystems knowing
> about multihoming, instead of the network. I personally think this is a
> better idea and scales much better. Let's have the network moving packets

cause each end node knows about the upstream network 'problems' so well?
giving them full routes too are we? ( I don't want to fight this arguement
here, I'm just making a rhetorical question, one I hope there will be a
presentation this nanog to also argue over :) )

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Christopher L. Morrow]

On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:

>
> On Sep 10, 2005, at 1:58 PM, Christopher L. Morrow wrote:
>
> > most likely, but I was really saying: "Do they even NEED PI
> > space?" (for
> > this discussion, or rather the start of it, I don't think so...
>
> I disagree.  (Or, more precisely, I don't think _anyone_ needs v6
> space right now 'cause it ain't really used.  But assuming you want
> to use it, Google "needs" is, IMHO.)

sure, but we were driving down the road of 'perhaps vint is doing v6
evangelism, and google will light v6 on all their services'... so they
need SOMETHING v6-ish, either PI or PA from all of their providers,
theoretically either would work for them.

>
> Care to explain why you think so?

In the current v6 multi-homing world you just get a new ip for each
provider you add to your network... you don't NEED PI space, unless you
are going to be a provider (or have a plan to service more than 200
customers in the next 12 months). So, say google just wants the quick and
dirty solution with little ARIN interaction, they 'force' their providers
(probably most already do this) to get v6 access to them, then they live
in the world of multiple ips/host (one per provider) and then would do the
shim6 lovin'.

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Christopher L. Morrow]

On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:

>
> On Sep 10, 2005, at 10:17 AM, Joe Abley wrote:
>
> >> [Perhaps this thread should migrate to Multi6?]
>
> >> Suppose they not only have no plan but couldn't really put
> >> together a plan to support 200 customers?  Does this mean Google,
> >> or any other content provider, is "unworthy" of globally routeable
> >> space?
> >
> > Yes, according to the current RIR policies. [So the determination
> > of "unworthy" above has been made, in effect, by RIR members.]
>
> And this is why v6 has failed and will continue to fail.
>

see my comments about: "Get involved!"

> The Internet is no longer an academic experiment.  It is not run by
> the 'best technology'.  It is run by the best business results.
>
> Content providers and other large business, without who's funds the
> Internet would fail, have a right not to be tied to a single
> provider.  And while I admit I am not up-to-date on v6 multi-homing
> strategies, the ones I have seen are either evil, unworkable or
> ridiculous, and simply will not fly.
>

See above.

>
> > There seems to be some ongoing perception that various protocol/
> > research organisations have no idea about the value of multi-homing
> > for enterprises in the real network, and hence ignore it. While
> > that might have once been the case (I certainly remember thinking
> > so around 1997 whilst shouting on the ipng list), I don't believe
> > it's the case today.
>
> That is _absolutely_ the impression I get from speaking to v6
> supporters today.  The profess otherwise, but the solutions and
> technologies they suggest disprove their protestations.
>
> Guess I better get over to shim6 and see what I'm missing out on.

excellent! one more provider/operator watching to be sure 'the right
thing' happens.

Re: Correct inclusion of rwhois info in WHOIS server output?

[Suresh Ramasubramanian]

Marco d'Itri's whois client does quite a lot of what you want,
including automatically following an rwhois referral when it finds one

Of course not much can be done when the rwhois server to which you're
redirected just doesn't respond

[EMAIL PROTECTED] 11:33:29 <~> $ telnet  rwhois.level3.net 4321
Trying 209.244.1.179...

srs

On 09/09/05, Albert Meyer <[EMAIL PROTECTED]> wrote:
> 
> Thanks to everyone who replied on and off-list. I'm concluding that there is a
> problem with WHOIS server output, caused mostly by a lack of standards, but
> people with more influence than me are already working on fixing that. In the
> meantime I'll see if I talk to the gnu maintainer about making jwhois more
> rwhois-friendly.
> 


-- 
Suresh Ramasubramanian ([EMAIL PROTECTED])

Re: Katrina Network Damage Report

[Steve Gibbard]

On Sat, 10 Sep 2005, Todd Underwood wrote:


interesting discussion.  at least we're talking about networking now.
:-)

wrt sean's comment, the only thing i can think he means by 'partition'
is that the networks may have power may be in some routing table but
just not the routing table of any of renesys's (or routeviews or ripe)
peers.  in that case, i guess i would agree.  our use of 'outage' is a
special case of 'partition' where the whole internet is on one side
and it's possible that the networks in question are on the other.
they may route somewhere.  just not to the internet.


The difference between a partitioning and a complete outage can depend a 
lot on what's on each side of the partition.


If my DSL line goes down, I suppose that's technically a partitioning.  I 
can still get to the DNS server in the basement, or to my neighbors' 
computers on my wireless network, but not to anything else.  Meanwhile, 
the rest of the Internet can't get to anything in my or my neighbors' 
houses, but is otherwise functional.  Complaining that that was anything 
less than a complete outage would be at best extremely pedantic, since 
there's likely nobody on my home network who particularly cares about 
being able to get to other things on my home network.


However, the same sort of partitioning can happen on a much bigger scale. 
There are some countries or large regions that have several ISPs, an 
exchange point they use to connect to eachother, locally hosted content, 
and a single path out to the rest of the world.  In those areas, it's 
possible for the international link to fail but for connectivity to the 
nearby portions of the Internet to work fine.  In those cases, it's far 
less clear-cut to say, "they don't have access to the Internet," and might 
be more accurate to say that their part of the Internet had been cut off 
from the rest of the Internet.


(I gave a talk on this at NANOG and a few other conferences last spring. 
The associated paper is at 
http://www.pch.net/resources/papers/Gibbard-mini-cores.pdf)


From what I understand of the Renesys methodology, the difference between 
a partitioning and a total outage wouldn't be visible.  A router in 
a region that wasn't able to send data to Florida wouldn't be able to send 
data to your collector (which doesn't mean the Renesys system isn't really 
cool for answering all sorts of other questions -- it is).


That said, I haven't heard any reports of a large scale partitioning 
happening in New Orleans.  It sounds like most of what was down was down 
due to local infrastructure being under water or without power, so my 
guess is that the Renesys view was pretty accurate in this case.  Thanks 
for sharing it.


-Steve

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Mikael Abrahamsson]

On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:

Content providers and other large business, without who's funds the Internet 
would fail, have a right not to be tied to a single provider.  And while I


Giving each entity who wants to multihome an AS of their own and own 
address block, doesn't scale. Think this in the way of each home in the 
world being multihomed, it just doesn't scale.


IPv6 solved the addressing problem, not the routing problem, in the 
current model. Let's try to fix the routing problem NOW instead of 5-10 
years down the road.


The "shimming" model is a way to solve this by the endsystems knowing 
about multihoming, instead of the network. I personally think this is a 
better idea and scales much better. Let's have the network moving packets 
as its primary goal, not solving "how do I reach this prefix" equations.




--
Mikael Abrahamssonemail: [EMAIL PROTECTED]

RE: www.usenetabuse.com?

[Hannigan, Martin]

Title: RE: www.usenetabuse.com?








I haven't run a large usenet server in awhile, but, anyone asking for your phone number related to a usenet complaint has a whole lot of time on their hands.

Wait for Supernews to chime in.

Martin



 -Original Message-
From:   Howard C. Berkowitz [mailto:[EMAIL PROTECTED]]
Sent:   Sat Sep 10 21:51:47 2005
To: nanog@merit.edu
Subject:    www.usenetabuse.com?


I'm assisting in trying to deal with a group of flooders/trolls. One
remailer directs complaints to www.usenetabuse.com.  Does anyone know
if this is a legitimate anonymizer abuse desk, or phishing for
details of exploits?

Re: Katrina Network Damage Report

[George William Herbert]

Randy wrote:
>George William Herbert <[EMAIL PROTECTED]>
>> 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.


Yes, to clarify, by "completely and utterly" i mean not just
the prefix that you saw drop, but more specific and more general routes
that you may have access to as well.


-george william herbert
[EMAIL PROTECTED]

www.usenetabuse.com?

[Howard C. Berkowitz]

I'm assisting in trying to deal with a group of flooders/trolls. One 
remailer directs complaints to www.usenetabuse.com.  Does anyone know 
if this is a legitimate anonymizer abuse desk, or phishing for 
details of exploits?

Re: Katrina Network Damage Report

[bmanning]

> 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.
> 
> Re: From: George William Herbert <[EMAIL PROTECTED]>
> > 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.

would that be that -all- your neighbors have no
information on how to forward that packet, then
the destination is unreachable.

what if a neighbor lies about reachablity and you
dump your packets into their "blackhole"?

that darned policy-constrained routing ick can be
tough to deal w/...

> 
> randy

--bill  (who will return to lurking)

Re: Katrina Network Damage Report

[Randy Bush]

Re: From: Todd Underwood <[EMAIL PROTECTED]>

to quote bobby dylan "you don't need a weatherman to know which
way the wind blows."  i.e., unless you were the president, the
department of fatherland security, or fema, you probably knew
there was a major disaster ongoing in nola and surrounds.  if
you could read the newpapers, you could even have known of it
in advance.

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?

> 1) the multi-hop issue is bogus, i believe.  i'll ignore it
> unless randy chooses to say what he means here.

maybe use .  some siteseer
entries seem a bit mangled, but [0] seems ok.

> 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.

Re: From: George William Herbert <[EMAIL PROTECTED]>
> 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.

randy

---

[0] - bibtex
@inproceedings{ wang02observation,
  Author = "Lan Wang and Xiaoliang Zhao and Dan Pei and Randy Bush and Daniel 
Massey and Allison Mankin and S. Felix Wu and Lixia Zhang",
  Title = "Observation and Analysis of BGP Behavior Under Stress",
  BookTitle = "Proc. of ACM SIGCOMM Internet Measurement Workshop 2002, 
Marseille, France",
  Month= "Nov",
  Year = "2002",
  url = "citeseer.ist.psu.edu/article/wang02observation.html" }

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[John Curran]

At 6:23 AM -0400 9/10/05, Marshall Eubanks wrote:
>However, there are two proposals to ARIN to allow direct  "micro"
>assignments to end sites, these are supposed to be merged into one
>by the 16th of this month, so people interested should go over to the
>ARIN ppml and comment.

Marshall - good pointer...

It is worth repeating that folks who hold an opinion on this matter
either way should quickly get involved, whether that is via mailing-list
or in person at the upcoming NANOG/ARIN meeting in LA.

Thanks!
/John

Re: Katrina Network Damage Report

[Todd Underwood]

interesting discussion.  at least we're talking about networking now.
:-)

wrt sean's comment, the only thing i can think he means by 'partition'
is that the networks may have power may be in some routing table but
just not the routing table of any of renesys's (or routeviews or ripe)
peers.  in that case, i guess i would agree.  our use of 'outage' is a
special case of 'partition' where the whole internet is on one side
and it's possible that the networks in question are on the other.
they may route somewhere.  just not to the internet.

quick question below...

> There are some inconsistent terms used in computer
> dependability research, but I prefer and use two
> key definitions: failure (something is offline)
> and outage (customer sees the service offline).

not sure i understand these definitions.  i'm happy to use any
well-defined terms (vocabulary never being worth fighting over).
again, when i use 'outage' i mean:  previously in global internet
tables of a consensus of a large peerset and now removed from those
tables.  which is that in your terms?

> Looking at the routing tables you see failures.

not necessarily, if i'm understanding your definitions (which i guess
i'm not).  

> If a prefix goes away completely and utterly,
> and is truly unreachable, then anyone trying to
> see it is going to see an outage.  But you can
> have a lot of intermediate cases where routes are
> mostly down but not completely, or where parts
> of the net can see it but other parts can't
> due to the vagarities of route propogation
> and partial failures.

yes.  we cover all of these by having a large peerset and integrating
our data across them.  the outages that we report are not from a
particular point on the net.  they are from a consensus of a large,
selected peerset.

> And there are situations where the route is
> down but the service is still up.

unless you use words differently, this is not true.  by 'service' i
mean 'IP service'.  if the route is down, no one can reach anything
associated with that route, obviously.  do you mean 'service' as local
loop service? 

> There are other network monitoring groups
> that do end to end connectivity tests from
> geographically distributed clients out to
> sample systems around the net.  Some for research
> and some for hire for network monitoring.
> 
> I think what they do is much closer to
> identifying true outages than your method.

yes, that may be.  those are good ways of identifying certain kinds of
outages.  the problem is that they only measure what they measure.
frequently these systems measure well-connected sites monitoring
well-connected sites.  this creates a bias in the data, tending to
suggest that no big event ever really impacts the internet.  this is
obviously a false conclusion.

for reference compare the analysis of the 2003 US blackouts from
keynote:

http://www.keynote.com/news_events/releases_2003/03august14.html  

(summary:  nothing to see here, move along)

with those from renesys:

http://www.renesys.com//resource_library/blackout_results.html

(summary:  >4K prefixes disappeared from the global table impacting
connectivity to hospitals, schools, government and lots of
businesses).  

i would agree that our method of routing table analysis has
significant limitations and needs to be combined with other data.  but
it's a fantastic way of showing a lower bound on what was affected:
prefixes without entries in the global table almost certainly have no
service.

t.

-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Patrick W. Gilmore]

On Sep 10, 2005, at 1:58 PM, Christopher L. Morrow wrote:

most likely, but I was really saying: "Do they even NEED PI  
space?" (for

this discussion, or rather the start of it, I don't think so...


I disagree.  (Or, more precisely, I don't think _anyone_ needs v6  
space right now 'cause it ain't really used.  But assuming you want  
to use it, Google "needs" is, IMHO.)


Care to explain why you think so?

--
TTFN,
patrick

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Patrick W. Gilmore]

On Sep 10, 2005, at 10:17 AM, Joe Abley wrote:


[Perhaps this thread should migrate to Multi6?]


multi6 hasn't existed for some time. The "level-3 shim" approach to  
multi-homing that was the primary output of multi6 is being  
discussed in shim6.


Guess I'm behind.  I'll have to subscribe to shim6.


Suppose they not only have no plan but couldn't really put  
together a plan to support 200 customers?  Does this mean Google,  
or any other content provider, is "unworthy" of globally routeable  
space?


Yes, according to the current RIR policies. [So the determination  
of "unworthy" above has been made, in effect, by RIR members.]


And this is why v6 has failed and will continue to fail.

The Internet is no longer an academic experiment.  It is not run by  
the 'best technology'.  It is run by the best business results.


Content providers and other large business, without who's funds the  
Internet would fail, have a right not to be tied to a single  
provider.  And while I admit I am not up-to-date on v6 multi-homing  
strategies, the ones I have seen are either evil, unworkable or  
ridiculous, and simply will not fly.



's not as though this line of thinking hasn't been followed many,  
many times before. The counter-argument goes like this:


1. There is more v6 space than there is v4 space, by virtue of the  
fact that the address is 96 bits wider.


2. Because there is vastly more v6 space than v4 space, if  
entitlement to PI space in v6 was opened up the chances are many  
more people would have v6 PI space than currently have v4 PI space.


This assumption has more holes in it than swiss cheese.


3. Every PI assignment/allocation takes up a routing slot in every  
router in the DFZ.


4. Given 2 and 3, there is potential for the amount of state in the  
DFZ to exceed the capabilities of the network to hold and process  
it (e.g. enormous RIBs, soaring processor requirements for dealing  
with updates, etc).


Ignoring the problems with #2, what is made of the idea that each AS  
might only have a single block, since blocks are so much larger?   
(And lots of other questions I'm sure you guys have already covered  
which are probably not on-topic for NANOG.)



It's possible that the number of PI assignments might not be that  
high, and the scaling properties in practice might not be so bad.  
However, you only get to find this out after you've opened the  
floodgates, and if it turns out that it doesn't scale, it's hard to  
push the water back into the reservoir.


The goal in shim6 is to find a mechanism which provides all the  
functional benefits of multi-homing without holding all the state  
in DFZ routers.


Perhaps the goal ... was chosen poorly?


There seems to be some ongoing perception that various protocol/ 
research organisations have no idea about the value of multi-homing  
for enterprises in the real network, and hence ignore it. While  
that might have once been the case (I certainly remember thinking  
so around 1997 whilst shouting on the ipng list), I don't believe  
it's the case today.


That is _absolutely_ the impression I get from speaking to v6  
supporters today.  The profess otherwise, but the solutions and  
technologies they suggest disprove their protestations.


Guess I better get over to shim6 and see what I'm missing out on.

--
TTFN,
patrick

Re: Katrina Network Damage Report

[George William Herbert]

Todd Underwood wrote:
> Sean Donelan wrote:
>> Todd Underwood wrote:
>> > the general idea is:  take a large peerset sending you full
>> > routes, keep every update forever, and take a reasonably long (at
>> > least a month or two) time horizon. calculate a consensus view for
>> > each prefix as to whether that prefix is reachable by some set of
>> > those peers.  an outaged prefix is one that used to be reachable that
>> > not no longer is.  in other words, one that has been withdrawn from
>> > the full table by some sufficiently large number of peers.
>> 
>> This describes a partioning, not necessarily an outage.
>
>can you explain what you mean?

I'm not sure if Sean's thinking the same thing I am,
but let me chime in with a nickel's worth of commentary.

There are some inconsistent terms used in computer
dependability research, but I prefer and use two
key definitions: failure (something is offline)
and outage (customer sees the service offline).

Various redundancy can hide failures from customers
and keep them from being true outages.

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.  But you can
have a lot of intermediate cases where routes are
mostly down but not completely, or where parts
of the net can see it but other parts can't
due to the vagarities of route propogation
and partial failures.

And there are situations where the route is
down but the service is still up.

There are other network monitoring groups
that do end to end connectivity tests from
geographically distributed clients out to
sample systems around the net.  Some for research
and some for hire for network monitoring.

I think what they do is much closer to
identifying true outages than your method.


-george william herbert
[EMAIL PROTECTED]

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Christopher L. Morrow]

On Sat, 10 Sep 2005, Marshall Eubanks wrote:

>
> Google == AS  15169 which has 100 prefixes announced in my BGP.
>
> I suspect they could qualify for IPv6 address space under any criteria.
> I know
> they could arrange to qualify, simply by buying an appropriate ISP.
> They've got the cash.
>

most likely, but I was really saying: "Do they even NEED PI space?" (for
this discussion, or rather the start of it, I don't think so...

-Chris

Re: Katrina Network Damage Report

[Todd Underwood]

sean,

On Sat, Sep 10, 2005 at 10:18:25AM -0400, Sean Donelan wrote:
> On Sat, 10 Sep 2005, Todd Underwood wrote:
> > the general idea is:  take a large peerset sending you full
> > routes, keep every update forever, and take a reasonably long (at
> > least a month or two) time horizon. calculate a consensus view for
> > each prefix as to whether that prefix is reachable by some set of
> > those peers.  an outaged prefix is one that used to be reachable that
> > not no longer is.  in other words, one that has been withdrawn from
> > the full table by some sufficiently large number of peers.
> 
> This describes a partioning, not necessarily an outage.

can you explain what you mean?

t.


-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Joe Abley]

On 10-Sep-2005, at 09:18, Patrick W. Gilmore wrote:


[Perhaps this thread should migrate to Multi6?]


multi6 hasn't existed for some time. The "level-3 shim" approach to  
multi-homing that was the primary output of multi6 is being discussed  
in shim6.


Suppose they not only have no plan but couldn't really put together  
a plan to support 200 customers?  Does this mean Google, or any  
other content provider, is "unworthy" of globally routeable space?


Yes, according to the current RIR policies. [So the determination of  
"unworthy" above has been made, in effect, by RIR members.]


IPv6 is a nice idea, and as soon as people realize that ISPs are  
not the only organizations who have a need to multi-home - and I  
mean really multi-home, not stupid work-arounds - then it might  
actually start to happen.


It's not as though this line of thinking hasn't been followed many,  
many times before. The counter-argument goes like this:


1. There is more v6 space than there is v4 space, by virtue of the  
fact that the address is 96 bits wider.


2. Because there is vastly more v6 space than v4 space, if  
entitlement to PI space in v6 was opened up the chances are many more  
people would have v6 PI space than currently have v4 PI space.


3. Every PI assignment/allocation takes up a routing slot in every  
router in the DFZ.


4. Given 2 and 3, there is potential for the amount of state in the  
DFZ to exceed the capabilities of the network to hold and process it  
(e.g. enormous RIBs, soaring processor requirements for dealing with  
updates, etc).


It's possible that the number of PI assignments might not be that  
high, and the scaling properties in practice might not be so bad.  
However, you only get to find this out after you've opened the  
floodgates, and if it turns out that it doesn't scale, it's hard to  
push the water back into the reservoir.


The goal in shim6 is to find a mechanism which provides all the  
functional benefits of multi-homing without holding all the state in  
DFZ routers.


There seems to be some ongoing perception that various protocol/ 
research organisations have no idea about the value of multi-homing  
for enterprises in the real network, and hence ignore it. While that  
might have once been the case (I certainly remember thinking so  
around 1997 whilst shouting on the ipng list), I don't believe it's  
the case today.


The real problem is that there is no simple answer that doesn't have  
potentially nasty consequences.



Joe

Re: Katrina Network Damage Report

[Sean Donelan]

On Sat, 10 Sep 2005, Todd Underwood wrote:
> the general idea is:  take a large peerset sending you full
> routes, keep every update forever, and take a reasonably long (at
> least a month or two) time horizon. calculate a consensus view for
> each prefix as to whether that prefix is reachable by some set of
> those peers.  an outaged prefix is one that used to be reachable that
> not no longer is.  in other words, one that has been withdrawn from
> the full table by some sufficiently large number of peers.

This describes a partioning, not necessarily an outage.

Re: Katrina Network Damage Report

[Todd Underwood]

randy brings up two separate questions...

On Sat, Sep 10, 2005 at 07:22:34PM +0700, Randy Bush wrote:
> but what about existence of covering or more specific prefixes?
> while aggregate inferences are likely reasonable, in general,

see?  i told y'all that this would come up!  yes, covering prefixes
count.  there are many fewer covering prefixes than many most net
geeks would like to believe.  there are also many prefixes that appear
(in routing data only) to cover that do not, in fact, provide
forwarding for the more specific prefixes.

a simple analysis that only includes a covering prefix if it has
exaclty the same origination pattern (last two ASes maybe), might be
sufficient.  still no way to tell, for certain, whether the cover
works. 

our analysis didn't look at covering prefixes, but a spot check of the
outaged prefixes doesn't reveal many.  perhaps someone else would like
our list of outaged prefixes to check those for cover?

> inferring unreachability of end interfaces by looking only at
> routing data, especially multi-hop bgp data, worries me.

me, too.  that's why we didn't do that.

two issues in this second question:

1) the multi-hop issue is bogus, i believe.  i'll ignore it unless randy chooses
to say what he means here.  

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
(randy, in this case).

t.

-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

Re: 12/8 problems?

[Eric Louie]

FYI, happened again this morning for (at least) 12/8 
duration approx 30 minutes 
starting at 5:45 AM PDT.

Re: Katrina Network Damage Report

[Randy Bush]

but what about existence of covering or more specific prefixes?
while aggregate inferences are likely reasonable, in general,
inferring unreachability of end interfaces by looking only at
routing data, especially multi-hop bgp data, worries me.

randy

Re: Katrina Network Damage Report

[Todd Underwood]

randy,

On Sat, Sep 10, 2005 at 05:49:59PM +0700, Randy Bush wrote:
> this report repeatedly uses the term "outage."  how is that
> determined/measured?

i think this is covered in the report several times, but i'm sorry if
it wasn't clear.  this is based on work that we've done for a while
(some of which was presented at nanog30:
http://nanog.org/mtg-0402/ogielski.html).

the general idea is:  take a large peerset sending you full
routes, keep every update forever, and take a reasonably long (at
least a month or two) time horizon. calculate a consensus view for
each prefix as to whether that prefix is reachable by some set of
those peers.  an outaged prefix is one that used to be reachable that
not no longer is.  in other words, one that has been withdrawn from
the full table by some sufficiently large number of peers.  

we exclude single-peer outages and outages that only affect a few
peers through some reasonable thresholding.

make sense?  that's the general idea.  the implementation is obviously
a *lot* more complicated.

t.

(i'm sure the question of covering prefixes will come up shortly and
i'll address it when/if it does). :-)

-- 
_
todd underwood
director of operations & security
renesys - interdomain intelligence
[EMAIL PROTECTED]   www.renesys.com

Re: Katrina Network Damage Report

[Randy Bush]

this report repeatedly uses the term "outage."  how is that
determined/measured?

randy

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Marshall Eubanks]

Google == AS  15169 which has 100 prefixes announced in my BGP.

I suspect they could qualify for IPv6 address space under any criteria. 
I know
they could arrange to qualify, simply by buying an appropriate ISP. 
They've got the cash.


However, there are two proposals to ARIN to allow direct  "micro"
assignments to end sites, these are supposed to be merged into one by 
the 16th of this month, so people interested should go over to the ARIN 
ppml and comment.


One issue is to what extent IPv6 tunnels should count towards 
multi-homing.


My personal feeling is that, having gotten 2002-3 through ARIN, this 
should pass

eventually.

Regards
Marshall Eubanks

On Sep 10, 2005, at 3:38 AM, Christopher L. Morrow wrote:




On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:



[Perhaps this thread should migrate to Multi6?]



perhaps... then jason can argue this instead of me :)


On Sep 9, 2005, at 11:55 PM, Christopher L. Morrow wrote:


On Fri, 9 Sep 2005, Daniel Golding wrote:



Getting back on-topic - how can this be? I thought only service
providers
(with downstream customers) could get PI v6 space. Isn't this what
policy
proposal 2005-1 is about? Can someone (from ARIN?) explain the
current
policy?


what if they didn't ask for a prefix but instead just hammered their
providers for /48's? What's the difference to them anyway?
(provided we
are just talking about them lighting up www.google.com in v6 of
course)

If they wanted to start offering more 'services' (ip services
perhaps?)
then they could say they were a 'provider' (All they need is a plan 
to
support 200 customers to get a /32) and start the magic of 
/32-ness...


Suppose they not only have no plan but couldn't really put together a
plan to support 200 customers?  Does this mean Google, or any other
content provider, is "unworthy" of globally routeable space?



apparently that's the plan yes, or so say the current decision
makers/policy-makers/'the-man'... take it up with them, in fact, 
everyone

should be thinking this through as you are/have and thinking about the
implications of the current policies related to v6 address allocations,
subnetting 'standards' and even multi-homing.


IPv6 is a nice idea, and as soon as people realize that ISPs are not
the only organizations who have a need to multi-home - and I mean
really multi-home, not stupid work-arounds - then it might actually
start to happen.


Agreed, so... hopefully others will start to participate in the 
process to
change things for the 'better'. To make sure that the 
policies/procedures

are more closely aligned with operational requirements/needs. It seems
that lots of folks are of the belief that:
1) its not important to worry about this 'today'
2) the 'right decision' will get made and 'things will just work out'
3) 'certainly someone else will argue my point for me'

(or some combination of that grouping...) It looks to me, and I'm new 
at

this so I may be wrong, that none of the above really is true :( The
current train for ipv6 is on the tracks and headed your way whether you
like it or not, and it's not headed your way to pick you up :(

The process/standards bodies need more operators to get involved so 
that

standards we can deploy/live-with make it to fruitition.

Thanks for the tee :)

-Chris

Re: Multi-6 [WAS: OT - Vint Cerf joins Google]

[Christopher L. Morrow]

On Sat, 10 Sep 2005, Patrick W. Gilmore wrote:

>
> [Perhaps this thread should migrate to Multi6?]
>

perhaps... then jason can argue this instead of me :)

> On Sep 9, 2005, at 11:55 PM, Christopher L. Morrow wrote:
>
> > On Fri, 9 Sep 2005, Daniel Golding wrote:
>
> >> Getting back on-topic - how can this be? I thought only service
> >> providers
> >> (with downstream customers) could get PI v6 space. Isn't this what
> >> policy
> >> proposal 2005-1 is about? Can someone (from ARIN?) explain the
> >> current
> >> policy?
> >
> > what if they didn't ask for a prefix but instead just hammered their
> > providers for /48's? What's the difference to them anyway?
> > (provided we
> > are just talking about them lighting up www.google.com in v6 of
> > course)
> >
> > If they wanted to start offering more 'services' (ip services
> > perhaps?)
> > then they could say they were a 'provider' (All they need is a plan to
> > support 200 customers to get a /32) and start the magic of /32-ness...
>
> Suppose they not only have no plan but couldn't really put together a
> plan to support 200 customers?  Does this mean Google, or any other
> content provider, is "unworthy" of globally routeable space?
>

apparently that's the plan yes, or so say the current decision
makers/policy-makers/'the-man'... take it up with them, in fact, everyone
should be thinking this through as you are/have and thinking about the
implications of the current policies related to v6 address allocations,
subnetting 'standards' and even multi-homing.

> IPv6 is a nice idea, and as soon as people realize that ISPs are not
> the only organizations who have a need to multi-home - and I mean
> really multi-home, not stupid work-arounds - then it might actually
> start to happen.

Agreed, so... hopefully others will start to participate in the process to
change things for the 'better'. To make sure that the policies/procedures
are more closely aligned with operational requirements/needs. It seems
that lots of folks are of the belief that:
1) its not important to worry about this 'today'
2) the 'right decision' will get made and 'things will just work out'
3) 'certainly someone else will argue my point for me'

(or some combination of that grouping...) It looks to me, and I'm new at
this so I may be wrong, that none of the above really is true :( The
current train for ipv6 is on the tracks and headed your way whether you
like it or not, and it's not headed your way to pick you up :(

The process/standards bodies need more operators to get involved so that
standards we can deploy/live-with make it to fruitition.

Thanks for the tee :)

-Chris