Daniel Roesen wrote:
On Wed, Dec 07, 2005 at 03:12:02PM +0100, Jeroen Massar wrote:
ISP's are already doing this in IPv6. The only thing to 'stop' it is to have "most" ISP's filter those announcements. But even if you filter then the prefix is still reachable through the aggregate, thus connectivity isn't lost.
Wrong. It's lost if your link to the aggregate provider is down at that time, or this network having BGP/IGP problems.
Why would that impact your connectivity when you are properly announcing your prefix? Except of course when there are ISP's that filter your prefix out. But hey that is their choice. They can also filter out a /32 if they like to do that. Their network. You can ask them to not do it. Or we can have a single block that contains all these prefixes so that they basically have to do it. Isn't the idea of having a more specific prefix that you actually make sure that your more-specific prefix actually get announced properly. If you have a IPv4 /24 and you cut it up in /28's and start announcing those at the moment, isn't it then your own responsibility to make sure those /28's actually get propagated properly? Indeed this requires asking people to lift their filters. This is the same as for IPv6 with /48's. As long as your more-specific /48 is correctly in the routing tables you get reached over those. When it is not, well you are not.
The more-specific multihoming idea works only if noone filters, and then you lose the only advantage that scheme has: the ability to filter.
It also works when there is a clear defined block that is used for this purpose so that ISP's can filter less strictly for that block.
Doesn't work, next try... ;)
Indeed doesn't work for folks who don't want to read and can only complain but can't come up with their own solutions or think along.
Instead of an end-site going to the RIRs for IP space, let them come to you, you being LIR. You as a LIR give them a /48 (or more) and say they can use their own ASN to announce it to their peers and transits. As long as those parties accept it they are fine. This also means you will have a plan for 200 potential customers :) The first side-effect is that your customers are (partially) dependent of you, you as LIR disappears, then they don't have squat.
Not only then, but also for things like IRR and DNS reverse delegations.
Again, only a half-solution.
What is the difference of going to "Organisation X", who are a LIR, or "Organisation Y", who are a RIR ?
Then again if RIPE disappears, what then? :)
Then we have other problems, as has each and every LIR.
What is the difference of a RIR disappearing with whom you do business or a LIR with whom you do business?
What is a 'real LIR' actually according to you and whatisn't?
A "real LIR" is a Local Internet Registry. A Local Internet Registery assigns resources they got allocated by a RIR to hand out to end users. As PI space isn't subassignable, PI is not an option for LIRs.
If you haven't noticed, current LIR's get an IPv6 PA prefix. You are trying to get address space for an end-site (you don't subassign, if you did you could become a LIR, okay at 200 customers). Thus my suggestion is that you can go to a LIR and get a part of their PA prefix and announce that. Simple.
They all are in it for the money in the end. If their business is renting out "address space" (like the RIR's do effectively) then so be it, that is their business.
But we're talking about independent IP space for "end users", not for LIRs.
Apparently my description of what I meant was too difficult to understand, thus I'll try to make it more clear: *) IANA has all the address space *) RIR's get address space from IANA *) LIR's get address space from RIR's *) end-sites get address space from LIR's Thus a LIR has a PA prefix. This LIR acts as a "PI provider for ISP's". Then an endsite comes to them (eg you) and asks for a /48. LIR gives you a /48, you announce that /48 as it being PI. You make sure that you announce that prefix properly, maintain multiple links and generally don't care about the PA prefix that is getting announced. The LIR might not even announce the PA prefix. The only reason left for having a link to the LIR would be because some people filter out the more specifics. Indeed the "PI prefix" is not registered as such at the RIR's, but you can still insert route6 objects in the RIR's db (if they support that :) and you can route it. WOW surprise: this is already being done today! PS: see Gert's anwer to my very related question and then wonder why I asked it in the first place: http://www.ripe.net/ripe/maillists/archives/address-policy-wg/2005/msg01272.... </repeat for x'th time> [..]
Of course some independent contractor could do a lot of PI requests for independent organisations, but then that entity is sort of working like a LIR, but then differently.
I cannot follow this analogy, sorry. This contractor isn't responsible for the assigned resources in the future, but the receiving end user is. Unlike LIR PA space where the LIR is in charge.
The employees at a LIR never change jobs/functions/roles? LIR's don't sometimes actually hire a contractor to do their work? The contractor also knows how to fill in the paperwork. As you didn't notice the above was in defense for non-LIR's doing requests. [..]
I thought you needed PI because you wanted to do "traffic engineering", how are you going to do traffic engineering with the following in your tables:
::/0 fe80::2 eth0 ::/0 fe80::1 eth1
Or you only want "Inbound TE" ($world to you) and not "Outbound TE"?
I want to do both. Read again.
You only claimed to be wanting to do "Traffic Engineering", never stated what kind of direction.
You're in the camp denying all but ISPs the "right" to do BGP, because it's technically not necessary.
Currently it is technically necessary, as there is no alternative. Which is why I suggest a big block where these "endsite PI" assignments can come from, or a special LIR which handles these blocks. So that in the future we can see 'those blocks are actually "endsite PI"' and let them solve their problems with the new technologies that have risen. Note that the 'camp' I am in is my very own little private club where I am the sole member and nobody else can join. There is nobody giving me any money for this stuff either.
Of course it isn't if you ignore all requirements put forward, but then it's also not necessary for the ISPs - except the real Tier 1s.
If you would actually *read* what I am writing, summed up for the xth time again above, maybe I need to add pictures or something; I have already suggested a number of times that ISP's should be able to get a /48 or whatever prefix from either a LIR or directly from the RIR's so that they can announce it into BGP, just like that is already currently happening...
Outbound TE is the easy part anyway, inbound TE is the tricky one. But I know that you understood BGP, so I'm not telling news here. :-)
Economics, that is people who won't be able to update their routers, will then figure out who can have a slot there or not. No, they will start to default as they still need to access the content. Thus add extra prefixes to the routing tables, let everybody upgrade their routers, but don't do it yourself. Nice. Letting others pay for your dirt.
Who are the others who NEED to upgrade? Only real Tier 1s. Only they NEED to have a "full table". All others can default to various degree, even to the extremes. Don't ignore that fact.
If you don't have a full table, you can't do much Traffic Engineering either. Or are you going to say "2003::/16 is europe that goes over Transit X" ? Then you should not have a problem with a chunk of space from a PA provider either.
RIR's fortunately do not guarantee routability, thus them giving out /48's from a single global /16 or so, to sites 'that desperately need them', allows people who don't want them to filter when table pressure become tight. Adding some geography in that big block might even allow one to at least carry the traffic to a 'local' IX to hand it off. Hand it off to whom? You need paid transit for that. You want everything for free? :)
No, I just want costs that aren't artificially inflated costs in order to push some political/economical agenda put forward by an (at large) ISP lobby.
The only lobby gaining money with this are Vendor X, Y and Z they need to build the bigger iron, not the ISP's nor the Tier1's or any other of those folks who pay those vendors...
Regarding your mentioned scenario: this kind of routing structure would definately need a complete redesign of how money flows in the global Internet, aligning more to the POTS interconnection fee model. That'll be bureaucracy unseen yet in the Internet, even with the most telcoish peering heavyweights.
There is a relatively simple charging scheme: x EUR or US$ per Gigabytes Of course you can add a wild variety of special cases like "US traffic", "Asian Traffic" etc. But this all has nothing to do with address policy, that is financial politics which you need to take care of with your upstreams.
I know the OCCAID folks are getting close to a global free transit network, but they also only arrive at IX's, your equipment still needs to be there to use those resources. People are not coming to you. But hey you know that very well :)
Uhm, I'm not OCCAID,
That was not the reason I mentioned them. The reason I mentioned it was because it demonstrates that you as an endsite still need to get a link to the IX's or some other place where to interconnect with some transit providers. These links and equipment still costs money. [..]
PS: where are all those companies who are in desperate need for this?
Not here. And my POV is more the non-commercial organization. Those had a respected place in the Internet once and weren't seen as a "nuisance who don't want to spend VC money left and right".
If they are not here, and this is the place where policies are made they apparently don't give much about all of this. If they don't know about this list: invite them. If they don't care: then there is no problem. Greets, Jeroen