Multi-6 [WAS: OT - Vint Cerf joins Google]
[Perhaps this thread should migrate to Multi6?] 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? 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. -- TTFN, patrick
Re: Multi-6 [WAS: OT - Vint Cerf joins Google]
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: Katrina Network Damage Report
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
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
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: Katrina Network Damage Report
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: Multi-6 [WAS: OT - Vint Cerf joins Google]
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, 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]
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 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]
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: Multi-6 [WAS: OT - Vint Cerf joins Google]
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: Katrina Network Damage Report
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]
on topic of IPv6 end-user assignments and value of multihoming 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
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 att 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 http://nanog.org/mtg-0210/wang.html. 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: Katrina Network Damage Report
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)
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
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]
RE: www.usenetabuse.com?
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: Multi-6 [WAS: OT - Vint Cerf joins Google]
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. http://www.ietf.org/html.charters/shim6-charter.html -- Mikael Abrahamssonemail: [EMAIL PROTECTED]
Re: Katrina Network Damage Report
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
