From paul at vix.com Tue Nov 1 01:51:14 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 01 Nov 2005 06:51:14 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Your message of "Mon, 31 Oct 2005 19:50:31 PST." <112701c5de97$6c0bd570$5ea723c0@tndh.net> References: <112701c5de97$6c0bd570$5ea723c0@tndh.net> Message-ID: <20051101065114.C61EF11425@sa.vix.com> tony, i suspect that we're talking past each other so let's stop soon, ok? # ... The super-regional addresses are the source of the pain in the routing # system so why shouldn't they carry the cost? whose pain? certainly from a multinational DFZ ISP's point of view, the cost of super-regional addresses is a great source of pain, since the competition they enable is only good for their competitors, whereas the cost is universal. but for everybody else, maybe the pain of buying fatter routers is worthwhile considering that it levels the playing field a little. # Multi-homing within a region does have impact on the routers serving that # region, but ONLY the routers within that region. you're still basing assertions on a premise i've disputed, which is that there are only a few very fat pipes between some kind of regions (maybe geographic), and that this trend will continue. i don't think it's true now, and i don't think there are any natural reasons for it to ever be more true than it is now, and i think that regionalized (geographic or otherwise) addressing would be an unnatural way to cause this to become truer, and that if it becomes truer, the internet industry as a whole will become even more brittle than it is, and the end users will suffer for it, as will various shareholders. if you want to presume benefits of regionality, then first either show me that we have regionality now, or show me the other market or technological forces that will lead to more regionality over time, and then we can talk about whether a regionalized addressing system has a shadow it can travel within, or whether regionalized addressing will MAKE a new shadow on the landscape. # > # There is no reason for ARIN to even bother with evaluating 'need' or # > # 'appropriate use' of PI space as long as there is a way for providers to # > # aggregate out the ones that have not paid enough to support a global # > # slot. # > # > if we're going to do provider-centric address allocation design, why would # > we say we wanted PI space at all? how about we allocate space based on # > need and appropriate use, and let providers compete on how well they can # > serve their customers? # # I didn't say they were provider centric, just that they could be aggregated # out. it's because you said that providers could aggregate them out, that i decided that you must be looking at this in a provider centric way. # In any case, who gets to decide the value of 'need' and why do they get to # decide that? providers and endusers are both members of the community. it should be our job to understand and balance their needs. i'm not even sure there is any conflict between the needs of providers' and endusers' in the long run, but i do know that a policy that will singularly benefit only one of these communities of interest is a mistake or at least uninteresting. # > then let such cities get themselves some address space, build an internet # > exchange, build a wireless network, number their citizens, and let transit # > providers compete over the result. ARIN's current policies would allow # > this. (and it's a damned damned DAMNED fine idea.) # # ARIN policy allows this, but there is an external conflict in 'use of public # funds to compete with industry'. i'm sure that there's an industry out there ready to do just about everything any given city does, including police and fire, sewage, road maintainance, etc. the decision of "what should government do?" is not decided solely by "what wouldn't be worst for industry?" but rather "what would be best for the citizenry?" in this case the citizenry (me for example) would rather have my streets dug up the fewest number of times, would like multiprovider address portability, would like a lockin-free market where i can choose the provider of commodity communications services. i'd like my city to provide that to me, because it would still require industry to provide the next leg -- transit, in this case, as well as contract construction and management services to the city -- while stabilizing the delivery of commodity communications services and probably stabilizing the finances of the various industry players so we're not always wondering who's going bankrupt next or who's buying whom next or whatever. but we digress. # It really doesn't matter if the exchange operator is a city, a consortium of # ISPs, or an independent enterprise as in the current set. actually, it does. regulation of the real estate required for last-mile is absolutely critical to the success of what i'm describing. # The bottom line is that all the 'insanity' that is necessary to sort those # things out within the city/region is contained at that exchange and the # transit providers have a clean demarc to compete over. i think we agree! but only at the city or metro level, in my view. but we REALLY digress. # One of the biggest issues that gets overlooked is that we are not restricted # to choosing one or the other. PA space is fine for those that don't care # where the space comes from. people who don't care where the space comes from are often simply undereducated rather than actively disinterested. ask someone "would you rather have address space that you can take to a new provider with you, or address space that you'd have to renumber out of if you change providers?" and you'll get a very modal result, peaking with the larger network owners who will generally prefer NAT over PA once they understand the implications. # Some entities (including DNS roots) have needs that don't fit in the PA # model. The current debate is about who gets to pass judgment on the value of # 'need'. The most effective judge of value is the organization requesting the # resource. If they are presented with a menu of resource bundles and prices # they can make the clear determination of the bundle that actually meets # their need with the value measure that will naturally pushback to keep them # from demanding more than they need. that would be a fine thing. the PA/PI split enabled by CIDR didn't leave a choice nearly as viable as that. i don't think regionalized (geo or otherwise) addressing would leave any viable choices open, either, but we could get to the point of discussing that if we could agree on some premises. # A sequential allocation of PI space creates the swamp that becomes # impossible to deal with over time. A structured allocation builds the option # that down the road it is possible to enforce exchange point based # aggregation if and/or where that becomes necessary. It really doesn't matter # what structure you choose, the constraint of topology to fit that structure # is what reduces the impact on the routing system. The point is to think # about ways to allocate PI space that will allow for long terms options. you're getting way ahead of yourself. assuming we agreed that there was some kind of regionality now, and was going to continue to be any, we'd have to decide whether geographic, or topological, or linguistic, or cultural regionality made the most sense as outer-block address pool boundaries. this whole topic area strikes me as a swamp when i consider the variables involved, and it's bothering me that you keep acting as if they're all known constants. paul From iggy at merit.edu Tue Nov 1 10:43:15 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Tue, 1 Nov 2005 10:43:15 -0500 (EST) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: I'm not at all sure there should be a requirment that the "sites" be one per metro area... or that there be any such restriction per metro area. I supose it depends on how you actualy define 'metro'. Perhaps something better that could be just as easily verified, is that each site must have a unique street address, etc... Perhaps you might think /48 per street address is a bit much, I guess that would depend on how large the building was/is. Maybe a /52 per street address could work. Either way, I think the one site per metro area is too restrictive, perticularly in the sense that it would pretty much eliminate any direct assignments to originzations that may entirely located in a small geographic area. Glenn Wiltse On Fri, 28 Oct 2005, Bill Woodcock wrote: > > So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more > about this over dinner, and I think the consensus out of that conversation > was this: > > - an IPv6 direct-assignment policy should be based directly on the ipv4 > direct-assignment policy, as closely as possible. > > - one-size-fits-all probably isn't useful in the long run. > > - host-counts are stupid. > > - a strict multi-homing requirement is perfectly reasonable. > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > - the size of the assignment should probably be /48 times the number of > sites you have already deployed. > > - in order to avoid creative interpretation of "sites," no more than one > site per metro area should be counted. That's arbitrary, but it's an > objectively-verifiable quantity, which is what's needed for the ARIN > analyst staff. > > Thoughts? > > -Bill > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From christopher.morrow at gmail.com Tue Nov 1 10:58:47 2005 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Tue, 1 Nov 2005 10:58:47 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> Message-ID: <75cb24520511010758t7c382defjc9ee451717faa944@mail.gmail.com> some below, and jumping in to bill's actual message since I missed the original. Keep in mind that I personally think that the 'classfulness' being imposed on ipv6 seems bad... It's convenient, but it's just wasteful. On 11/1/05, Glenn Wiltse wrote: > I'm not at all sure there should be a requirment that the "sites" be > one per metro area... or that there be any such restriction per metro > area. I supose it depends on how you actualy define 'metro'. Perhaps > something better that could be just as easily verified, is that each > site must have a unique street address, etc... Perhaps you might think > /48 per street address is a bit much, I guess that would depend on how > large the building was/is. Maybe a /52 per street address could work. > I think the 'metro area' part was more an effort to say: "It's ok to have 1 assignment of $size to each place you want to light a connection, but we don't really want to support folks just asking for PI 'because'." So making a metro, or location dependent proposition seemed reasonable. (for folks with disparate locations and no backside network connecting them all together) > Either way, I think the one site per metro area is too restrictive, > perticularly in the sense that it would pretty much eliminate any direct > assignments to originzations that may entirely located in a small > geographic area. > > > Glenn Wiltse > > On Fri, 28 Oct 2005, Bill Woodcock wrote: > > > > > So Chris Morrow and Mike Hughes and Thomas Narten and I were talking more > > about this over dinner, and I think the consensus out of that conversation > > was this: > > > > - an IPv6 direct-assignment policy should be based directly on the ipv4 > > direct-assignment policy, as closely as possible. > > > > - one-size-fits-all probably isn't useful in the long run. > > > > - host-counts are stupid. > > the reasoning behind this (forgive me if someone else already said this) is: "Multihoming is a business decision, not a size decision". Basically, there are lots of new regulations coming around that will 'require' mutlihoming (provider redundancy sorts of things for end sites) that have nothing to do with the size of the organization under the thumb of the regulation. You may legittimately have a single front-end e-commerce site that supports millions of dollars of revenue, operating off say a very small number if host addresses (www.google.com comes to mind actually). Forcing the multihoming to have some arbitrary number of ips in use seems counter productive. It's not the metric of interest for this problem. Also, there should be much more work done on other methods of multihoming. Methods that make it simpler, and less globally intensive for everyone in the long term. So, there may be flavors of multihoming in the future that require PI and flavors that do not (and provide the flexibility to switch providers at will with little penalty to the end site). My major issue with the 2005-1 proposal was it's 100k host count requirement, it just seemed like the wrong way to measure for this. > > - a strict multi-homing requirement is perfectly reasonable. > > > > - preexisting IPv4 deployment should qualify you for IPv6 assignment. > > > > - the size of the assignment should probably be /48 times the number of > > sites you have already deployed. > > > > - in order to avoid creative interpretation of "sites," no more than one > > site per metro area should be counted. That's arbitrary, but it's an > > objectively-verifiable quantity, which is what's needed for the ARIN > > analyst staff. > > > > Thoughts? > > > > -Bill > > > > _______________________________________________ > > PPML mailing list > > PPML at arin.net > > http://lists.arin.net/mailman/listinfo/ppml > > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From iggy at merit.edu Tue Nov 1 13:11:05 2005 From: iggy at merit.edu (Glenn Wiltse) Date: Tue, 1 Nov 2005 13:11:05 -0500 (EST) Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <75cb24520511010758t7c382defjc9ee451717faa944@mail.gmail.com> References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> <75cb24520511010758t7c382defjc9ee451717faa944@mail.gmail.com> Message-ID: Yes, however all I'm saying is that there may very well be originzations with ligitamate needs for PI space that are in a realtively small geographic location, yet have lots of ligitamate 'sites' all in that small area. I really see no reason to restrict things so that only orginizations that span larger areas will qualify. I agree with the concept that the the size of the block requested and/or received should be tied in someway to the number of 'sites' that you have. I'm just saying restricting one site per 'metro area' is not the right thing. I guess it's all just another debate about what is a 'site'... and even to some extent, how many subnets does a perticular 'site' need. I think untill we can all come to consensus on these basic questions, we'll never get consensus on the bigger picture. Glenn On Tue, 1 Nov 2005, Christopher Morrow wrote: > some below, and jumping in to bill's actual message since I missed the > original. Keep in mind that I personally think that the 'classfulness' > being imposed on ipv6 seems bad... It's convenient, but it's just > wasteful. > > On 11/1/05, Glenn Wiltse wrote: >> I'm not at all sure there should be a requirment that the "sites" be >> one per metro area... or that there be any such restriction per metro >> area. I supose it depends on how you actualy define 'metro'. Perhaps >> something better that could be just as easily verified, is that each >> site must have a unique street address, etc... Perhaps you might think >> /48 per street address is a bit much, I guess that would depend on how >> large the building was/is. Maybe a /52 per street address could work. >> > > I think the 'metro area' part was more an effort to say: "It's ok to > have 1 assignment of $size to each place you want to light a > connection, but we don't really want to support folks just asking for > PI 'because'." So making a metro, or location dependent proposition > seemed reasonable. (for folks with disparate locations and no backside > network connecting them all together) > >> Either way, I think the one site per metro area is too restrictive, >> perticularly in the sense that it would pretty much eliminate any direct >> assignments to originzations that may entirely located in a small >> geographic area. From hannigan at verisign.com Tue Nov 1 13:53:23 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Tue, 1 Nov 2005 13:53:23 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: > some below, and jumping in to bill's actual message since I missed the > original. Keep in mind that I personally think that the 'classfulness' > being imposed on ipv6 seems bad... It's convenient, but it's just > wasteful. Isn't this the part where Tony jumps in and says "IPV4" mindset? :-) (That was an excellent comment re: 2005-1 btw). -M< From kloch at hotnic.net Tue Nov 1 14:00:57 2005 From: kloch at hotnic.net (Kevin Loch) Date: Tue, 01 Nov 2005 14:00:57 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: References: <0A79726C-B546-4DEE-945F-92B9F4A148C7@cnet.com> <75cb24520511010758t7c382defjc9ee451717faa944@mail.gmail.com> Message-ID: <4367BB69.2060309@hotnic.net> Glenn Wiltse wrote: > I agree with the concept that the the size of the block requested and/or > received should be tied in someway to the number of 'sites' that you have. > I'm just saying restricting one site per 'metro area' is not the right > thing. One way to avoid defining a site is to look at the number of upstream connections. Separate sites would each have at least one upstream connection. Connections to the same upstream POP could probably share a /48. - Kevin From alh-ietf at tndh.net Tue Nov 1 22:04:18 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 1 Nov 2005 19:04:18 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051101065114.C61EF11425@sa.vix.com> Message-ID: <120401c5df5a$1f763b60$5ea723c0@tndh.net> Paul Vixie wrote: > tony, i suspect that we're talking past each other so let's stop soon, ok? I am trying to be responsive, but if I am not getting your point that response will be meaningless... > > # ... The super-regional addresses are the source of the pain in the > routing > # system so why shouldn't they carry the cost? > > whose pain? certainly from a multinational DFZ ISP's point of view, the > cost > of super-regional addresses is a great source of pain, since the > competition > they enable is only good for their competitors, whereas the cost is > universal. > but for everybody else, maybe the pain of buying fatter routers is > worthwhile > considering that it levels the playing field a little. This depends on you perspective. If those with big wallets want to set a bar that says 'you must have this much cash to play', then yes fatter routers levels the playing field for those who make the cut. For the players that don't make the cut though that level field they can't enter does them no good. > > # Multi-homing within a region does have impact on the routers serving > that > # region, but ONLY the routers within that region. > > you're still basing assertions on a premise i've disputed, which is that > there > are only a few very fat pipes between some kind of regions (maybe > geographic), > and that this trend will continue. i don't think it's true now, and i > don't > think there are any natural reasons for it to ever be more true than it is > now, > and i think that regionalized (geographic or otherwise) addressing would > be an > unnatural way to cause this to become truer, and that if it becomes truer, > the > internet industry as a whole will become even more brittle than it is, and > the > end users will suffer for it, as will various shareholders. The assertion is based on the fact that there are a limited number of fiber runs under the oceans. Yes that number is more than 1, but it is not numbered in the thousands, and will continue to be limited over time due to costs. There is no reason for a network in New York to know the gory details of the traffic engineering in Beijing, any more than the networks in Beijing need to know the details of local delivery in New York. The entire concept of a global DFZ with detailed traffic engineering overlays has been about raising the bar to prevent entry by new players. That approach is not required for bit delivery to work. Bit delivery is possible using transit providers interconnecting exchange based aggregates, and that would be no more brittle than what we currently have. > > if you want to presume benefits of regionality, then first either show me > that > we have regionality now, or show me the other market or technological > forces > that will lead to more regionality over time, and then we can talk about > whether a regionalized addressing system has a shadow it can travel within, > or whether regionalized addressing will MAKE a new shadow on the landscape. If you go back to the original IPv6 allocation mechanism you will see that it was all about regionalizing the space. I am not defending it just noting that it started from the premise that there were only a few transit providers and that all of their customers would be contained within their region as aggregates of the transit and never show up in the global routing system. This was not an acceptable business arrangement for the non-transit providers so we have the current plan where anyone that can claim they are a provider gets independent space. Of course this still leaves their customers locked within the regional aggregate of that non-transit provider. The edge customers are claiming the same problem with the business arrangement, and if we allocate sequential space to them like we do to the providers there will be a swamp over time. Fundamentally we don't have a good way to constrain the routing system except to abstract out the details of non-local networks. Non-local can be defined in a variety of ways, and I am just suggesting that geography is one of those ways. > > # > # There is no reason for ARIN to even bother with evaluating 'need' or > # > # 'appropriate use' of PI space as long as there is a way for > providers to > # > # aggregate out the ones that have not paid enough to support a global > # > # slot. > # > > # > if we're going to do provider-centric address allocation design, why > would > # > we say we wanted PI space at all? how about we allocate space based > on > # > need and appropriate use, and let providers compete on how well they > can > # > serve their customers? > # > # I didn't say they were provider centric, just that they could be > aggregated > # out. > > it's because you said that providers could aggregate them out, that i > decided > that you must be looking at this in a provider centric way. No, just that the provider is the one looking to reduce the resource consumption, so if they have a way to deliver the bits without extraneous knowledge they will shed as much as they can. > > # In any case, who gets to decide the value of 'need' and why do they get > to > # decide that? > > providers and endusers are both members of the community. it should be > our > job to understand and balance their needs. i'm not even sure there is any > conflict between the needs of providers' and endusers' in the long run, > but > i do know that a policy that will singularly benefit only one of these > communities of interest is a mistake or at least uninteresting. We completely agree here about the need for balance. I do see a conflict though in that everyone wants to have their hand on the knob of fine-grained-traffic-engineering. Allowing everyone to express their policy in the global view just adds to bloat. > > # > then let such cities get themselves some address space, build an > internet > # > exchange, build a wireless network, number their citizens, and let > transit > # > providers compete over the result. ARIN's current policies would > allow > # > this. (and it's a damned damned DAMNED fine idea.) > # > # ARIN policy allows this, but there is an external conflict in 'use of > public > # funds to compete with industry'. > > i'm sure that there's an industry out there ready to do just about > everything > any given city does, including police and fire, sewage, road maintainance, > etc. the decision of "what should government do?" is not decided solely > by > "what wouldn't be worst for industry?" but rather "what would be best for > the > citizenry?" > > in this case the citizenry (me for example) would rather have my streets > dug > up the fewest number of times, would like multiprovider address > portability, > would like a lockin-free market where i can choose the provider of > commodity > communications services. i'd like my city to provide that to me, because > it > would still require industry to provide the next leg -- transit, in this > case, > as well as contract construction and management services to the city -- > while > stabilizing the delivery of commodity communications services and probably > stabilizing the finances of the various industry players so we're not > always > wondering who's going bankrupt next or who's buying whom next or whatever. > > but we digress. I agree with your goal, but recent WiFi efforts show that no matter how lame the deployments by industry are, as soon as a city steps up for the good of their citizens those lethargic providers will cry foul. > > # It really doesn't matter if the exchange operator is a city, a > consortium of > # ISPs, or an independent enterprise as in the current set. > > actually, it does. regulation of the real estate required for last-mile > is > absolutely critical to the success of what i'm describing. > > # The bottom line is that all the 'insanity' that is necessary to sort > those > # things out within the city/region is contained at that exchange and the > # transit providers have a clean demarc to compete over. > > i think we agree! but only at the city or metro level, in my view. > > but we REALLY digress. I really don't care about the scale. My attempt has been to define an approach that is devoid of any geo-political context. There will always be policies that overlay on any mechanism and distort the outcome, but trying to design something for current political structures is a simple way to ensure they don't fit in the future. > > # One of the biggest issues that gets overlooked is that we are not > restricted > # to choosing one or the other. PA space is fine for those that don't > care > # where the space comes from. > > people who don't care where the space comes from are often simply > undereducated rather than actively disinterested. ask someone "would you > rather have address space that you can take to a new provider with you, or > address space that you'd have to renumber out of if you change providers?" > and you'll get a very modal result, peaking with the larger network owners > who will generally prefer NAT over PA once they understand the > implications. We agree about the education point, though I would put it as the educated will take the path of lowest cost and renumbering is a high cost. The difference being that NAT is a higher cost than PI, but current policies essentially raise the cost of PI above NAT. That might be justified with the limited pool in IPv4, but there is no reason for the RIRs to take that approach with IPv6. At the same time blindly allocating sequential PI space is known to have a negative impact on the routing system, so we need something better. > > # Some entities (including DNS roots) have needs that don't fit in the PA > # model. The current debate is about who gets to pass judgment on the > value of > # 'need'. The most effective judge of value is the organization requesting > the > # resource. If they are presented with a menu of resource bundles and > prices > # they can make the clear determination of the bundle that actually meets > # their need with the value measure that will naturally pushback to keep > them > # from demanding more than they need. > > that would be a fine thing. the PA/PI split enabled by CIDR didn't leave > a choice nearly as viable as that. i don't think regionalized (geo or > otherwise) addressing would leave any viable choices open, either, but we > could get to the point of discussing that if we could agree on some > premises. I guess I don't see how PA is even a consideration in this model, unless it is considered the lowest item on the menu where the PA consumer is not a direct member of ARIN. Maybe you are suggesting that the PA blocks themselves would just be additional menu choices. The geo approach in my draft doesn't particularly fit either since it simply pre-allocates space and there is no need to justify to anyone for use of the space, just the need to convince a provider to route it. > > # A sequential allocation of PI space creates the swamp that becomes > # impossible to deal with over time. A structured allocation builds the > option > # that down the road it is possible to enforce exchange point based > # aggregation if and/or where that becomes necessary. It really doesn't > matter > # what structure you choose, the constraint of topology to fit that > structure > # is what reduces the impact on the routing system. The point is to think > # about ways to allocate PI space that will allow for long terms options. > > you're getting way ahead of yourself. assuming we agreed that there was > some kind of regionality now, and was going to continue to be any, we'd > have > to decide whether geographic, or topological, or linguistic, or cultural > regionality made the most sense as outer-block address pool boundaries. > this > whole topic area strikes me as a swamp when i consider the variables > involved, > and it's bothering me that you keep acting as if they're all known > constants. I don't mean to act as if the boundaries are known. I was simply trying to suggest that this is the real discussion point. Right or wrong there will continue to be political/national interests in defining the boundaries differently than the current provider/large-business biased practice. ARIN needs to find a way of representing the interests of the small user (typically not in the room) to respond to this political assault. Building in value judgments will only embolden the political efforts. Tony From paul at vix.com Tue Nov 1 23:11:40 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 02 Nov 2005 04:11:40 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Your message of "Tue, 01 Nov 2005 19:04:18 PST." <120401c5df5a$1f763b60$5ea723c0@tndh.net> References: <120401c5df5a$1f763b60$5ea723c0@tndh.net> Message-ID: <20051102041140.1034011426@sa.vix.com> # > you're still basing assertions on a premise i've disputed, ... # # The assertion is based on the fact that there are a limited number of fiber # runs under the oceans. Yes that number is more than 1, but it is not # numbered in the thousands, and will continue to be limited over time due to # costs. There is no reason for a network in New York to know the gory # details of the traffic engineering in Beijing, any more than the networks in # Beijing need to know the details of local delivery in New York. this is mind boggling. the routers aren't at the landing stations, tony! and in some years, the only way to get IP from one part of europe to another or from one part of asia to another or from one part of south america to another was through new york or palo alto or miami. there is a HUGE need for the folks in beijing to be able to access and traverse the local IP market in new york, and vice versa. and in my view, this is a trend, one that will accelerate and one that is good for the internet and for every user and every provider of internet services. # The entire concept of a global DFZ with detailed traffic engineering # overlays has been about raising the bar to prevent entry by new players. i hold the exact diametrically opposed view. the global DFZ is the only think preventing us from paying $10000/meg to one or three huge providers. # That approach is not required for bit delivery to work. Bit delivery is # possible using transit providers interconnecting exchange based aggregates, # and that would be no more brittle than what we currently have. that's soviet-style central planning thinking you've got going there. yow! sure, you could rebuild MILnet and maybe NSFnet or Internet-2 that way -- but a global IP economy will be organic and unplannable. paraphrasing padlipsky, the territory is under no obligation whatsoever to conform to your map, sir! # ... Allowing everyone to express their policy # in the global view just adds to bloat. i don't like the bloat either. we wouldn't need nearly as many prefixes if our edge could be more dynamic. (once again i lament the death of A6/DNAME.) however, if the edge is to be static, it will be huge. that's the game. # > but we digress. # # I agree with your goal, but recent WiFi efforts show that no matter how lame # the deployments by industry are, as soon as a city steps up for the good of # their citizens those lethargic providers will cry foul. let 'em cry. my money is on gavin. though san francisco needs an internet exchange, and IP providers applying for any kind of permit or license should be required by the city to exchange local routes MLPA-style with other ISP's. (why should i have to use a bicycle messenger rather than FTP to ensure that my bits don't leave town on their way to someone else in the same city? and why should i have to pay the same rate for local delivery as long distance, especially when transporting terrabytes per day?) but we digress. # I don't mean to act as if the boundaries are known. well, but, you are. acting that way, that is. From alh-ietf at tndh.net Wed Nov 2 00:52:15 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Tue, 1 Nov 2005 21:52:15 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051102041140.1034011426@sa.vix.com> Message-ID: <120c01c5df71$95de9ce0$5ea723c0@tndh.net> Paul Vixie wrote: > # > you're still basing assertions on a premise i've disputed, ... > # > # The assertion is based on the fact that there are a limited number of > fiber > # runs under the oceans. Yes that number is more than 1, but it is not > # numbered in the thousands, and will continue to be limited over time due > to > # costs. There is no reason for a network in New York to know the gory > # details of the traffic engineering in Beijing, any more than the > networks in > # Beijing need to know the details of local delivery in New York. > > this is mind boggling. the routers aren't at the landing stations, tony! That is a business decision, not a technical one. > and in some years, the only way to get IP from one part of europe to > another > or from one part of asia to another or from one part of south america to > another was through new york or palo alto or miami. Those were frequently a political decision, and in other cases business ones. There could have been interconnection in those places to avoid routing through remote hops, but the technology allowed them to run long paths so the rest of the world had to deal with it. > there is a HUGE need for > the folks in beijing to be able to access and traverse the local IP market > in new york, and vice versa. and in my view, this is a trend, one that > will > accelerate and one that is good for the internet and for every user and > every provider of internet services. Actually the long term trend is the other way as there are more local exchanges and peering interconnects now than 10 years ago. I can't speak to any recent trend that might be doing traffic engineering around the local options, but the 'need' has more to do with policy than technology. > > # The entire concept of a global DFZ with detailed traffic engineering > # overlays has been about raising the bar to prevent entry by new players. > > i hold the exact diametrically opposed view. the global DFZ is the only > think preventing us from paying $10000/meg to one or three huge providers. We don't need a global DFZ to accomplish the bypass you are alluding to. That is just cheaper than the interface count it would take to run an N-way mesh. These are all just economic trade-offs here because we have the technology to do things differently if we want to. The bottom line is that we don't want to either due to fear of extortion, or just loss of control. > > # That approach is not required for bit delivery to work. Bit delivery is > # possible using transit providers interconnecting exchange based > aggregates, > # and that would be no more brittle than what we currently have. > > that's soviet-style central planning thinking you've got going there. > yow! > sure, you could rebuild MILnet and maybe NSFnet or Internet-2 that way -- > but > a global IP economy will be organic and unplannable. paraphrasing > padlipsky, > the territory is under no obligation whatsoever to conform to your map, > sir! True, though if things get too out of hand the bunch at the UN has the regulatory power to encourage conformance. I am not suggesting we should allow things to get there, just noting that there is a boundary condition in that direction. > > # ... Allowing everyone to express their policy > # in the global view just adds to bloat. > > i don't like the bloat either. we wouldn't need nearly as many prefixes > if > our edge could be more dynamic. (once again i lament the death of > A6/DNAME.) >From my perspective A6/DNAME was not as technically flawed as the fragile DNS infrastructure that it relied on. The biggest problem with A6 is that it seriously stresses the DNS infrastructure as compared with AAAA, and the only reference experience looked more like AAAA than A6. In any case it is not dead so much as parked waiting for someone to show that it won't break everything. > > however, if the edge is to be static, it will be huge. that's the game. > > # > but we digress. > # > # I agree with your goal, but recent WiFi efforts show that no matter how > lame > # the deployments by industry are, as soon as a city steps up for the good > of > # their citizens those lethargic providers will cry foul. > > let 'em cry. my money is on gavin. though san francisco needs an > internet > exchange, and IP providers applying for any kind of permit or license > should > be required by the city to exchange local routes MLPA-style with other > ISP's. > (why should i have to use a bicycle messenger rather than FTP to ensure > that > my bits don't leave town on their way to someone else in the same city? > and > why should i have to pay the same rate for local delivery as long distance, > especially when transporting terrabytes per day?) > > but we digress. Your arguments are fundamentally opposed to each other here. This comment says regulation is appropriate at a city scale while the one above about intercontinental transit should not be regulated. Why shouldn't there be a global requirement for exchange based peering on whatever scale makes sense? Should there be a single exchange for each of San Francisco, San Jose, and Oakland, or one that covers the entire Bay Area, or California? My argument is that the cost of running independent exchanges and transit should be weighed against the cost of routing impact within that area. If local routing scales then deploy one regulated exchange; if it doesn't then deploy more until you fit within what routing can support. The current system looks more like an N-way mesh laid over a shared routing table than anything else. In any case the key ingredient here to mask out the mass of PI space to end sites is that a regulator said 'MUST PEER'. There is nothing magic about a city doing that vs. a national government or the UN. > > # I don't mean to act as if the boundaries are known. > > well, but, you are. acting that way, that is. I will try to act differently, but it is hard to teach an old dog new tricks. Tony From paul at vix.com Wed Nov 2 10:16:44 2005 From: paul at vix.com (Paul Vixie) Date: Wed, 02 Nov 2005 15:16:44 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Your message of "Tue, 01 Nov 2005 21:52:15 PST." <120c01c5df71$95de9ce0$5ea723c0@tndh.net> References: <120c01c5df71$95de9ce0$5ea723c0@tndh.net> Message-ID: <20051102151644.9F33411425@sa.vix.com> # > the routers aren't at the landing stations, tony! # # That is a business decision, not a technical one. when one entity has to decide something, we call it a "decision." when a lot of entities have to decide something, we call it "game theory" or even a "market". but i guess if you think that soviet-style central planning will ever work for the internet, then you would naturally think of the placement of routers wrt landing stations as a "decision". # > paraphrasing padlipsky, the territory is under no obligation whatsoever to # > conform to your map, sir! # # True, though if things get too out of hand the bunch at the UN has the # regulatory power to encourage conformance. um, no. actually, the UN does not have (and should not have, and will never have) that kind of regulatory power. # I am not suggesting we should allow things to get there, just noting that # there is a boundary condition in that direction. in an earlier note i tried to point in the general direction of the absurdity of "boundaries", but i was apparently too subtle. if the IP community were to seek regionalized aggregatability in its block allocations, then "geo" is not what the end users would want. indeed, you'd see outer blocks based on language, culture, religion, and politics before you'd see much geo at all. for example, much of the christian world would want to band their addresses together, and much of the muslim world. probably so they could firewall each other off more efficiently. an outer block for the catalan language, and one for farsi, and so on. if the idea of aggregatability as a block allocation strategy weren't just silly madness, it would grow up to be scary madness. # From my perspective A6/DNAME was not as technically flawed as the fragile # DNS infrastructure that it relied on. The biggest problem with A6 is that it # seriously stresses the DNS infrastructure as compared with AAAA, and the # only reference experience looked more like AAAA than A6. you've given me some insight. A6/DNAME and the dynamic edge it would have enabled was too organic for you and for a lot of others. i get it now. i disagree completely, now as then, since i'm in a pretty good position to know how much stress the DNS infrastructure can take, and i'll say again, A6/DNAME would have been the smaller worry compared to massive PI allocations or SHIM6. # In any case it is not dead so much as parked waiting for someone to show # that it won't break everything. no, actually, it's dead. there's an installed base that begins its flows with AAAA lookups which we've proved cannot be synthesized based on A6 data. there was only one opportunity to fix this, and the "DNS Directorate" ruled it out. (invalidating the installed base isn't on the table.) # > but we digress. # # Your arguments are fundamentally opposed to each other here. This comment # says regulation is appropriate at a city scale while the one above about # intercontinental transit should not be regulated. Why shouldn't there be a # global requirement for exchange based peering on whatever scale makes sense? regulation of this kind makes sense to a group of citizens if they can get away with it. the largest civic unit that can get away with stuff like this is a city. # Should there be a single exchange for each of San Francisco, San Jose, and # Oakland, or one that covers the entire Bay Area, or California? if those cities could somehow learn to work together, and "get away with it", then it would be a fine thing. but they never will, so it doesn't matter what "should" be done, even if we could identify the values and valuer that underlies the "should" in your question, which we can't. # My argument is that the cost of running independent exchanges and transit # should be weighed against the cost of routing impact within that area. weighed by whom? googling for "soviet central planning" is entertaining and educational. especially , whose title is "Why Soviet Central Planning Failed". here's a quote: In Schumpeter's view, the power of the market system lay not in the level of static efficiency that it achieved (as most of the economics profession said it did), but in its level of dynamic efficiency. That is, the success of the market system was not its efficient resource allocation under static levels of technology and resource availability, but its ability to produce dynamic changes in technology and to achieve dynamic growth through such changes. # > well, but, you are. acting that way, that is. # # I will try to act differently, but it is hard to teach an old dog new tricks. i understand that padlipsky's "elements of networking style" is back in print, and reading this could help you with your quest. From Lee.Howard at stanleyassociates.com Wed Nov 2 18:47:21 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 2 Nov 2005 18:47:21 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4800010@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Paul Vixie > Sent: Wednesday, November 02, 2005 10:17 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 or its logical successor > > # True, though if things get too out of hand the bunch at the > UN has the > # regulatory power to encourage conformance. > > um, no. actually, the UN does not have (and should not have, > and will never > have) that kind of regulatory power. I agree with "does not" and "should not," but "will never have" is not clear to me. > if the IP community were > to seek regionalized aggregatability in its block > allocations, then "geo" is not what the end users would want. Current policy is to allocate on geographic regional boundaries. Each RIR allocates from separate IPv4 /8s and IPv6 /23s. The fact that network operators do not aggregate, or that operators connect in multiple regions, is beyond the scope of ARIN to remedy. Lee From alh-ietf at tndh.net Thu Nov 3 14:25:43 2005 From: alh-ietf at tndh.net (Tony Hain) Date: Thu, 3 Nov 2005 11:25:43 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <20051102151644.9F33411425@sa.vix.com> Message-ID: <12fb01c5e0ac$73cf4f50$5ea723c0@tndh.net> Paul Vixie wrote: > ... > # > # True, though if things get too out of hand the bunch at the UN has the > # regulatory power to encourage conformance. > > um, no. actually, the UN does not have (and should not have, and will > never > have) that kind of regulatory power. As the UN true, but the membership has those powers within their own sovereign realm. All they need to do is convince each other to play along. > > # I am not suggesting we should allow things to get there, just noting > that > # there is a boundary condition in that direction. > > in an earlier note i tried to point in the general direction of the > absurdity > of "boundaries", but i was apparently too subtle. if the IP community > were > to seek regionalized aggregatability in its block allocations, then "geo" > is > not what the end users would want. indeed, you'd see outer blocks based > on > language, culture, religion, and politics before you'd see much geo at all. > for example, much of the christian world would want to band their > addresses > together, and much of the muslim world. probably so they could firewall > each > other off more efficiently. an outer block for the catalan language, and > one > for farsi, and so on. if the idea of aggregatability as a block > allocation > strategy weren't just silly madness, it would grow up to be scary madness. Your comments seem to ignore that there are already people that reverse engineer the RIR allocations to derive the geo-political information they want for their firewalls. Yes power is derived from managing information flow and every group would like simpler tools for exercising restrictions. In any case my comments were not about managing firewalls, they were focused on the need for network operators to weed out the crap that unnecessarily consumes resources in their routers. There is a direct conflict between those that want to overlay their policy on the world and those that want the ability to control their own resources. Right now the first group is running amuck and the second is paying the price. The second group needs a rational tool that will allow them to push back. > > # From my perspective A6/DNAME was not as technically flawed as the > fragile > # DNS infrastructure that it relied on. The biggest problem with A6 is > that it > # seriously stresses the DNS infrastructure as compared with AAAA, and the > # only reference experience looked more like AAAA than A6. > > you've given me some insight. A6/DNAME and the dynamic edge it would have > enabled was too organic for you and for a lot of others. i get it now. i > disagree completely, now as then, since i'm in a pretty good position to > know > how much stress the DNS infrastructure can take, and i'll say again, > A6/DNAME > would have been the smaller worry compared to massive PI allocations or > SHIM6. If you will recall I chaired the meeting because I had the neutral position, but that is somewhat irrelevant at this point. There are always going to be conflicting perspectives and people will tend to favor the approach that draws on their experience base. This often (but not necessarily in your case) causes them to overlook or under appreciate the pain that approach will cause from another perspective. PI, Shim6, and A6 all solve different problems. They are related in that they have roots in multi-homed sites, but one solves edge autonomy, one application persistence, and the other core flexibility. Using any one to address the concerns of the others receives howls of incompetence. > > # In any case it is not dead so much as parked waiting for someone to show > # that it won't break everything. > > no, actually, it's dead. there's an installed base that begins its flows > with AAAA lookups which we've proved cannot be synthesized based on A6 > data. > there was only one opportunity to fix this, and the "DNS Directorate" > ruled > it out. (invalidating the installed base isn't on the table.) > > # > but we digress. > # > # Your arguments are fundamentally opposed to each other here. This > comment > # says regulation is appropriate at a city scale while the one above about > # intercontinental transit should not be regulated. Why shouldn't there > be a > # global requirement for exchange based peering on whatever scale makes > sense? > > regulation of this kind makes sense to a group of citizens if they can get > away with it. the largest civic unit that can get away with stuff like > this > is a city. Viewed from the bottom up. Regulators often view from the top down, so countries fit more in their perspective of scale. I am not suggesting that regulation is the right path, just that if it exists it will probably have broader reach. > > # Should there be a single exchange for each of San Francisco, San Jose, > and > # Oakland, or one that covers the entire Bay Area, or California? > > if those cities could somehow learn to work together, and "get away with > it", > then it would be a fine thing. but they never will, so it doesn't matter > what "should" be done, even if we could identify the values and valuer > that > underlies the "should" in your question, which we can't. > > # My argument is that the cost of running independent exchanges and > transit > # should be weighed against the cost of routing impact within that area. > > weighed by whom? googling for "soviet central planning" is entertaining > and > educational. especially > , > whose title is "Why Soviet Central Planning Failed". here's a quote: > > In Schumpeter's view, the power of the market system lay not in the > level of static efficiency that it achieved (as most of the > economics > profession said it did), but in its level of dynamic efficiency. > That > is, the success of the market system was not its efficient resource > allocation under static levels of technology and resource > availability, > but its ability to produce dynamic changes in technology and to > achieve > dynamic growth through such changes. Interesting in that you are essentially arguing that central planning through the ISP/RIR process is mandatory even though it can't deal with the dynamic needs of the end network users. > > # > well, but, you are. acting that way, that is. > # > # I will try to act differently, but it is hard to teach an old dog new > tricks. > > i understand that padlipsky's "elements of networking style" is back in > print, > and reading this could help you with your quest. I will look for it. ;) From owen at delong.com Thu Nov 3 15:22:47 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 03 Nov 2005 12:22:47 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <12fb01c5e0ac$73cf4f50$5ea723c0@tndh.net> References: <12fb01c5e0ac$73cf4f50$5ea723c0@tndh.net> Message-ID: --On November 3, 2005 11:25:43 AM -0800 Tony Hain wrote: > Paul Vixie wrote: >> ... >> # >> # True, though if things get too out of hand the bunch at the UN has the >> # regulatory power to encourage conformance. >> >> um, no. actually, the UN does not have (and should not have, and will >> never >> have) that kind of regulatory power. > > As the UN true, but the membership has those powers within their own > sovereign realm. All they need to do is convince each other to play along. > This is straying _WAY_ off the topic at hand, but, the ITU is the closest you can come to an organized empowerment of this nature, and, fortunately, in spite of their recent efforts in this direction, they don't yet have the power to do so. > Your comments seem to ignore that there are already people that reverse > engineer the RIR allocations to derive the geo-political information they > want for their firewalls. Yes power is derived from managing information > flow and every group would like simpler tools for exercising > restrictions. > However, these are well known to be only marginally accurate in their results. There are lots of ARIN allocations that have presence in EMEA and APAC, many APNIC allocations with addresses in the Americas, and, many RIP allocations with presence outside of EMEA. It works as a rule of thumb, but, it doesn't work as an absolute. > In any case my comments were not about managing firewalls, they were > focused on the need for network operators to weed out the crap that > unnecessarily consumes resources in their routers. There is a direct > conflict between those that want to overlay their policy on the world and > those that want the ability to control their own resources. Right now the > first group is running amuck and the second is paying the price. The > second group needs a rational tool that will allow them to push back. > What both groups need, actually, is a separation between the IDR locator and the End System Identifier. This would allow routing to work in a manner similar to Telco style LNP and I think would solve most of the issue in question. The reality is that the desire to push policy globally is less than the desire to be non-dependent on or locked into any particular ISP and to have some control over ones own destiny. Currently, the only mechanism for doing that is to take up a global policy slot. Your approach provides a mechanism for making that expensive, but, it doesn't address the actual needs of the community. > There are always going to be conflicting perspectives and people will tend > to favor the approach that draws on their experience base. This often (but > not necessarily in your case) causes them to overlook or under appreciate > the pain that approach will cause from another perspective. PI, Shim6, and > A6 all solve different problems. They are related in that they have roots > in multi-homed sites, but one solves edge autonomy, one application > persistence, and the other core flexibility. Using any one to address the > concerns of the others receives howls of incompetence. > True enough, but, PI is, so far, the only one of them that solves the problems that are being expressed by actual organizations that want to adopt V6 but aren't willing to give up capabilities that exist in V4 to do so. Yes, because the V6 working group didn't deliver on their promises, PI has all the same problems in V6 that it did in V4. However, the reality is that when TUBA was abandoned years ago, it was because there was a promise of solving this and other problems in a "better" V6. Now, what we have is a bloated version of TUBA and still a low adoption rate. I'm starting to think that if we don't change how routing works in V6, V6 may be essentially still born. > Viewed from the bottom up. Regulators often view from the top down, so > countries fit more in their perspective of scale. I am not suggesting that > regulation is the right path, just that if it exists it will probably have > broader reach. > The regulation may have broader scope, but, obtaining compliance over any portion of the internet greater than a city is challenging due to the nature of the internet. Often, large-scale regulation is perceived as damage and simply routed around. In any case, can we try to refocus the discussion on what is/is not an appropriate modification to make to 2005-1 to generate useful policy? Thanks, Owen -- If it wasn't crypto-signed, it probably didn't come from me. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From stephen at sprunk.org Wed Nov 9 11:11:50 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 9 Nov 2005 10:11:50 -0600 Subject: [ppml] 2005-1 or its logical successor References: <0f9701c5dce3$473ec4b0$5ea723c0@tndh.net> Message-ID: <022401c5e548$4c44a3e0$6f0016ac@ssprunk> Thus spake cja at daydream.com > As much as I think that geographical addressing could be a good idea, > networks aren't routed geographically. The interconnections aren't there > to make aggregation per your RFC feasible. I believe that currently there > is as much geography taken into account as can be. The RIRs get > blocks for their regions. Some aggregation could be done at that level > depending on how things are connected together. I do not believe that > assigning PI space per your rfc will gain us anything that assigning PI > blocks per region out of a known PI block won't do. You refer in your > note to aggregating the further from the source. Unfortunately "distance" > is assessed on how far topologically in a provider network the traffic > travels, not necessariliy on how far it goes geographically. True, but in the various discussions I've seen of this idea, the natural conclusion seems to be that each geographical area would have an IX that all ISPs using the PI block would be required to connect to, and each ISP would advertise only the aggregate to their transit providers. It appears settlements would be required for traffic coming in on one ISP's links and headed to another ISP's customers; upstream traffic would be handled as it is today. This model effectively trades a BGP routing problem for a money routing problem. Given no significant improvements have been made to BGP for a long time, perhaps it's time to let the bean-counters have their shot? I'm also wondering how many "tier 1" providers would be willing to participate in such a model absent government regulations. Why would UUNET want to do something that makes it easier for their customers to multihome (or rehome) to "tier 2/3" providers or even another "tier 1"? Would we see significant benefits with just the smaller ISPs participating? S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Michael.Dillon at btradianz.com Wed Nov 9 11:37:29 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 9 Nov 2005 16:37:29 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <022401c5e548$4c44a3e0$6f0016ac@ssprunk> Message-ID: > True, but in the various discussions I've seen of this idea, the natural > conclusion seems to be that each geographical area would have an IX that all > ISPs using the PI block would be required to connect to, and each ISP would > advertise only the aggregate to their transit providers. The various geographical or geo-topological addressing models that have been proposed don't MANDATE that an IX must be established in any particular area. It is true that establishing an IX is a logical way to deal with geo addressing, but it could also be done with a local mesh of private interconnects as well. > It appears > settlements would be required for traffic coming in on one ISP's links and > headed to another ISP's customers; upstream traffic would be handled as it > is today. Again, it is not clear whether or not settlements would be required. I suspect that in some regions, geo addressing will simply not be used because operators in that region can't resolve settlement issues. In other areas they will be used without any settlements, probably areas where IXes and route servers are the norm for ISP interconnection. And in other areas, ISPs will find various ways of dealing with settlements. In no case does the geo addressing mandate these things. It is merely an enabler for alternate architectures and alternate interconnect models. It enhances the Internet ecosystem by providing diversity and has a real chance at reducing pressure on the global routing table by giving the long tail of small providers and multihomed organizations a way to solve their diversity problems without consuming slots in everyone's routing table. > This model effectively trades a BGP routing problem for a money routing > problem. Given no significant improvements have been made to BGP for a long > time, perhaps it's time to let the bean-counters have their shot? I agree that it is time for the technologists to stop hogging the entire problem space of Internet routing. Technology is here to serve the creativity of humans, not to restrict and direct that creativity. Maybe it will be bean counters who solve this and maybe it will be small business people, but let's give them the chance. > I'm also wondering how many "tier 1" providers would be willing to > participate in such a model absent government regulations. Big companies are known for being dumb and slow to change. There is no reason why tier 1 Internet providers should be exempt from this rule. Having clueful employees on the payroll does not protect a company from the consequences of "size". --Michael Dillon From billd at cait.wustl.edu Wed Nov 9 11:42:43 2005 From: billd at cait.wustl.edu (Bill Darte) Date: Wed, 9 Nov 2005 10:42:43 -0600 Subject: [ppml] 2005-1 or its logical successor Message-ID: Michael, So do you think if the RIR's decided that policy for IPv6 PI address allocation was similar to what it is today for IPv4....the industry would just have to 'figure it out' and would? Could this actually happen if the requirement for existing holders of IPv4 space were required to go 'wholesale' to v6 to qualify? Not suggesting such a policy, just looking for perspective. Bill Darte ARIN AC > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Wednesday, November 09, 2005 10:37 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 or its logical successor > > > > True, but in the various discussions I've seen of this idea, the > > natural > > > conclusion seems to be that each geographical area would have an IX > > that > all > > ISPs using the PI block would be required to connect to, > and each ISP > would > > advertise only the aggregate to their transit providers. > > The various geographical or geo-topological addressing models > that have been proposed don't MANDATE that an IX must be > established in any particular area. It is true that > establishing an IX is a logical way to deal with geo > addressing, but it could also be done with a local mesh of > private interconnects as well. > > > It appears > > settlements would be required for traffic coming in on one > ISP's links > and > > headed to another ISP's customers; upstream traffic would > be handled > > as > it > > is today. > > Again, it is not clear whether or not settlements would be > required. I suspect that in some regions, geo addressing will > simply not be used because operators in that region can't > resolve settlement issues. In other areas they will be used > without any settlements, probably areas where IXes and route > servers are the norm for > ISP interconnection. And in other areas, ISPs will find > various ways of dealing with settlements. > > In no case does the geo addressing mandate these things. It > is merely an enabler for alternate architectures and > alternate interconnect models. It enhances the Internet > ecosystem by providing diversity and has a real chance at > reducing pressure on the global routing table by giving the > long tail of small providers and > multihomed organizations a way to solve their diversity > problems without consuming slots in everyone's routing table. > > > This model effectively trades a BGP routing problem for a money > > routing > > problem. Given no significant improvements have been made > to BGP for a > long > > time, perhaps it's time to let the bean-counters have their shot? > > I agree that it is time for the technologists to stop hogging > the entire problem space of Internet routing. Technology is > here to serve the creativity of humans, not to restrict and > direct that creativity. Maybe it will be bean counters who > solve this and maybe it will be small business people, but > let's give them the chance. > > > I'm also wondering how many "tier 1" providers would be willing to > > participate in such a model absent government regulations. > > Big companies are known for being dumb and slow to change. > There is no reason why tier 1 Internet providers should be > exempt from this rule. Having clueful employees on the > payroll does not protect a > company from the consequences of "size". > > --Michael Dillon > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From hannigan at verisign.com Wed Nov 9 11:42:30 2005 From: hannigan at verisign.com (Hannigan, Martin) Date: Wed, 9 Nov 2005 11:42:30 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: [ SNIP ] > I'm also wondering how many "tier 1" providers would be willing to > participate in such a model absent government regulations. > Why would UUNET > want to do something that makes it easier for their customers > to multihome > (or rehome) to "tier 2/3" providers or even another "tier 1"? > Would we see > significant benefits with just the smaller ISPs participating? Anti-trust, (IANAL)I'm guessing. The same reason MS has to allow you to use others browsers and tools on their operating system. -M< From Lee.Howard at stanleyassociates.com Wed Nov 9 11:44:50 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 9 Nov 2005 11:44:50 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Stephen Sprunk > Sent: Wednesday, November 09, 2005 11:12 AM > To: cja at daydream.com; Tony Hain > Cc: ARIN PPML > Subject: Re: [ppml] 2005-1 or its logical successor > > True, but in the various discussions I've seen of this idea, > the natural > conclusion seems to be that each geographical area would have > an IX that all > ISPs using the PI block would be required to connect to, and > each ISP would > advertise only the aggregate to their transit providers. It appears > settlements would be required for traffic coming in on one > ISP's links and > headed to another ISP's customers; upstream traffic would be > handled as it > is today. What's the transition plan, if these IXs don't exist now? Are these IXs required by law, by policy, or something else? Are they privately-owned monopolies, or publicly-owned monopolies? > > This model effectively trades a BGP routing problem for a > money routing > problem. Given no significant improvements have been made to > BGP for a long > time, perhaps it's time to let the bean-counters have their shot? I hear a lot of support for settlements from telcos, some from governments, and little from network people. It effectively drives hosting companies out of business, if they have to pay for transit (settlement for inbound traffic) but carriers get to charge at both ends of the stream. Is there evidence that this model provides a network that is better, faster, or cheaper? If economists set addressing policy, can network engineers set monetary policy? > I'm also wondering how many "tier 1" providers would be willing to > participate in such a model absent government regulations. > Why would UUNET > want to do something that makes it easier for their customers > to multihome > (or rehome) to "tier 2/3" providers or even another "tier 1"? > Would we see > significant benefits with just the smaller ISPs participating? Because those providers are inferior. The phrase used to be, "What's good for the Internet is good for UUNET." That's tongue-in-cheek, of course. However, the same company owns UUNET and MAE-*, so there might be some interest, but I think having a single point of failure (nuke the IX) in each geographical area sounds contrary to good internetwork design. Lee > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin From stephen at sprunk.org Wed Nov 9 15:38:25 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Wed, 9 Nov 2005 14:38:25 -0600 Subject: [ppml] 2005-1 or its logical successor References: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com> Message-ID: <02ca01c5e56d$895a0020$6f0016ac@ssprunk> Thus spake "Howard, W. Lee" >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> Behalf Of Stephen Sprunk > >> True, but in the various discussions I've seen of this idea, >> the natural conclusion seems to be that each geographical >> area would have an IX that all ISPs using the PI block would >> be required to connect to, and each ISP would advertise >> only the aggregate to their transit providers. It appears >> settlements would be required for traffic coming in on one >> ISP's links and headed to another ISP's customers; >> upstream traffic would be handled as it is today. > > What's the transition plan, if these IXs don't exist now? Interesting question, and one of the stumbling blocks to getting this approach deployed. > Are these IXs required by law, by policy, or something else? > Are they privately-owned monopolies, or publicly-owned > monopolies? They're effectively required at a technical level, though I don't see them getting created without government regulation. In the absence of the latter, I'd suspect they'd be set up as non-profits owned by their members or something similar; if the gov't got involved, I'd expect them to be private for-profit companies selected by bribed politicians. >> This model effectively trades a BGP routing problem for a >> money routing problem. Given no significant improvements >> have been made to BGP for a long time, perhaps it's time >> to let the bean-counters have their shot? > > I hear a lot of support for settlements from telcos, > some from governments, and little from network people. > It effectively drives hosting companies out of business, > if they have to pay for transit (settlement for inbound > traffic) but carriers get to charge at both ends of the > stream. OTOH, people with big upstream pipes, like hosters, could end up receiving huge settlement checks for inbound traffic on pipes that are today only filled in one direction. I've seen no data to indicate that the net movement of money would be substantially different under this plan (or that it wouldn't, for that matter). > Is there evidence that this model provides a network > that is better, faster, or cheaper? It's arguably "better" and "faster" because local traffic stays local and inbound traffic takes the most direct route; at a macro level, both are good for the Internet. Less long-haul traffic means transit prices should drop, leading to "cheaper". Also, by replacing PI-based multihoming with IX-based multihoming, there is less pressure on the DFZ, leading to cheaper routers, or at least less-frequent upgrades. And multihoming, at least within one "area", becomes significantly cheaper and easier, which a lot of end sites would call "better". However, I don't think any ISPs in isolation would see enough "better, faster, cheaper" to justify making the move. It only works if everyone does it, which is contrary to human nature. We're long past the days of doing things for the common good, at least when they require a fundamental change in business models. > If economists set addressing policy, can network engineers > set monetary policy? Non-sequitur. >> I'm also wondering how many "tier 1" providers would be willing to >> participate in such a model absent government regulations. >> Why would UUNET want to do something that makes it easier >> for their customers to multihome (or rehome) to "tier 2/3" >> providers or even another "tier 1"? Would we see >> significant benefits with just the smaller ISPs participating? > > Because those providers are inferior. The phrase used > to be, "What's good for the Internet is good for UUNET." > That's tongue-in-cheek, of course. However, the same > company owns UUNET and MAE-*, so there might be some > interest, I don't buy that argument. I can't think of a reason that an IX-based model would improve a "tier 1's" profitability, and can think of several reasons they wouldn't. At best, I see them grudgingly joining the club after all of the "tier 2/3" players form a united front and use it as a marketing tactic. And owning an IX here or there isn't meaningful when we're talking about an order of magnitude (or two) growth in the number of IXen -- unless one manages to get a profitable contract operating a number of them. > but I think having a single point of failure (nuke the IX) in > each geographical area sounds contrary to good > internetwork design. Dillon points out that an IX isn't strictly required; for small enough numbers of participants, you could create a full mesh of private connections. You could also do this as a backup for the IX. If the mesh isn't full (due to circuit failures, most likely, or due to IX failure), the partially-connected party(ies) would have to leak more-specifics upstream and withdraw the aggregate, but obviously this degenerates to today's PI situation (and possibly worse) if not quickly corrected. Global impact of a local problem is a Bad Thing(tm). All in all, I'm not sure I support this idea. It's technically interesting, but I'm not sure if it's viable in today's market. If we'd done it a decade ago, however... S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Lee.Howard at stanleyassociates.com Wed Nov 9 16:44:33 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Wed, 9 Nov 2005 16:44:33 -0500 Subject: [ppml] 2005-1 or its logical successor Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB492256E@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: Stephen Sprunk [mailto:stephen at sprunk.org] > Sent: Wednesday, November 09, 2005 3:38 PM > To: Howard, W. Lee; cja at daydream.com; Tony Hain > Cc: ARIN PPML > Subject: Re: [ppml] 2005-1 or its logical successor > > Thus spake "Howard, W. Lee" > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >> Behalf Of Stephen Sprunk > > > >> True, but in the various discussions I've seen of this idea, > >> the natural conclusion seems to be that each geographical > >> area would have an IX that all ISPs using the PI block would > >> be required to connect to, and each ISP would advertise > >> only the aggregate to their transit providers. It appears > >> settlements would be required for traffic coming in on one > >> ISP's links and headed to another ISP's customers; > >> upstream traffic would be handled as it is today. > > > > What's the transition plan, if these IXs don't exist now? > > Interesting question, and one of the stumbling blocks to getting this > approach deployed. > > > Are these IXs required by law, by policy, or something else? > > Are they privately-owned monopolies, or publicly-owned > > monopolies? > > They're effectively required at a technical level, though I > don't see them > getting created without government regulation. In the absence of the > latter, I'd suspect they'd be set up as non-profits owned by > their members > or something similar; if the gov't got involved, I'd expect > them to be > private for-profit companies selected by bribed politicians. > > >> This model effectively trades a BGP routing problem for a > >> money routing problem. Given no significant improvements > >> have been made to BGP for a long time, perhaps it's time > >> to let the bean-counters have their shot? > > > > I hear a lot of support for settlements from telcos, > > some from governments, and little from network people. > > It effectively drives hosting companies out of business, > > if they have to pay for transit (settlement for inbound > > traffic) but carriers get to charge at both ends of the > > stream. > > OTOH, people with big upstream pipes, like hosters, could end > up receiving > huge settlement checks for inbound traffic on pipes that are > today only > filled in one direction. I've seen no data to indicate that the net > movement of money would be substantially different under this > plan (or that it wouldn't, for that matter). I don't understand. HTTP traffic is typically lopsided outbound from the server. Are you suggesting hosting companies would charge more per inbound bit than carriers, or that they'd develop new traffic/business models? Or did I misunderstand which direction pays whom? > It's arguably "better" and "faster" because local traffic > stays local and > inbound traffic takes the most direct route; at a macro > level, both are good > for the Internet. Less long-haul traffic means transit > prices should drop, leading to "cheaper". No more cold-potato routing. OK. > However, I don't think any ISPs in isolation would see enough > "better, > faster, cheaper" to justify making the move. It only works > if everyone does > it, which is contrary to human nature. We're long past the > days of doing > things for the common good, at least when they require a > fundamental change in business models. Maybe we should just give very large blocks to exchanges, which they could assign to customers for regional use. In addition to current policy. > > However, the same > > company owns UUNET and MAE-*, so there might be some > > interest, > > I don't buy that argument. I can't think of a reason that an > IX-based model > would improve a "tier 1's" profitability, and can think of > several reasons they wouldn't. Ehh, yeah, but they'd have a good shot at being first mover, or beating competing IX-builders based on name recognition. > > but I think having a single point of failure (nuke the IX) in > > each geographical area sounds contrary to good > > internetwork design. > > Dillon points out that an IX isn't strictly required; for Yes, that's a good point. I'd like it to scale, and I'm wondering if there's an intermediate position where there's a regional aggregate but non-IX-ians leak more specifics. Need to sit down at a whiteboard for a few minutes on that one. > > All in all, I'm not sure I support this idea. It's > technically interesting, > but I'm not sure if it's viable in today's market. If we'd > done it a decade ago, however... I misunderstood you then, and thought you were advocating. Is anyone formulating a proposal for geographically-based allocations/assignments based on this discussion? Lee > > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin > From christopher.morrow at gmail.com Wed Nov 9 23:22:49 2005 From: christopher.morrow at gmail.com (Christopher Morrow) Date: Wed, 9 Nov 2005 23:22:49 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <02ca01c5e56d$895a0020$6f0016ac@ssprunk> References: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com> <02ca01c5e56d$895a0020$6f0016ac@ssprunk> Message-ID: <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> On 11/9/05, Stephen Sprunk wrote: > Thus spake "Howard, W. Lee" > >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > >> Behalf Of Stephen Sprunk > > I hear a lot of support for settlements from telcos, > > some from governments, and little from network people. > > It effectively drives hosting companies out of business, I'd be concerned, am concerned, about 'settlement' situations. Perhaps its a misunderstanding of them on my part though :) I'd be concerned that there are more than 2 parties involved in the conversation, and potentially someone in the middle could bend traffic paths to influence their business needs (putting competition out of business or just censoring people?) Anyway, probably not a topic for this conversation, just worrisome :) (knowing how evil bean counters can be...) > > if they have to pay for transit (settlement for inbound > > traffic) but carriers get to charge at both ends of the > > stream. > > OTOH, people with big upstream pipes, like hosters, could end up receiving > huge settlement checks for inbound traffic on pipes that are today only > filled in one direction. I've seen no data to indicate that the net If they charge lots of settlement, perhaps people won't send packets their way? or will degrade performance intentionally? Or force that traffic through a competitor to impale them on a higher cost link :( > movement of money would be substantially different under this plan (or that > it wouldn't, for that matter). > > > Is there evidence that this model provides a network > > that is better, faster, or cheaper? > > It's arguably "better" and "faster" because local traffic stays local and > inbound traffic takes the most direct route; at a macro level, both are good > for the Internet. Less long-haul traffic means transit prices should drop, > leading to "cheaper". it takes the most direct route assuming no funny monkey business with routing... assuming people don't have capacity problems in region (or at the IX) and don't force traffic on non-optimal paths. > > Also, by replacing PI-based multihoming with IX-based multihoming, there is > less pressure on the DFZ, leading to cheaper routers, or at least I am not sure that local/regional IXP proliferation is going to help the DFZ folks all that much in the end. It may remove direct connections and direct allocations from their tables. It would essentially aggregate all customers in region behind one prefix. Eventually the 'regional' IXP would have to become a County IXP then a City IXP then Town IXP, proliferating the number of IXP's to a very large number (how many towns exist in the USA alone? Does this really drop the DFZ table that much? Additionally, the DFZ folks now become the 'LD carrier' of the Internet and since they don't have direct customers they arrange 'settlement' with the IXPs I suppose? I'm not sure this gets us to the end goal either. > less-frequent upgrades. And multihoming, at least within one "area", > becomes significantly cheaper and easier, which a lot of end sites would > call "better". How is a local IXP 'multihoming' me? it's getting me a connection to a single 'carrier' with lots of bgp options... or I'm again confused. It may get me more than one pipe to the IXP and more bgp options on each, and now the IXP-truck-bomb is my failure scenario (and much easier I'd think). > > but I think having a single point of failure (nuke the IX) in > > each geographical area sounds contrary to good > > internetwork design. > me too -Chris From tvest at pch.net Thu Nov 10 00:34:05 2005 From: tvest at pch.net (Tom Vest) Date: Thu, 10 Nov 2005 00:34:05 -0500 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com> <02ca01c5e56d$895a0020$6f0016ac@ssprunk> <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> Message-ID: <5D01CB91-95D4-4746-B308-BD3EBD3BC28C@pch.net> On Nov 9, 2005, at 11:22 PM, Christopher Morrow wrote: > On 11/9/05, Stephen Sprunk wrote: >> Thus spake "Howard, W. Lee" >>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >>>> Behalf Of Stephen Sprunk > >>> I hear a lot of support for settlements from telcos, >>> some from governments, and little from network people. >>> It effectively drives hosting companies out of business, > > I'd be concerned, am concerned, about 'settlement' situations. Perhaps > its a misunderstanding of them on my part though :) I'd be concerned > that there are more than 2 parties involved in the conversation, and > potentially someone in the middle could bend traffic paths to > influence their business needs (putting competition out of business or > just censoring people?) Anyway, probably not a topic for this > conversation, just worrisome :) (knowing how evil bean counters can > be...) Be afraid, be very afraid. The bean counters that are nostalgic for this must have very short memories -- or very questionable intentions. Most developing country telcos vacated the old geographic settlement system for international voice services back in 1997 because it had ceased to be viable. Why? Because prices and the value of currencies vary across markets, and these variations (plus new technology) tempted some operators to suppress demand in their own markets (to maximize their external settlement receipts), and tempted some others to offshore their service platform in order to voice spam their own markets, which also pumped up their home market settlement receipts. The cost of these diversions reached the tens of billions of $US by 1996, which prompted the US to lead the charge to the door shortly thereafter. So long as costs, prices, and currencies vary between markets, and its technically/institutionally possible to play such tricks, arbitrage will confound any effort to map economic sanity onto whatever benefits this arrangement might provide in terms of routing sanity/bloat deceleration. To date, the only proven way to avoid such arbitrage is to operate a hermetically sealed network, where everything coming in/out is closely monitored... Which, sadly, is not to say that that little complication would unacceptable to everyone. If you hear a developing country telco advocating settlements, they're probably remembering the good old days when international settlement receipts helped to cross-subsidize domestic government services. You hear a rich country telco advocating something like this, you can bet they're doing it with full understanding of what would be required to make it work economically. Be very afraid... >>> if they have to pay for transit (settlement for inbound >>> traffic) but carriers get to charge at both ends of the >>> stream. >> >> OTOH, people with big upstream pipes, like hosters, could end up >> receiving >> huge settlement checks for inbound traffic on pipes that are today >> only >> filled in one direction. I've seen no data to indicate that the net > > If they charge lots of settlement, perhaps people won't send packets > their way? or will degrade performance intentionally? Or force that > traffic through a competitor to impale them on a higher cost link :( >> movement of money would be substantially different under this plan >> (or that >> it wouldn't, for that matter). >> >>> Is there evidence that this model provides a network >>> that is better, faster, or cheaper? >> >> It's arguably "better" and "faster" because local traffic stays >> local and >> inbound traffic takes the most direct route; at a macro level, >> both are good >> for the Internet. Less long-haul traffic means transit prices >> should drop, >> leading to "cheaper". > > it takes the most direct route assuming no funny monkey business with > routing... assuming people don't have capacity problems in region (or > at the IX) and don't force traffic on non-optimal paths. > >> >> Also, by replacing PI-based multihoming with IX-based multihoming, >> there is >> less pressure on the DFZ, leading to cheaper routers, or at least > > I am not sure that local/regional IXP proliferation is going to help > the DFZ folks all that much in the end. It may remove direct > connections and direct allocations from their tables. It would > essentially aggregate all customers in region behind one prefix. > Eventually the 'regional' IXP would have to become a County IXP then a > City IXP then Town IXP, proliferating the number of IXP's to a very > large number (how many towns exist in the USA alone? Does this really > drop the DFZ table that much? > > Additionally, the DFZ folks now become the 'LD carrier' of the > Internet and since they don't have direct customers they arrange > 'settlement' with the IXPs I suppose? I'm not sure this gets us to the > end goal either. > >> less-frequent upgrades. And multihoming, at least within one "area", >> becomes significantly cheaper and easier, which a lot of end sites >> would >> call "better". > > How is a local IXP 'multihoming' me? it's getting me a connection to a > single 'carrier' with lots of bgp options... or I'm again confused. It > may get me more than one pipe to the IXP and more bgp options on each, > and now the IXP-truck-bomb is my failure scenario (and much easier I'd > think). > >>> but I think having a single point of failure (nuke the IX) in >>> each geographical area sounds contrary to good >>> internetwork design. >> > > me too > > -Chris > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From owen at delong.com Thu Nov 10 03:45:18 2005 From: owen at delong.com (Owen DeLong) Date: Thu, 10 Nov 2005 00:45:18 -0800 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> References: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociat es.com> <02ca01c5e56d$895a0020$6f0016ac@ssprunk> <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> Message-ID: <7E9FBE55404FE87D082D50D8@odpwrbook.hq.netli.lan> Folks, While geographical addressing proposals may be a valid topic of discussion for ARIN policy, they are _NOT_ part of the 2005-1 proposal. Can we please move the geographical addressing discussion on to another subject-line/thread? Thanks, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Thu Nov 10 05:10:48 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 10 Nov 2005 10:10:48 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: Message-ID: > So do you think if the RIR's decided that policy for IPv6 PI address > allocation was similar to what it is today for IPv4....the industry would > just have to 'figure it out' and would? Could this actually happen if the > requirement for existing holders of IPv4 space were required to go > 'wholesale' to v6 to qualify? The industry is good at dealing with constraints and figuring out the optimal way to live within those constraints. But there is a difference between a constraint and an order to change something. A requirement for a wholesale transition to IPv6 is more like an order than like a constraint. ARIN policies, no matter how liberal they may appear to some, are always constraints. I think our job is to make sure that the constraints are not more restrictive than necessary. The industry could live with IPv6 policies that are more or less parallels of the IPv4 policies, but I think that is making things more constrained than necessary. The IPv6 address space is large enough to allow for alternative addressing models. I think it is wise to extend the current geo-topological addressing of the 5 regional RIRs to another level based on the major cities within the RIR regions. But rather than constrain everyone to go along with such a new model, I think it better to do this as a parallel IPv6 address space using some of the large amount of space reserved for other addressing models. That way, industry has a real choice. I don't expect ISPs in Montana to make the same choices as ISPs in New York but I do expect that we will learn from the choices that ISPs make. --Michael Dillon From Michael.Dillon at btradianz.com Thu Nov 10 05:22:02 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 10 Nov 2005 10:22:02 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com> Message-ID: > What's the transition plan, if these IXs don't exist now? > Are these IXs required by law, by policy, or something else? > Are they privately-owned monopolies, or publicly-owned > monopolies? ARIN deals with this problem the same way that it deals with BGP prefix filters. When ARIN went from a /19 to a /20 as the minimum sized address block we did not pass a law requiring ISPs to change the prefix filters. We didn't even make a policy requiring ISPs to change address filters. ARIN enables things like local peering IXes but neither mandates them nor manages the process of creating them. > I hear a lot of support for settlements from telcos, > some from governments, and little from network people. > It effectively drives hosting companies out of business, > if they have to pay for transit (settlement for inbound > traffic) but carriers get to charge at both ends of the > stream. I don't believe any of the talk about settlements. When settlements become the norm they won't look like what people talk about today. Since settlements have to be negotiated they will look more like the secret SFI peering and paid peering agreements that currently exist. In other words, we are well down the road to settlements. In any case, settlements are not the job of ARIN or any of the RIRs. > Is there evidence that this model provides a network > that is better, faster, or cheaper? Some people believe that imposing one business model in all regions and all cities results in a network that is better, faster and cheaper in only the largest population centers. > but I think having a single point of failure > (nuke the IX) in each geographical area sounds contrary > to good internetwork design. Quite true. That is why ARIN should not address the IX issue. Let the engineers deal with it. They will probably build a model with 3 or more IXes in every city with good interconnections between them. In some cities that may be a single IX with bridging to 3 or more locations. In others, the detail will all be visible at the IP layer. These are not issues for an RIR to deal with other than to know that the technology is available. -- Michael Dillon From Michael.Dillon at btradianz.com Thu Nov 10 05:42:40 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 10 Nov 2005 10:42:40 +0000 Subject: [ppml] 2005-1 or its logical successor In-Reply-To: <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> Message-ID: > Eventually the 'regional' IXP would have to become a County IXP then a > City IXP then Town IXP, proliferating the number of IXP's to a very > large number (how many towns exist in the USA alone? Does this really > drop the DFZ table that much? According to UN statistics there are about 5,000 cities in the world with population of 100,000 or greater. We already have geo addressing at the RIR level, more or less. I think we either need to pick a city size, like 100,000, as the next level of aggregation or, possibly, pick one level in between. This would mean that any smaller towns need to join in the aggregate for the nearest (or dearest) town of 100,000 or greater. At the regional level I can see North America being split into eastern and western regions. Possibly there could be a central region as well and if you include Canada in your thinking, I would also see a north/south split with the dividing line running somewhere south of DC, south of Kansas City, and south of Portland. If anyone is serious about doing work on where the natural regional groupings are for North America I would recommend looking at Telegeography's data and also I would recommend studying freight dispatching systems which have also divided North America into dispatch zones. State boundaries and LATAs are too small for this exercise. We don't really need to aggregate cities into more than half a dozen regions or so, per continent. > Additionally, the DFZ folks now become the 'LD carrier' of the > Internet and since they don't have direct customers they arrange > 'settlement' with the IXPs I suppose? I'm not sure this gets us to the > end goal either. What is the difference between settlement and transit? Settlement and paid peering? Maybe it is just terminology. > How is a local IXP 'multihoming' me? it's getting me a connection to a > single 'carrier' with lots of bgp options... or I'm again confused. There is no single model for this. Maybe the IXP sells you Internet access circuits with no ISP at the other end. Then you buy a cross connect from one of the ISPs at the IXP. If you want to you can buy multiple access circuits, and then buy your cross connects from separate ISPs. I believe Savvis started out in life with a very similar model. > It > may get me more than one pipe to the IXP and more bgp options on each, > and now the IXP-truck-bomb is my failure scenario (and much easier I'd > think). Even in a city with 100,000 people, I believe that there should be a minimum of 3 IXP locations or 3 separate IXPs. That is the architecture for the 22nd century and that is the goal which we should be striving towards. If enough people understand the implications of single points of failure in a world where everything happens on the network then customers will demand this and ISPs/IXPs will build this. I realize that today, there is not a universal business case for building that kind of architecture, especially within a single company. But when making policy we must look at the larger picture which includes corporate evolution and industry evolution as well. --Michael Dillon From stephen at sprunk.org Thu Nov 10 08:14:30 2005 From: stephen at sprunk.org (Stephen Sprunk) Date: Thu, 10 Nov 2005 07:14:30 -0600 Subject: [ppml] geo addressing (was: Re: 2005-1 or its logical successor) References: <369EB04A0951824ABE7D8BAC67AF9BB492241F@CL-S-EX-1.stanleyassociates.com><02ca01c5e56d$895a0020$6f0016ac@ssprunk> <75cb24520511092022r33a12e95y4345647a4d105338@mail.gmail.com> Message-ID: <009701c5e5f8$cbef60c0$5a84a13f@ssprunk> Thus spake "Christopher Morrow" > On 11/9/05, Stephen Sprunk wrote: >> Thus spake "Howard, W. Lee" >> >> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On >> >> Behalf Of Stephen Sprunk > >> > I hear a lot of support for settlements from telcos, >> > some from governments, and little from network people. >> > It effectively drives hosting companies out of business, > > I'd be concerned, am concerned, about 'settlement' situations. Perhaps > its a misunderstanding of them on my part though :) I'd be concerned > that there are more than 2 parties involved in the conversation, and > potentially someone in the middle could bend traffic paths to > influence their business needs (putting competition out of business or > just censoring people?) Anyway, probably not a topic for this > conversation, just worrisome :) (knowing how evil bean counters can > be...) > >> > if they have to pay for transit (settlement for inbound >> > traffic) but carriers get to charge at both ends of the >> > stream. >> >> OTOH, people with big upstream pipes, like hosters, could end up >> receiving huge settlement checks for inbound traffic on pipes that >> are today only filled in one direction. I've seen no data to indicate >> that the net > > If they charge lots of settlement, perhaps people won't send packets > their way? or will degrade performance intentionally? Or force that > traffic through a competitor to impale them on a higher cost link :( Since all IX members would be advertising the same aggregate to their upstreams, inbound traffic necessarily flows to the member closest to the source. All one can do is _prevent_ traffic from reaching you by not advertising, prepending, etc. but why would they do that when they stand to make money for every bit of yours that comes in and avoid paying you for every bit of theirs they get directly? >> > Is there evidence that this model provides a network >> > that is better, faster, or cheaper? >> >> It's arguably "better" and "faster" because local traffic stays local and >> inbound traffic takes the most direct route; at a macro level, both are >> good >> for the Internet. Less long-haul traffic means transit prices should >> drop, >> leading to "cheaper". > > it takes the most direct route assuming no funny monkey business with > routing... assuming people don't have capacity problems in region (or > at the IX) and don't force traffic on non-optimal paths. Assuming the settlement rate is comparable to or higher than the current transit rate (something nobody has addressed so far), everyone has a financial incentive to build as much inbound capacity and attract as much inbound traffic as possible. >> Also, by replacing PI-based multihoming with IX-based multihoming, >> there is less pressure on the DFZ, leading to cheaper routers, or at >> least > > I am not sure that local/regional IXP proliferation is going to help > the DFZ folks all that much in the end. It may remove direct > connections and direct allocations from their tables. It would > essentially aggregate all customers in region behind one prefix. > Eventually the 'regional' IXP would have to become a County IXP then a > City IXP then Town IXP, proliferating the number of IXP's to a very > large number (how many towns exist in the USA alone? Does this really > drop the DFZ table that much? There are ~3000 counties in the US; while all of them certainly don't need their own IX, even if we did something that nutty 3000 routes for the US is a clear improvement over the status quo. If we restricted "areas" to, say, the so-called NFL cities or something similar, we'd have another two orders of magnitude reduction in routes. There's certainly the possibility of IXes above the first level, but I haven't thought that much about how it would be accomplished. Frankly, I think we'd be okay with 3000 routes for the US, and I'm not sure that getting it down to 1 route is worth the extra hassle. > Additionally, the DFZ folks now become the 'LD carrier' of the > Internet and since they don't have direct customers they arrange > 'settlement' with the IXPs I suppose? I'm not sure this gets us to the > end goal either. The way I've seen it described, there's nothing preventing any ISP from selling transit to any other or to end sites; the only thing is that to use the IX-based addresses in a given area, they'd need to peer at the IX (and join the settlement scheme). So, your promising local ISP could join the IX, sell a customer a connection, buy transit from UUNET et al, and nothing much would change except that (a) your customer could multihome (or rehome) to any other IX member without any new routes in the DFZ, (b) you would get settlement check for traffic coming in on your transit pipes headed for other IX members, and (c) you'd send settlement checks for traffic coming in on other IX members' transit pipes headed for your customers. I'd originally looked at this without settlements, thinking that the benefits to all would provide the motivation. Unfortunately, that _does_ lead to the inbound traffic problems you describe. Ironically, with settlements I think everyone will build to the point their settlement revenue/expense will be roughly zero -- and as a side effect build a more efficient Internet for everyone. >> less-frequent upgrades. And multihoming, at least within one "area", >> becomes significantly cheaper and easier, which a lot of end sites would >> call "better". > > How is a local IXP 'multihoming' me? it's getting me a connection to a > single 'carrier' with lots of bgp options... or I'm again confused. It > may get me more than one pipe to the IXP and more bgp options on each, > and now the IXP-truck-bomb is my failure scenario (and much easier I'd > think). As I said, there are (ugly) ways of handling failure of a single IX. The better solution is to have multiple IXen per "area". Frankly, in most fiber hub cities there's a handful of buildings to bomb and you could take down most of the Internet (heck, the phone network) within hundreds of miles. Competent folks would look at how much redundancy is logical for a given physical plant and build to that level -- and no more. S Stephen Sprunk "Stupid people surround themselves with smart CCIE #3723 people. Smart people surround themselves with K5SSS smart people who disagree with them." --Aaron Sorkin From Michael.Dillon at btradianz.com Thu Nov 10 09:59:36 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 10 Nov 2005 14:59:36 +0000 Subject: [ppml] geo addressing In-Reply-To: <009701c5e5f8$cbef60c0$5a84a13f@ssprunk> Message-ID: > Assuming the settlement rate is comparable to or higher than the current > transit rate (something nobody has addressed so far), everyone has a > financial incentive to build as much inbound capacity and attract as much > inbound traffic as possible. I think that I did address this. Settlement in an Internet context is not much different from transit or paid peering. Therefore, the companies invloved will negotiate rates and terms just as they do with transit, paid peering, and SFI peering. It's not up to us to solve this problem. We are not the FCC of the Internet. We just give out IPv6 addresses to companies to *ENABLE* them to internetwork. By creating this geotopological addressing scheme we enable companies by allowing them to reduce the footprint that a region makes in the DFZ or global routing table if you prefer. And it also enables companies by giving them a handy traffic tag that tells them how far the traffic travelled to reach the peering point. I expect that this will help companies distinguish between hot-potato traffic and cold-potato traffic and therefore allow them to come up with a reasonable charging scheme for their settlements. However, unlike the traditional telco settlements, this does not require accounting for every network session. It still deals with traffic in the aggregate by lumping together all traffic that comes from a particular city into the same address range. This will allow a much more efficient accounting system than the telco model which, in the latter half of the 1990's, still constituted 75% or more of your telephone bill. As for traffic that is not using geo-topological addresses, it can continue in the way it always has, with the usual depeering games and secret paid peering deals to avoid the appearance of being a second class "transit" customer. > The way I've seen it described, there's nothing preventing any ISP from > selling transit to any other or to end sites; the only thing is that to use > the IX-based addresses in a given area, they'd need to peer at the IX (and > join the settlement scheme). It's all about opting in. Companies will join the scheme if it makes sense. The scheme will evolve to meet the needs of network operators and customers. The long tail of small multihomers that will spring up over the next 10 years will mostly be served by geotopologically aggregates and the growth of routing tables world-wide will be dampened. Even if an old-time tier one doesn't want to switch to geo-topological addresses, there is still a business case to be made for serving small to mid-size customers using this scheme. > (b) you would get settlement check > for traffic coming in on your transit pipes headed for other IX members, and > (c) you'd send settlement checks for traffic coming in on other IX members' > transit pipes headed for your customers. I would hope that this would be done without huge numbers of checks. In fact, the IX could be in a position to mediate the financial exchanges as well as providing interconnect services. --Michael Dillon From Lee.Howard at stanleyassociates.com Thu Nov 10 11:25:04 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 10 Nov 2005 11:25:04 -0500 Subject: [ppml] geo addressing Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB4922791@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Thursday, November 10, 2005 5:22 AM > To: ppml at arin.net > Subject: Re: [ppml] 2005-1 or its logical successor > > > What's the transition plan, if these IXs don't exist now? > > Are these IXs required by law, by policy, or something else? > > Are they privately-owned monopolies, or publicly-owned > > monopolies? > > ARIN deals with this problem the same way that it > deals with BGP prefix filters. When ARIN went from > a /19 to a /20 as the minimum sized address block > we did not pass a law requiring ISPs to change the > prefix filters. We didn't even make a policy requiring > ISPs to change address filters. > > ARIN enables things like local peering IXes but > neither mandates them nor manages the process of > creating them. Would you propose allocating /x to regional IXen? Of a certain size, or serving a certain (defined how?) region? In addition to or lieu of existing policy? IPv4 and/or/xor IPv6? > -- Michael Dillon Lee From Lee.Howard at stanleyassociates.com Thu Nov 10 12:20:49 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Thu, 10 Nov 2005 12:20:49 -0500 Subject: [ppml] geo addressing (was: Re: 2005-1 or its logical successor) Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB49227CA@CL-S-EX-1.stanleyassociates.com> > > If they charge lots of settlement, perhaps people won't send packets > > their way? or will degrade performance intentionally? Or force that > > traffic through a competitor to impale them on a higher cost link :( > > Since all IX members would be advertising the same aggregate to their > upstreams, Is that enforceable? > inbound traffic necessarily flows to the member closest to the > source. Assuming everyone hot-potatos. For certain values of "closest," which may vary depending on local routing policy. > All one can do is _prevent_ traffic from reaching you by not > advertising, prepending, etc. but why would they do that when > they stand to > make money for every bit of yours that comes in and avoid > paying you for > every bit of theirs they get directly? I'm having pronoun trouble. "You" is a web hoster/content provider? "They" and "one" are an ISP? "Closest" may not equal "cheapest." Even if there's a flat settlement rate tarriffed by the FCC (or whatnot), circuit or equipment costs may vary. > > it takes the most direct route assuming no funny monkey > business with > > routing... assuming people don't have capacity problems in > region (or > > at the IX) and don't force traffic on non-optimal paths. > > Assuming the settlement rate is comparable to or higher than > the current > transit rate (something nobody has addressed so far), everyone has a > financial incentive to build as much inbound capacity and > attract as much > inbound traffic as possible. Okay. . . then it's the carriers who get shafted, because most of their traffic is outbound. And they pass the savings on to you, the consumer. Even if the financial incentives are properly formed, as Chris points out, people may act contrary to their short-term interest for the benefit of long-term interest. > > I am not sure that local/regional IXP proliferation is going to help > > the DFZ folks all that much in the end. It may remove direct > > connections and direct allocations from their tables. It would > > essentially aggregate all customers in region behind one prefix. > > Eventually the 'regional' IXP would have to become a County > IXP then a > > City IXP then Town IXP, proliferating the number of IXP's to a very > > large number (how many towns exist in the USA alone? Does > this really > > drop the DFZ table that much? > > There are ~3000 counties in the US; while all of them > certainly don't need > their own IX, even if we did something that nutty 3000 routes > for the US is > a clear improvement over the status quo. If we restricted > "areas" to, say, > the so-called NFL cities or something similar, we'd have > another two orders > of magnitude reduction in routes. Agreed, that's the potential benefit, if it works. Is it possible to achieve some of this benefit with only partial deployment? In other words, if we manage to get a policy out of this, and IXen start sprouting like grass, ARIN has only created opportunity--would there be voluntary adoption, and if so, would partial adoption be good? > The way I've seen it described, there's nothing preventing > any ISP from > selling transit to any other or to end sites; the only thing > is that to use > the IX-based addresses in a given area, they'd need to peer > at the IX (and > join the settlement scheme). > > So, your promising local ISP could join the IX, sell a customer a > connection, I'm confused again. "Connection" meaning "BGP neighborship including full table (transit)" or meaning "circuit with transit." ? > buy transit from UUNET et al, and nothing much > would change > except that (a) your customer could multihome (or rehome) to > any other IX > member without any new routes in the DFZ, (b) you would get > settlement check > for traffic coming in on your transit pipes headed for other > IX members, and > (c) you'd send settlement checks for traffic coming in on > other IX members' > transit pipes headed for your customers. "Nothing much" where the value of nothing is sufficiently high. > S > > Stephen Sprunk "Stupid people surround themselves with smart > CCIE #3723 people. Smart people surround themselves with > K5SSS smart people who disagree with them." --Aaron Sorkin Lee From Michael.Dillon at btradianz.com Fri Nov 11 03:02:47 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 11 Nov 2005 08:02:47 +0000 Subject: [ppml] geo addressing In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB4922791@CL-S-EX-1.stanleyassociates.com> Message-ID: > Would you propose allocating /x to regional IXen? > Of a certain size, or serving a certain (defined how?) > region? In addition to or lieu of existing policy? > IPv4 and/or/xor IPv6? Reserve, not allocate. Someone still has to do the tough work of analyzing world populations and the limits to growth in order to come up with some measure of how much networking activity to expect in each part of the world. This analysis is needed to determine how big /x is for each city and how to aggregate cities into larger sub-continental aggregates. The addresses are then reserved in the same way that ARIN reserves neighboring blocks when they allocate a block to an ISP. At that point we will know exactly which /x belongs to each city. But that doesn't mean that we allocate the addresses to exchanges in the city. The allocation may well go to ISPs based on their network infrastructure in and around a particular city. But in some cities, there will likely be a consortium of ISPs and exvchanges who will administer the allocations in the same way that APNIC NIRs administer allocations in some countries. All of this is IPv6 because that is where th big block of unspecified address space exists. It does mean that in geotopological addressing we come back to the idea of allocating to ISPs only as many addresses as they can justify. No /32s. However, the /48 and /64 rules continue to apply because end-user networks are still the same. --Michael Dillon From bmanning at vacation.karoshi.com Fri Nov 11 12:02:08 2005 From: bmanning at vacation.karoshi.com (bmanning at vacation.karoshi.com) Date: Fri, 11 Nov 2005 17:02:08 +0000 Subject: [ppml] geo addressing In-Reply-To: References: <369EB04A0951824ABE7D8BAC67AF9BB4922791@CL-S-EX-1.stanleyassociates.com> Message-ID: <20051111170208.GA6969@vacation.karoshi.com.> On Fri, Nov 11, 2005 at 08:02:47AM +0000, Michael.Dillon at btradianz.com wrote: > > Would you propose allocating /x to regional IXen? > > Of a certain size, or serving a certain (defined how?) > > region? In addition to or lieu of existing policy? > > IPv4 and/or/xor IPv6? > > Reserve, not allocate. Someone still has to do the tough > work of analyzing world populations and the limits to growth > in order to come up with some measure of how much networking > activity to expect in each part of the world. This analysis > is needed to determine how big /x is for each city and how > to aggregate cities into larger sub-continental aggregates. someone, anyone... stop me NOW... (ok, i am making a presumption or two here, but i expect i am not alone) .. couching this as a question... Michael, why do you think that "world population" is even remotely associated w/ address utilization? or, in other words, What is your IP address? (not the address(s) used in your computing/communication devices). unless/until we get the routing locator/endpoint id split, the IP address is both how to get somewhere AND the target/source of bit streams. Not people. Devices. So unless your "world populations" and "limits to growth" are applied to devices, i can't really buy into your arguments ... except as an intellectual exercise and -perhaps- worthy of a limited operational trial. If only to empericially test the viability of this approach. --bill > --Michael Dillon > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml From Lee.Howard at stanleyassociates.com Fri Nov 11 13:32:19 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 11 Nov 2005 13:32:19 -0500 Subject: [ppml] geo addressing Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB49229CE@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michael.Dillon at btradianz.com > Sent: Friday, November 11, 2005 3:03 AM > To: ppml at arin.net > Subject: Re: [ppml] geo addressing > > > Would you propose allocating /x to regional IXen? > > Of a certain size, or serving a certain (defined how?) > > region? In addition to or lieu of existing policy? > > IPv4 and/or/xor IPv6? > > Reserve, not allocate. Someone still has to do the tough > work of analyzing world populations and the limits to growth > in order to come up with some measure of how much networking > activity to expect in each part of the world. This analysis > is needed to determine how big /x is for each city and how > to aggregate cities into larger sub-continental aggregates. Interesting. > The addresses are then reserved in the same way that ARIN > reserves neighboring blocks when they allocate a block to > an ISP. At that point we will know exactly which /x belongs > to each city. But that doesn't mean that we allocate the > addresses to exchanges in the city. The allocation may well > go to ISPs based on their network infrastructure in and around > a particular city. But in some cities, there will likely > be a consortium of ISPs and exvchanges who will administer > the allocations in the same way that APNIC NIRs administer > allocations in some countries. Okay, pretty clear answers. Do I have it right that ARIN would reserve, say, a /32 for NY, with a dotted line around a map, then any ISP who applied for address space would get an allocation from that /32? ISPs would have to apply for separate blocks in each gerrymander; local ISPs and IXen would have portable blocks from their local /32? > All of this is IPv6 because that is where th big block of > unspecified address space exists. It does mean that in > geotopological addressing we come back to the idea of > allocating to ISPs only as many addresses as they can > justify. No /32s. However, the /48 and /64 rules continue > to apply because end-user networks are still the same. Justify = 6-month projected host count? 10 year? > > --Michael Dillon Lee From memsvcs at arin.net Fri Nov 11 16:35:46 2005 From: memsvcs at arin.net (Member Services) Date: Fri, 11 Nov 2005 16:35:46 -0500 Subject: [ppml] ARIN XVI Meeting Archives Now Available Message-ID: <43750EB2.90404@arin.net> The ARIN community recently concluded the ARIN XVI Public Policy and Members Meetings, held in Los Angeles, California, October 26-28, 2005. The presentations, webcast archives, and minutes of these meetings are now available on the ARIN website at: http://www.arin.net/meetings/minutes/ARIN_XVI/ In addition to these files, the page referenced above has links to presentations for the Sunday "Getting Started with IPv6" workshop, and Tuesday's tutorials. We thank all in the community who participated either in person or remotely, and look forward to seeing you all again for ARIN XVII in Montreal, Quebec, Canada, April 9-12, 2006. Regards, Member Services American Registry for Internet Numbers (ARIN) From Michael.Dillon at btradianz.com Mon Nov 14 05:17:24 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 14 Nov 2005 10:17:24 +0000 Subject: [ppml] geo addressing In-Reply-To: <20051111170208.GA6969@vacation.karoshi.com.> Message-ID: > > Reserve, not allocate. Someone still has to do the tough > > work of analyzing world populations and the limits to growth > > in order to come up with some measure of how much networking > > activity to expect in each part of the world. This analysis > > is needed to determine how big /x is for each city and how > > to aggregate cities into larger sub-continental aggregates. > Michael, why do you think that "world population" > is even remotely associated w/ address utilization? I don't think that. I do think that regional population is related to the amount of economic activity (number of transactions) which is related to the amount of communication which is related to the number of devices which is related to the number of IP addresses. In order to do geotopological allocation, one has to make a decision as to how many addresses go to each city. This decision should be based on real economic information regarding the projected population and the limits to growth in the various regions. In some cases, higher populations mean that fewer IPv6 addresses need to be reserved because fewer economic transactions will take place, i.e. people will not be buying iPods, music tracks, and phone conversations. Geographers and economists can provide the science needed to fairly divide IPv6 geo addresses between the 5,000 biggest cities in the world. The existing non-geo IPv6 addresses and the rest of the reserved IPv6 addresses, provide a buffer in case something unpredictable happens, for instance, if the Western half of the USA sinks beneath the ocean and this results in a population surge in Mexico's former deserts and the Sahara, then we are not completely stuck. > of bit streams. Not people. Devices. So unless your "world > populations" and "limits to growth" are applied to devices, > i can't really buy into your arguments ... except as an > intellectual exercise and -perhaps- worthy of a limited operational > trial. If only to empericially test the viability of this > approach. We need to estimate the number of devices on the network in 2050 and at the end of the century. I believe that the information needed to make that estimate for the 5,000 largest population centers in the world, already exists. We need to somehow engage with the geographers and economists who have this information in order to map out a reasonable plan for dividing up a geotopological address space and then launch a trial of this addressing plan in cities where there is already a tradition of local interconnect. But this can't be done by ARIN alone. This really needs support from other RIRs and the NRO. In particular, the NRO is involved with international organizations which have access to the kind of geographical and economic data that we need. --Michael Dillon From Michael.Dillon at btradianz.com Mon Nov 14 05:37:25 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 14 Nov 2005 10:37:25 +0000 Subject: [ppml] geo addressing In-Reply-To: <369EB04A0951824ABE7D8BAC67AF9BB49229CE@CL-S-EX-1.stanleyassociates.com> Message-ID: > Okay, pretty clear answers. Do I have it right that ARIN > would reserve, say, a /32 for NY, with a dotted line around > a map, then any ISP who applied for address space would get > an allocation from that /32? ISPs would have to apply for > separate blocks in each gerrymander; local ISPs and IXen > would have portable blocks from their local /32? More or less. First of all, I would not draw borders around areas on a map. I would allocate addresses to ISPs who will interconnect within the existing boundaries of the city of New York, but I would expect that those ISPs will serve customers in the surrounding area as well as the city itself. In that surrounding area, it will be up to the customers to decide whether they connect to an NYC based ISP or a Syracuse based ISP or a Rochester based ISP. The actual boundaries will be fuzzy. ISPs would be able to ask for a geotopological allocation or a "classic" allocation or some of both. Local ISPs would be able to get portable allocations of any size from their local reservation. Of course, they are only portable within that city. Companies can do the same. Presumably, someday a multihomed company will move their factory Poughkeepsie to Utica and will decide to longline their network connection back to the New York area in order to avoid renumbering into Rochester addresses. That is entirely up to them since the geotopological address allocation is based on the center of interconnection, not the physical location. If the American embassy in Moscow wants to use addresses out of the Washington DC reservation then they can do that as long as they tunnel back to DC to interconnect. I'm not proposing lots and lots of strict rules, just a separate paradigm for addressing, interconnect and peering that focuses on the world's 5,000 largest cities with population of 100,000 or greater. These are the nodes in the Internet because the vast majority of the fiber in place, interconnects these cities. That is the geographical topology that I want to match the addressing to. > > All of this is IPv6 because that is where th big block of > > unspecified address space exists. It does mean that in > > geotopological addressing we come back to the idea of > > allocating to ISPs only as many addresses as they can > > justify. No /32s. However, the /48 and /64 rules continue > > to apply because end-user networks are still the same. > > Justify = 6-month projected host count? 10 year? That is up to policy. But these geo-topological addresses do bring us back to the IPv4 concept of justifying the size of the ISP's allocation. Also, this justification happens in the context of a single local area which means it is much smaller than the "classic" IPv6 address space and it is limited. Therefore, I think 10 years is way too much. A 6-month projection is reasonable as a minimum but I would prefer to see 12 months. This forces companies to make an annual review of their situation which is reasonable because it ties in with budgetting cycles. I think that along with the one year projection justifying the allocation, it would be good to see a 3 year projection as well. I would also expect that the current algorithm used for carving up the IPv4 space would be good to use in each geo-topological area. --Michael Dillon From michel at arneill-py.sacramento.ca.us Mon Nov 14 10:19:46 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 14 Nov 2005 07:19:46 -0800 Subject: [ppml] geo addressing Message-ID: Beating a dead horse: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt Michel From terry.l.davis at boeing.com Mon Nov 14 11:27:24 2005 From: terry.l.davis at boeing.com (Davis, Terry L) Date: Mon, 14 Nov 2005 08:27:24 -0800 Subject: [ppml] geo addressing Message-ID: <0D090F1E0F5536449C7E6527AFFA280A621BF4@XCH-NW-8V1.nw.nos.boeing.com> Michael I certainly can't say I like the concept you present. If you want to achieve the same thing, try reading Tony Hain's IETF draft on embedding the GPS location in the address. With this concept, if you had the Internet core routers addressed in this manner, you could develop cut-through routing that could very much mimic circuit switching. That would significantly shrink the routing tables and would not impose the stringent rules you propose. Take care Terry -----Original Message----- From: Michael.Dillon at btradianz.com [mailto:Michael.Dillon at btradianz.com] Sent: Monday, November 14, 2005 2:37 AM To: ppml at arin.net Subject: Re: [ppml] geo addressing > Okay, pretty clear answers. Do I have it right that ARIN > would reserve, say, a /32 for NY, with a dotted line around > a map, then any ISP who applied for address space would get > an allocation from that /32? ISPs would have to apply for > separate blocks in each gerrymander; local ISPs and IXen > would have portable blocks from their local /32? More or less. First of all, I would not draw borders around areas on a map. I would allocate addresses to ISPs who will interconnect within the existing boundaries of the city of New York, but I would expect that those ISPs will serve customers in the surrounding area as well as the city itself. In that surrounding area, it will be up to the customers to decide whether they connect to an NYC based ISP or a Syracuse based ISP or a Rochester based ISP. The actual boundaries will be fuzzy. ISPs would be able to ask for a geotopological allocation or a "classic" allocation or some of both. Local ISPs would be able to get portable allocations of any size from their local reservation. Of course, they are only portable within that city. Companies can do the same. Presumably, someday a multihomed company will move their factory Poughkeepsie to Utica and will decide to longline their network connection back to the New York area in order to avoid renumbering into Rochester addresses. That is entirely up to them since the geotopological address allocation is based on the center of interconnection, not the physical location. If the American embassy in Moscow wants to use addresses out of the Washington DC reservation then they can do that as long as they tunnel back to DC to interconnect. I'm not proposing lots and lots of strict rules, just a separate paradigm for addressing, interconnect and peering that focuses on the world's 5,000 largest cities with population of 100,000 or greater. These are the nodes in the Internet because the vast majority of the fiber in place, interconnects these cities. That is the geographical topology that I want to match the addressing to. > > All of this is IPv6 because that is where th big block of > > unspecified address space exists. It does mean that in > > geotopological addressing we come back to the idea of > > allocating to ISPs only as many addresses as they can > > justify. No /32s. However, the /48 and /64 rules continue > > to apply because end-user networks are still the same. > > Justify = 6-month projected host count? 10 year? That is up to policy. But these geo-topological addresses do bring us back to the IPv4 concept of justifying the size of the ISP's allocation. Also, this justification happens in the context of a single local area which means it is much smaller than the "classic" IPv6 address space and it is limited. Therefore, I think 10 years is way too much. A 6-month projection is reasonable as a minimum but I would prefer to see 12 months. This forces companies to make an annual review of their situation which is reasonable because it ties in with budgetting cycles. I think that along with the one year projection justifying the allocation, it would be good to see a 3 year projection as well. I would also expect that the current algorithm used for carving up the IPv4 space would be good to use in each geo-topological area. --Michael Dillon _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From michel at arneill-py.sacramento.ca.us Mon Nov 14 11:35:55 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 14 Nov 2005 08:35:55 -0800 Subject: [ppml] geo addressing Message-ID: > Davis, Terry L wrote: > try reading Tony Hain's IETF draft on embedding > the GPS location in the address. Terry, Tony and I have met several times discussing it a while ago. If you go here under the "geographical data" you'll find Tony's stuff next to mine. This is ancient history. http://arneill-py.sacramento.ca.us/ipv6mh/ Both mechanisms have similar annoyances; as of today we don't have a routing infrastructure and/or the necessary protocols to make geo addressing work. Sorry to rain on the parade but this is flogging a dead horse; we have explored these ideas years ago with no success. Michel. From Michael.Dillon at btradianz.com Tue Nov 15 05:20:54 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 15 Nov 2005 10:20:54 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > as of today we don't have a > routing infrastructure and/or the necessary protocols to make geo > addressing work. Sorry to rain on the parade but this is flogging a dead > horse; we have explored these ideas years ago with no success. I disagree on several points. First of all, geotopological addressing is not the same thing as was discussed in the past. We do have the necessary protocols to make geo-topological addressing work because it uses all the same protocols that we have today without any protocol changes. It even does multihoming in exactly the same way using BGP and it aggregates prefixes in the same way that ISPs do so today. Geotopological addressing only requires the RIRs to set aside one of the remaining 7 regions of IPv6 space for geo-topological addressing and to start handing out allocations consistent with the geotopology. This geotopology is based partly on geography but still considers topology to be important. The highest level cut is made based on continents just like the RIRs today. This is geography and it is also topology because intercontinental traffic is expensive and must transit limited intercontinental fibers. At the lowest level, we have the city, which has a population of 100,000 or greater. The city serves as an economic and communications hub for its surrounding area which often spans national borders. Then, in between these two is a middle layer of aggregation for a cluster of cities which tend to communicate more with each other than with other cities on the same continent. In some areas this will be easy to determine, for example Australia, New Zealand, and Papua/New Guinea would make a logical cluster in the APNIC region. But in some other regions, such as ARIN's region it is less clear. That's OK because this mid level of aggregation is not about borders, it is about where we can cluster some cities in order to aggregate their routing detail under a covering prefix. It might mean that people in Denver and Salt-Lake City send all their Detroit traffic to Chicago because Detroit and Chicago are hidden inside the same covering prefix. This is not a bad thing in general. But remember, there are no rules about how this is done. If your company has networks in all those cities, and you have circuits direct from Denver to Detroit, then you are free to keep as much unaggregated detail as you want in your routing tables. This doesn't solve the IPv6 multihoming problem in general. It specifically addresses the long tail multihoming problem. This is the large number of small ISPs and small to mid-size companies for whom the Internet is mission critical and who want to multihome in order to enhance their network resiliency. And geotopological addressing is entirely optional. It only impacts the people who want to use it. --Michael Dillon From memsvcs at arin.net Tue Nov 15 09:12:20 2005 From: memsvcs at arin.net (Member Services) Date: Tue, 15 Nov 2005 09:12:20 -0500 Subject: [ppml] Maintenance Work on Saturday, November 19 Message-ID: <4379ECC4.10103@arin.net> On Saturday, November 19, 2005, ARIN will perform hardware maintenance. This work is scheduled from 8 AM until 1 PM Eastern time. During this time, the automated mail responder for our role accounts and the processing of credit card payments will be unavailable. All other services will not be affected. Role mail will queue during this maintenance window. Auto response messages will start being sent once all systems are back online. Please do not re-send your mail if you do not receive a ticket number right away. We apologize for any inconvenience this may cause to our members and all in the Internet community. Regards, Ginny Listman Director of Engineering American Registry for Internet Numbers From rich at nic.umass.edu Wed Nov 16 13:31:52 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Wed, 16 Nov 2005 13:31:52 -0500 (EST) Subject: [ppml] geo addressing Message-ID: The horse has left the morticians for the glue factory. Anyone looked at any traceroutes lately? I've gone from Boston to Boston via Chicago and actually improved performance once with a congestion sensitive application by forcing a reroute via Los Angeles. That's a function of where the fiber got laid, and the path purchased not where the people are. This won't change due to addressing. Anyone tunneled or multihomed lately? Certainly possible for an org to announce the same prefix in two cities far apart. I know one org that does it 90 miles apart, which is probably trivial in terms of distance, but a model proposing different supernets for 2 areas would require NAT or fail (but I repeat myself.) These are regional examples, but some proposals were down the city-regional level, and would have broken here. Anyone remember LATA's? Toll bypass? Various new telco products and VoIP offerings have made area codes and even exchanges less reliable as a geolocation tool. (201 was NYC, 202 LA; if the system was geo hierarchical, the east might have been 2 and the west 9 with others in the middle. It's a non-hierarchical system which happened to correlation geographically. Compare the US Postal code system, which has hierarchy @ 3, 5 and 9 digits, and like the early area code system, run by one org with an iron fist for their internal use.) Looking at IP in IP (MPLS, VPNs etc) and private fiber (Google today, someone else tomorrow), suggest that things are growing in way counter to geographic organization. Addresses could legitimately pop up all over the place, not unlike cell phone numbers, which require a database to track that. But your cell phone's serial number doesn't change when you fly from NYC to LA. An IP address is just an address and nothing more. Let Dobbin rest in peace.... From Michael.Dillon at btradianz.com Thu Nov 17 04:59:08 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Thu, 17 Nov 2005 09:59:08 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > Anyone looked at any traceroutes lately? I've gone from Boston to Boston > via Chicago and actually improved performance once with a congestion > sensitive application by forcing a reroute via Los Angeles. That's a > function of where the fiber got laid, and the path purchased not where the > people are. This won't change due to addressing. Geotopological addressing is not a traffic engineering tool. It does not pretend to solve all corner cases in Internet operations or architecture. What it does do is allow a much larger number of organizations to multihome in their city without consuming slots in the global routing table. Therefore it helps you reroute traffic via Chicago and LA because there will be more space in the global routing table for those more-specifics. > Anyone remember LATA's? Toll bypass? Various new telco products and VoIP > offerings have made area codes and even exchanges less reliable as a > geolocation tool. Geotopological addressing is not a geolocation tool. > (201 was NYC, 202 LA; if the system was geo hierarchical, > the east might have been 2 and the west 9 with others in the middle. This was done on purpose. The feeling was that people would make less dialling mistakes if the similar area codes were far apart geographically. > An IP address is just an address and nothing more. That has not been true since people began filtering on different prefix lengths in different address ranges. Around the time CIDR was invented. Geotopological addressing is not proposed as a replacement for the classic IPv6 address allocation plan. It is proposed as an additional addressing plan with different rules which runs alongside the classic plan and offers organizations a choice. In effect, it brings market principles to bear in RIR policy by making classic addressing compete with geotopological addressing. --Michael Dillon From rich at nic.umass.edu Thu Nov 17 15:09:36 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Thu, 17 Nov 2005 15:09:36 -0500 (EST) Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: On Thu, 17 Nov 2005, Michael.Dillon at btradianz.com wrote: > Geotopological addressing is not a traffic engineering tool. > It does not pretend to solve all corner cases in Internet > operations or architecture. What it does do is allow a much > larger number of organizations to multihome in their > city without consuming slots in the global routing table. > Therefore it helps you reroute traffic via Chicago and LA > because there will be more space in the global routing table > for those more-specifics. Based on past events, same city homing doesn't strike me as scaleable anymore, in even moderate availablity environments. Geographic diversification of the infrastructure seems more the trend, so one event (nature, man, etc) doesn't effect all. So, say I'm homed in Boston and NYC. Which address space do I announce, the Boston space in NYC or the NYC space in Boston, or my direct assignments which are neither? > [REF AREA CODES] > This was done on purpose. The feeling was that people would make > less dialling mistakes if the similar area codes were far apart > geographically. Story I had, back when dialing was done with pulses, is the areas with the most customers (LA, NYC, Chicago) got the codes with a low number of clicks (212, 213, 312) and least (Alaska, Hawaii ) got more clicks, i.e. 907, 808. The longer it takes to connect, the longer you tie up the operator board, so there was an interest in reducing that by AT&T. (one ref: http://www.lincmad.com/table1947.html) >> An IP address is just an address and nothing more. > > That has not been true since people began filtering on different > prefix lengths in different address ranges. Around the time CIDR > was invented. No, it's still an address. A CIDR block is a notation for a group of addresses related to routing traffic in a particular fashion. I could group addresses together in a different way, for example, load balancing selection using bits from the last byte of the address. > Geotopological addressing is not proposed as a replacement for > the classic IPv6 address allocation plan. It is proposed as an > additional addressing plan with different rules which runs > alongside the classic plan and offers organizations a choice. > In effect, it brings market principles to bear in RIR policy > by making classic addressing compete with geotopological addressing. I'm not sold on why is this needed, and question if it represents something that will move IPv6 implementation forward. From Michael.Dillon at btradianz.com Fri Nov 18 05:14:20 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Fri, 18 Nov 2005 10:14:20 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > Based on past events, same city homing doesn't strike me as scaleable > anymore, in even moderate availablity environments. Geographic > diversification of the infrastructure seems more the trend, so one event > (nature, man, etc) doesn't effect all. So, say I'm homed in Boston and NYC. > Which address space do I announce, the Boston space in NYC or the NYC space > in Boston, or my direct assignments which are neither? In the absence of any research studies on the needs of mid-sized companies, I would say that if you have determined that you need diverse connections to two cities you would be foolish to acquire geotopological IP addresses. Instead you should get a classic IPv6 allocation and announce it in both cities. However, one thing that researchers could find out is how common it is to build such diversity between city pairs and what city pairs people are likely to use. In that case a 3 tier geotopological addressing system that aggregates at the regional level as well as the city and continent levels, could allocate small virtual cities within a regional aggregate that represent these city pairs. Then you would get addresses from the virtual city. But this only makes sense if it simplifies something and it is only likely to be simpler in a few cases where there is a LOT of multi-city diversity being demanded. If, for whatever reason, you decided to use geotopological addresses anyway and announce the foreign addresses in Boston and NY, then this would only have local impact in the routing tables. Montreal would send traffic for your NY addresses to New York. If your New York circuit was down, presumably you would be redirecting that traffic to Boston. > I'm not sold on why is this needed, and question if it represents > something that will move IPv6 implementation forward. It is not intended to move IPv6 implementation forward. The assumption is that IPv6 will be implemented and that pressure on the routing table will increase as more and more small and mid-size companies demand BGP multihoming as part of their network diversity. Geotopological addressing can reduce this routing table pressure without any new protocols or any new technology. Geotopological addressing is an administrative solution to the problem that gives competing businesses more options and fewer constraints in how they operate IP networks. --Michael Dillon From paul at vix.com Fri Nov 18 10:01:28 2005 From: paul at vix.com (Paul Vixie) Date: Fri, 18 Nov 2005 15:01:28 +0000 Subject: [ppml] geo addressing In-Reply-To: Your message of "Fri, 18 Nov 2005 10:14:20 GMT." References: Message-ID: <20051118150128.1162411426@sa.vix.com> michael, there's a disconnect here. i'm a big fan of metro-government sponsored L1/L2, like what's been done in palo alto and stockholm and to some degree philadelphia. cost per moved bit on the internet should be cheaper if i can drive or walk to my destination than if it would take an airplane owned by fedex to get it there for me. and i do think that a city who compels, through its permit or licensing process, carriers to interconnect inside the city limits so that traffic between residents never has to leave the city, will be more competitive. and under such a regime, the city would very likely have its own address space, which would be available to residents (businesses and people) on the same basis that street/road addresses are available. the presumption here is that if you want to reach someone who's in the same city, and you're both connected to city ethernet, then either you can ARP for them (if you're in the same broadcast domain) or you can follow your city-default (sort of like your city sewer connection) and reach them through the city's internal IGP. in that sense, geo addressing can work. but in the sense of trying to drive this from the RIR side, it just can't. without the local government mandating local interconnects, then no IXP could do this, and no RIR could make any sensible or relevant policy covering this. the closest an RIR could come is creating a membership class for city governments, teaching city governments how to do this kind of thing, writing white papers about how it can be done and why it's good. From michel at arneill-py.sacramento.ca.us Fri Nov 18 11:39:35 2005 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Fri, 18 Nov 2005 08:39:35 -0800 Subject: [ppml] geo addressing Message-ID: Michael, > Michael.Dillon at btradianz.com wrote: >[ppml] geo addressing Disclaimer: please understand that I'm not trying to rain on your parade and read the following as friendly feedback from someone who's been on that road before. We have been working on geo addressing for IPv6 since 1995. That's over 10 years. http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf Look who wrote it, too. Since then, lots of people including myself have worked on it, with sometimes significant amounts of research such as having a database of all the cities in the world: http://arneill-py.sacramento.ca.us/ipv6mh/geov6.txt And other nice methods by many other persons. Out of these people, many were bright, hard-working, politically well-connected in the IPv6 IETF and other communities, and had large vendor resources behind them. You're flogging a dead horse. The last round of discussions I remember being involved in, we approached the issue not as "why geo addressing" but as "why not geo addressing". The main argument was: even if we don't aggregate geo addresses, they are not worse than randomly assign prefixes, so why not go to geo addresses and figure out later if we can aggregate them. If we can, good; if we can't, oh well nice try no cigar and we're not worse off than if we had flat space anyway. Trouble is: it does not fly for two reasons: 1. Politics: any geo addressing scheme involves tons of political horseshit. 2. Uncertainty: place yourself in the position of a network administrator of a growing company; why risk going to geo addresses not knowing if the aggregation mechanism will fit your needs? Way too risky. Michel. From marla_azinger at eli.net Fri Nov 18 12:02:52 2005 From: marla_azinger at eli.net (Azinger, Marla) Date: Fri, 18 Nov 2005 09:02:52 -0800 Subject: [ppml] geo addressing Message-ID: <10ECB7F03C568F48B9213EF9E7F790D202100C4E@wava00s2ke2k01.corp.pvt> Paul- Thank you for your input and information. I've been following this string of emails and I have seen alot of valid points. What I appreciate about your response is how it really gets to the point of "how this applies practically" in our world today and what we can do for it in the future. Thank you Marla Azinger ELI -----Original Message----- From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net]On Behalf Of Paul Vixie Sent: Friday, November 18, 2005 7:01 AM To: Michael.Dillon at btradianz.com Cc: ppml at arin.net Subject: Re: [ppml] geo addressing michael, there's a disconnect here. i'm a big fan of metro-government sponsored L1/L2, like what's been done in palo alto and stockholm and to some degree philadelphia. cost per moved bit on the internet should be cheaper if i can drive or walk to my destination than if it would take an airplane owned by fedex to get it there for me. and i do think that a city who compels, through its permit or licensing process, carriers to interconnect inside the city limits so that traffic between residents never has to leave the city, will be more competitive. and under such a regime, the city would very likely have its own address space, which would be available to residents (businesses and people) on the same basis that street/road addresses are available. the presumption here is that if you want to reach someone who's in the same city, and you're both connected to city ethernet, then either you can ARP for them (if you're in the same broadcast domain) or you can follow your city-default (sort of like your city sewer connection) and reach them through the city's internal IGP. in that sense, geo addressing can work. but in the sense of trying to drive this from the RIR side, it just can't. without the local government mandating local interconnects, then no IXP could do this, and no RIR could make any sensible or relevant policy covering this. the closest an RIR could come is creating a membership class for city governments, teaching city governments how to do this kind of thing, writing white papers about how it can be done and why it's good. _______________________________________________ PPML mailing list PPML at arin.net http://lists.arin.net/mailman/listinfo/ppml From Lee.Howard at stanleyassociates.com Fri Nov 18 14:46:44 2005 From: Lee.Howard at stanleyassociates.com (Howard, W. Lee) Date: Fri, 18 Nov 2005 14:46:44 -0500 Subject: [ppml] geo addressing Message-ID: <369EB04A0951824ABE7D8BAC67AF9BB44434E3@CL-S-EX-1.stanleyassociates.com> > -----Original Message----- > From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On > Behalf Of Michel Py > Sent: Friday, November 18, 2005 11:40 AM > To: Michael.Dillon at btradianz.com; ppml at arin.net > Subject: Re: [ppml] geo addressing > > Out of these people, many were bright, hard-working, politically > well-connected in the IPv6 IETF and other communities, and had large > vendor resources behind them. IETF != ARIN Looks to me like this is getting a reasonable hearing. I don't mean to suggest that there's consensus, but your argument that "Nobody listened when I suggested this a long time ago in a galaxy far, far away," does not indicate that it's not worth hearing now. PPML is an excellent place to develop a policy proposal. > The main argument was: even if we don't aggregate geo > addresses, they are not worse than randomly assign prefixes, > so why not > go to geo addresses and figure out later if we can aggregate > them. If we > can, good; if we can't, oh well nice try no cigar and we're not worse > off than if we had flat space anyway. If one could demonstrate a high probability of aggregation, that would help. > Trouble is: it does not fly for two reasons: > 1. Politics: any geo addressing scheme involves tons of political > horseshit. > 2. Uncertainty: place yourself in the position of a network > administrator of a growing company; why risk going to geo > addresses not > knowing if the aggregation mechanism will fit your needs? Way > too risky. There's a window between getting an ISP assignment and an ARIN assignment (/29 to /21). Within that window, I-as-network-admin would rather have geoical provider-independent space than provider-aggregatable space. Well, not me personally, since my network is NATed behind a /28, but I could imagine people thinking that if they have to renumber at /21 anyway, at least regional PI addresses would keep them from having to renumber in the meantime. Lee > > Michel. > > _______________________________________________ > PPML mailing list > PPML at arin.net > http://lists.arin.net/mailman/listinfo/ppml > From Michael.Dillon at btradianz.com Mon Nov 21 04:49:00 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 21 Nov 2005 09:49:00 +0000 Subject: [ppml] geo addressing In-Reply-To: <20051118150128.1162411426@sa.vix.com> Message-ID: > and i do think that a city who compels, through its permit or licensing > process, carriers to interconnect inside the city limits so that traffic > between residents never has to leave the city, will be more competitive. I would like to see a policy that enables this but does not require this. It is a political decision whether or not to mandate action, and I think that addressing schemes should avoid meddling in national, and local politics. > and under such a regime, the city would very likely have its own address > space, which would be available to residents (businesses and people) on > the same basis that street/road addresses are available. Ideally, a geotopological addressing policy would not prevent a city from doing this in countries in which the citizens want this to be done. > but in the sense of trying to drive this from the RIR side, it just can't. > > without the local government mandating local interconnects, then no IXP > could do this, and no RIR could make any sensible or relevant policy > covering this. the closest an RIR could come is creating a membership > class for city governments, teaching city governments how to do this kind > of thing, writing white papers about how it can be done and why it's good. As I said before, I don't think that it is necessary to mandate local interconnects. Geotopological addressing is in addition to classic IPv6 addressing. In areas where the IXPs and network operators cannot organize themselves to interconnect voluntarily or where the governments don't mandate interconnection, it is still possible to use classic addresses and achieve Internet access in a less optimal way. RIRs can only deal with addressing policies and with education. So it is feasible for the RIRs to create and administer geotopological addresses and it is feasible for them to run education programs that explain the optimal configuration for the use of geotopological addresses which does involve rich local interconnections in or near each city that is a center of aggregation. --Michael Dillon From Michael.Dillon at btradianz.com Mon Nov 21 05:05:59 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Mon, 21 Nov 2005 10:05:59 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > We have been working on geo addressing for IPv6 since 1995. That's over > 10 years. > http://arneill-py.sacramento.ca.us/ipv6mh/metro-addr-slides-jul95.pdf > Look who wrote it, too. I am not a hero worshipper so the author of these slides does not impress me. However, I was aware of this work and it is the source of my ideas on geotopological addressing. On the other hand, what I am proposing is rather different. I do not propose this as THE model for IPv6 addressing. I do not propose any changes to the IPv6 protocol including the interpretation of bits in the header. I do not propose any changes to routing protocols. I do not propose any political involvement by either countries or the Internet Society or by some new organization. I'm simply extrapolating the known and tested ability of IPv4 network operators to aggregate more specifics at the edge of their network. We know that it is feasible for a network operator to listen to two adjacent /24 announcements from his "downstreams" and announce a single aggregated /23 to his "upstreams". If we could allocate addresses to more closely correspond to network topology, then we could do more aggregation and the global routing table would see less routes. The network topology of today now roughly matches the topology of transportation systems and economic flows. In other words the nodes in the network are cities or metropolitan areas. Geotopological addressing is a change to the way that IPv6 addresses are administered and allocated. There is no requirement for any changes other than RIR policies and practices. Of course, to gain the optimum benefit, network operators must interconnect more widely in metro areas and adjust peering policies to cover the cold potato routing that will happen. But these things are outside the remit of ARIN and other RIRs. Like BGP filtering, we can only hope that sane engineering practices will prevail and that network operators will adapt to RIR activities. In the past when the minimum size of an allocation was changed we did observe that network operators changed their BGP filters to match. Therefore I don't want to mandate what ISPs do. > Since then, lots of people including myself have worked on it, with > Out of these people, many were bright, hard-working, politically > well-connected in the IPv6 IETF and other communities, and had large > vendor resources behind them. > > You're flogging a dead horse. Leonardo da Vinci, a brilliant and well-connected engineer, made plans for a flying machine. Many years later after many other people flogged that dead horse, a pair of dumb bicycle mechanics named Orville and Wylbur managed to build such a machine. Dead horse, indeed! > Trouble is: it does not fly for two reasons: > 1. Politics: any geo addressing scheme involves tons of political > horseshit. This is a political mailing list. RIR policy is inherently a political activity. If you aren't interested then you can feel free to ignore us and we will continue without you. > 2. Uncertainty: place yourself in the position of a network > administrator of a growing company; why risk going to geo addresses not > knowing if the aggregation mechanism will fit your needs? Way too risky. The aggregation mechanism is simple and well-known already. By "network administrator" I assume you mean the technical people who are on the buying committee making decisions about buying a particular Internet access service. As far as I am concerned it is up to the network operator to convince these people. --Michael Dillon From paul at vix.com Mon Nov 21 14:19:46 2005 From: paul at vix.com (Paul Vixie) Date: Mon, 21 Nov 2005 19:19:46 +0000 Subject: [ppml] geo addressing In-Reply-To: Your message of "Mon, 21 Nov 2005 10:05:59 GMT." References: Message-ID: <20051121191946.CCA1711425@sa.vix.com> # If we could allocate addresses to more closely correspond # to network topology, then we could do more aggregation and # the global routing table would see less routes. ... you never answered my earlier question, so i'll ask it again: what makes you think network topology is static enough that this temporary optimization won't cost more in the long term than it buys in the short term? # The network topology of today now roughly matches the topology # of transportation systems and economic flows. In other words # the nodes in the network are cities or metropolitan areas. ok, so restating my question so we can both be sure i asked it: what relationship does the network topology of today have to the network topology of tomorrow, and why, and how do you know? From tony.li at tony.li Mon Nov 21 23:51:25 2005 From: tony.li at tony.li (Tony Li) Date: Mon, 21 Nov 2005 20:51:25 -0800 Subject: [ppml] geo addressing In-Reply-To: <20051121191946.CCA1711425@sa.vix.com> References: <20051121191946.CCA1711425@sa.vix.com> Message-ID: > what relationship does the network topology of today have to the > network topology of tomorrow, and why, and how do you know? Not to take sides in this argument, but one thing that we can observe is the *general* locality of topology. For example, an end site is most likely to use a service provider in its local region rather than buy a transcontinental link for access. Similarly, we can make the generalization that service providers in a given area will, at some point in the volume curve, choose to interconnect locally rather than back-haul significant traffic volumes to a distant interconnect only to have it return. The primary drivers here are the obvious ones: geographic barriers to interconnection result in an economic disincentive to interconnect. We see this in the pricing of submarine bandwidth relative to terrestrial bandwidth. Similarly, simple distance is a disincentive to create long-haul interconnect outside of long-haul networks, resulting in additional locality. Thus, as an example, two ISPs that are connected currently in the SF bay area are likely to remain connected within the bay area as long as it remains in their economic interests to do so. Assuming that both survive as commercial entities and traffic volumes justify the link, there is little incentive for the ISPs to instead sever the link and interconnect in Washington D.C. instead. This locality of topology can be exploited by an appropriately constructed routing architecture, but it requires a slightly different approach than the geographical addressing architectures that have been discussed in the literature so far. Regards, Tony From Michael.Dillon at btradianz.com Tue Nov 22 05:12:32 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Tue, 22 Nov 2005 10:12:32 +0000 Subject: [ppml] geo addressing In-Reply-To: <20051121191946.CCA1711425@sa.vix.com> Message-ID: > what makes you think network topology is static enough that > this temporary optimization won't cost more in the long term > than it buys in the short term? Because I believe that it is unlikely that many new cities will form causing nearby cities to shrink. Therefore the topology of cities and their interconnects will remain roughly as is. Of course the bandwidth of fibre between cities will increase at varying rates, but I don't foresee major shifts in the economy such as the fall of the Roman empire or the conquest of North America. In addition, I have seen no evidence to show that it is common for organizations to move their networks from one city to another. Most of the topology churn happens inside a metro area. The geotopological address model allows for this churn but hides it from the global (and regional) routing system. Past evidence from companies going into bankruptcy, merger, or acquisition, shows that companies tend to integrate New York routers within New York and LA routers within LA. In other words, you do get PoP consolidation and merger of network resources within a city more often than people move those resources to another city. When I am talking about topology, I am not talking about every last detail of every last router and circuit. It fits ISPs with one PoP in a city, ISPs with 5 PoPs in a city and ISPs with no PoPs but some metro ring topology with edge routers scattered in customer buildings. In all cases, there is a city that has circuits running to other cities. At that level, the topology does not change as much. > # The network topology of today now roughly matches the topology > # of transportation systems and economic flows. In other words > # the nodes in the network are cities or metropolitan areas. > > ok, so restating my question so we can both be sure i asked it: > > what relationship does the network topology of today have to the > network topology of tomorrow, and why, and how do you know? Networks serve people. People live in cities. Therefore the network topology of tommorrow *MUST* connect cities together. Inside the city, people and organizations constantly shift and move. Therefore the topology in the city will constantly be changing. This change does not need to be visible to other cities. By selecting cities larger than 100,000 to be centers of aggregation we allow for areas which could see considerable population growth. Such growth tends to add to existing cities rather than create new ones. I do not suggest that city address allocation size should be based on current population. I would like to see it based on future population as determined by economists, statisticians, geographers who understand the limits to growth in order to make realistic projections. And if we get it a little bit wrong this is good. It would be very bad if we solved all the problems of the world for future generations because then they would be bored out of their minds with no real problems to solve for themselves. So I'm not looking for perfection here. --Michael Dillon From tony.li at tony.li Tue Nov 22 13:12:55 2005 From: tony.li at tony.li (Tony Li) Date: Tue, 22 Nov 2005 10:12:55 -0800 Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> > By selecting cities larger than 100,000 to be centers of aggregation > we allow for areas which could see considerable population growth. > Such growth tends to add to existing cities rather than create new > ones. I do not suggest that city address allocation size should be > based on current population. I would like to see it based on future > population as determined by economists, statisticians, geographers > who understand the limits to growth in order to make realistic > projections. It seems like getting this exactly right is not so important. If you overshoot, then you have a prefix that is underpopulated, but you still aggregate everyone in the metro. If you undershoot, you need a second prefix, but you still get ample aggregation from the first prefix. As has been observed before most of the benefits of aggregation come from aggregating the leaves of the addressing tree. Tony From paul at vix.com Tue Nov 22 13:41:28 2005 From: paul at vix.com (Paul Vixie) Date: Tue, 22 Nov 2005 18:41:28 +0000 Subject: [ppml] geo addressing In-Reply-To: Your message of "Tue, 22 Nov 2005 10:12:55 PST." <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> References: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> Message-ID: <20051122184128.39E2311425@sa.vix.com> if the city in question becomes an LIR or ISP, such that cutouts will not happen when address-users move out of the city, then this could make sense. there is no sensible way to do it from the RIR level, however. From tony.li at tony.li Tue Nov 22 13:45:54 2005 From: tony.li at tony.li (Tony Li) Date: Tue, 22 Nov 2005 10:45:54 -0800 Subject: [ppml] geo addressing In-Reply-To: <20051122184128.39E2311425@sa.vix.com> References: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> <20051122184128.39E2311425@sa.vix.com> Message-ID: > if the city in question becomes an LIR or ISP, such that cutouts > will not > happen when address-users move out of the city, then this could > make sense. Paul, Sites that relocate outside of the aggregate have to renumber. There's nothing magical here. Tony From owen at delong.com Tue Nov 22 18:46:23 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2005 15:46:23 -0800 Subject: [ppml] geo addressing In-Reply-To: References: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> <20051122184128.39E2311425@sa.vix.com> Message-ID: What about sites that expand outside the aggregate, want to remain within their own aggregate for administrative purposes, but, also want local connectivity in their various offices around the world? Imagine, for example, that a company in the US, within an ARIN aggregate starts expanding internationally into Asia, Europe, Africa, and Latin America. Imagine that such company feels that their existing /32 is adequate, but, they want to be able to announce it (or a fraction of it) from their sites on each continent directly. The reality is that geo. addressing only works if the world stands still. The world does not stand still, so, geo. addressing trends towards entropy. Owen -- If this message was not signed with gpg key 0FE2AA3D, it's probably a forgery. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From tony.li at tony.li Tue Nov 22 19:02:29 2005 From: tony.li at tony.li (Tony Li) Date: Tue, 22 Nov 2005 16:02:29 -0800 Subject: [ppml] geo addressing In-Reply-To: References: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> <20051122184128.39E2311425@sa.vix.com> Message-ID: <298E4653-1709-4C6D-8339-A5CD2206AA0D@tony.li> On Nov 22, 2005, at 3:46 PM, Owen DeLong wrote: > What about sites that expand outside the aggregate, want to remain > within their own aggregate for administrative purposes, but, also > want local connectivity in their various offices around the world? > > Imagine, for example, that a company in the US, within an ARIN > aggregate starts expanding internationally into Asia, Europe, > Africa, and Latin America. Imagine that such company feels that > their existing /32 is adequate, but, they want to be able to > announce it (or a fraction of it) from their sites on each > continent directly. > > The reality is that geo. addressing only works if the world > stands still. The world does not stand still, so, geo. > addressing trends towards entropy. Owen, What matters is where the individual site is connected. If a multinational has a HQ in one area, then they should get a prefix in that area. If they have an office in another area, then how they should proceed depends entirely on the topological situation. If the remote site is only connected via HQ, then the site should be numbered via the HQ prefix. If the site is only connected locally, then they should be numbered out of the local area. If they are connected via both, then we're gonna have the multihoming argument (again). Yes, a strict geographic address proponent would number them out of the geographic prefix regardless of connectivity. That's perhaps not the only way... Tony From owen at delong.com Tue Nov 22 22:26:53 2005 From: owen at delong.com (Owen DeLong) Date: Tue, 22 Nov 2005 19:26:53 -0800 Subject: [ppml] geo addressing In-Reply-To: <298E4653-1709-4C6D-8339-A5CD2206AA0D@tony.li> References: <802E08CD-4F3D-482C-A448-15E72FD08A92@tony.li> <20051122184128.39E2311425@sa.vix.com> <298E4653-1709-4C6D-8339-A5CD2206AA0D@tony.li> Message-ID: <6F945FDBBDCB9C1AE98A96A2@odpwrbook.local> Point is that organizations will have topological needs that don't will cause geo. addressing to break one way or the other. Eventually, this will cause address migration and entropy. Owen --On November 22, 2005 4:02:29 PM -0800 Tony Li wrote: > > On Nov 22, 2005, at 3:46 PM, Owen DeLong wrote: > >> What about sites that expand outside the aggregate, want to remain >> within their own aggregate for administrative purposes, but, also >> want local connectivity in their various offices around the world? >> >> Imagine, for example, that a company in the US, within an ARIN >> aggregate starts expanding internationally into Asia, Europe, >> Africa, and Latin America. Imagine that such company feels that >> their existing /32 is adequate, but, they want to be able to >> announce it (or a fraction of it) from their sites on each >> continent directly. >> >> The reality is that geo. addressing only works if the world >> stands still. The world does not stand still, so, geo. >> addressing trends towards entropy. > > > Owen, > > What matters is where the individual site is connected. > > If a multinational has a HQ in one area, then they should get a > prefix in that area. If they have an office in another area, then > how they should proceed depends entirely on the topological > situation. > > If the remote site is only connected via HQ, then the site should be > numbered via the HQ prefix. If the site is only connected locally, > then they should be numbered out of the local area. If they are > connected via both, then we're gonna have the multihoming > argument (again). > > Yes, a strict geographic address proponent would number them > out of the geographic prefix regardless of connectivity. That's > perhaps not the only way... > > Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Wed Nov 23 04:47:35 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Nov 2005 09:47:35 +0000 Subject: [ppml] geo addressing In-Reply-To: <20051122184128.39E2311425@sa.vix.com> Message-ID: > if the city in question becomes an LIR or ISP, such that cutouts will not > happen when address-users move out of the city, then this could make sense. > > there is no sensible way to do it from the RIR level, however. Cutouts can be largely prevented by filtering BGP announcements of prefixes outside the city where they belong. This is analogous to the existing prefix filtering. I agree that there is no sensible way to deal with prefix filtering from the RIR level, and yet, most ISPs do filter anyway. Of course the RIRs could recommend filtering and publish an up-to-date feed of all city-level reservations to facilitate filtering. There are any number of things that can be done to support and encourage using geotopological addresses in the way they are intended. Given that the classic IPv6 addresses will still exist I don't really see that there will be much problem because anyone who doesn't fit into the geotopological model will simply not use it in the first place. The one mechanism that is available to the RIRs for mandating activity is the member agreement. It is conceivable that RIRs could structure an agreement to mandate any number of activities and then only give out geotop addresses to city governments who sign an agreement. Those city governments, acting as LIRs would then pass on the requirements in their member contracts. Unfortunately, I don't see that as a feasible structure to work worldwide. In some cultures it would fly. In others it simply would not work and could even run into legal challenges. The things that work in the Internet tend to evolve from the bottom up and tend to be imperfect in many details. --Michael Dillon From Michael.Dillon at btradianz.com Wed Nov 23 04:51:36 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Nov 2005 09:51:36 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > What about sites that expand outside the aggregate, want to remain > within their own aggregate for administrative purposes, but, also > want local connectivity in their various offices around the world? There is always a choice of classical IPv6 or geotop addressing. > Imagine, for example, that a company in the US, within an ARIN > aggregate starts expanding internationally into Asia, Europe, > Africa, and Latin America. Imagine that such company feels that > their existing /32 is adequate, but, they want to be able to > announce it (or a fraction of it) from their sites on each > continent directly. Well, to start with if the company has a /32 then you are talking about classic v6 addressing not geotop addressing. A company that has geotop addresses will only receive an allocation that is sized according to their needs in one metro area. If they want to expand to other metro areas, their allocation will not be big enough. The logical course of action is to apply for allocations in the other metro areas. I can't understand the benefits to a company of having a single prefix as opposed to half a dozen. It's all inside their own network anyway. --Michael Dillon From Michael.Dillon at btradianz.com Wed Nov 23 04:57:48 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Nov 2005 09:57:48 +0000 Subject: [ppml] geo addressing In-Reply-To: <298E4653-1709-4C6D-8339-A5CD2206AA0D@tony.li> Message-ID: > If they are > connected via both, then we're gonna have the multihoming > argument (again). We are also talking about corner cases. No addressing plan will solve everyone's business problems. If they are multihomed via two cities they can renumber into a classic IPv6 allocation. Current ARIN policies also have limitations that force people to do things like renumbering. > Yes, a strict geographic address proponent would number them > out of the geographic prefix regardless of connectivity. That's > perhaps not the only way... Choices are good. Also, because IPv6 is not widely deployed yet we have not seen all that it can do. The company above could solve their renumbering problem using IPv6 NAT. I am not referring to the stateful packet inspection that is called NAT in the IPv4 world but a simple one-to-one mapping of IPv6 addresses. As long as we keep the classic IPv6 addressing plan there is no need for geotop addressing to solve all corner cases. --Michael Dillon From rich at nic.umass.edu Wed Nov 23 10:17:30 2005 From: rich at nic.umass.edu (Rich Emmings) Date: Wed, 23 Nov 2005 10:17:30 -0500 (EST) Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: On Wed, 23 Nov 2005, Michael.Dillon at btradianz.com wrote: > > I can't understand the benefits to a company of having a > single prefix as opposed to half a dozen. It's all inside > their own network anyway. > A number of reasons. Example: You can more easily recognize your own traffic from 'foreign' when applying policy, and router configurations are a lot shorter when you only have one or two prefixes to deal with as opposed to 15. A lesser config leads to lesser chance of configuration errors, so improves overall reliability. The usefulness of this depends from org to org. That said, I tend to prefer two medium chunks to one large one, as when things go off base globally with one, a portion of your space stays reachable. But in saying I want 2, doesn't mean I want more. Now, the tension between size of the global tables, and efficient allocation to LIR's may vary from being mutually beneficial, to being polar opposites, hence existing policy concerning not issuing of address space only for administrative convenience. --- Since we're still beating Dobbin the deceased, when it comes to multihoming for diversity purpose, I want the 2nd system to be as separate as possible. 2nd city, 2nd routing block, 2nd provider, etc. More recently Katrina and less recently NYC provides some lessons in business continuity over a large geo area disaster. Level 3 and Cogent's little dance speak of the need for [true] provider diversity. Geo based systems provide that 2nd prefix, but so does multiple allocation of _any_ kind without the attempt to maintain a an optional, secondary hierarchy. I also catch a strong whiff for the possibility of a geo based system making censorship much easier. --- That said, your goals concern intra geo area routing, to attempt keep it close. There have been, and are some models which of this. Example the old educational NEARNet and the phoenix of that, the current Boston Gigapop. The gigapop is part of I2/Abilene so there are barriers to admission, Traffic in the gigapop between member institutions remains local to the area. Traffic outside of the area, but on I2, heads off to other I2 gigapops (or the member institution routes it out I1) It doesn't use geo addressing. there's more than another way to solve the problem you want to solve. From tony.li at tony.li Wed Nov 23 13:23:30 2005 From: tony.li at tony.li (Tony Li) Date: Wed, 23 Nov 2005 10:23:30 -0800 Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: >> If they are >> connected via both, then we're gonna have the multihoming >> argument (again). > > We are also talking about corner cases. No addressing > plan will solve everyone's business problems. If they > are multihomed via two cities they can renumber into > a classic IPv6 allocation. Current ARIN policies also > have limitations that force people to do things like > renumbering. This is hardly a corner case. There are tons of companies built around the HQ and remote sales office model. All of the VPN hype that you've seen over the last few years is precisely to help these people construct exactly these networks. > As long as we keep the classic IPv6 addressing plan there > is no need for geotop addressing to solve all corner cases. It would seem to me that you're suggesting that there's no need for geotop addressing. Tony From tony.li at tony.li Wed Nov 23 13:25:31 2005 From: tony.li at tony.li (Tony Li) Date: Wed, 23 Nov 2005 10:25:31 -0800 Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: > A company that has geotop addresses will only receive an > allocation that is sized according to their needs in one > metro area. If they want to expand to other metro areas, > their allocation will not be big enough. The logical course > of action is to apply for allocations in the other metro > areas. > > I can't understand the benefits to a company of having a > single prefix as opposed to half a dozen. It's all inside > their own network anyway. If the remote sites are topologically connected through HQ, then each additional prefix that they require needs to be advertised globally through the HQ ISP. This could be an issue for the ISP and is certainly an issue for interdomain routing. Tony From owen at delong.com Wed Nov 23 13:34:55 2005 From: owen at delong.com (Owen DeLong) Date: Wed, 23 Nov 2005 10:34:55 -0800 Subject: [ppml] geo addressing In-Reply-To: References: Message-ID: <21391FC7840D971E18848ADB@odpwrbook.local> You're still ignoring the case where they are connected both to HQ (or each other in some other topology other than a star) _AND_ local internet connectivity. It is not an all or nothing game. Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 186 bytes Desc: not available URL: From Michael.Dillon at btradianz.com Wed Nov 23 18:27:49 2005 From: Michael.Dillon at btradianz.com (Michael.Dillon at btradianz.com) Date: Wed, 23 Nov 2005 23:27:49 +0000 Subject: [ppml] geo addressing In-Reply-To: Message-ID: > This is hardly a corner case. There are tons of companies built around > the HQ and remote sales office model. All of the VPN hype that you've > seen over the last few years is precisely to help these people construct > exactly these networks. If those really are pure VPN locations, then the local addresses are irrelevant because everything in the remote sales office will likely be addressed using HQ addresses. The HQ and the remote sales offices could achieve local multihomed resiliency of access connections using geotop addresses. > It would seem to me that you're suggesting that there's no need for > geotop addressing. No, I'm suggesting that it is not necessary for a solution to be an all-singing magic bullet in order for that solution to be useful and worthy of implementation. Geotop addressing will dampen the growth of the global route table by enabling millions of small end medium enterprises to multihome at the local level without consuming global routing table slots. Clearly, any solution aimed at small and medium sized companies will not be optimal for larger ones and there will probably be a threshhold where it does not work at all. That's why I don't think geotop addressing needs to address every corner case. It is another option in the toolkit that will work well in some cases and not in others. --Michael Dillon