[address-policy-wg] Re: AddOn --- Re: Re: Re: a consensus, about what?

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

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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 238 bytes
Desc: OpenPGP digital signature
URL: </ripe/mail/archives/address-policy-wg/attachments/20051231/cb094789/attachment.sig>