Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")

[Kurt Erik Lindqvist <kurtis@kurtis.pp.se>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

>
> There were a lot less than 40 presentations and the number of
> proposals was even less.

Since the first meeting in Vienna there have been a lot more 
presentations. I didn't say anything about Minneapolis. Whatever.

>>> on Nov. 2003, it is possible for a small ISP delegated
>>> address blocks from multiple larger ISPs and can still
>>> have its own policy.
>
>> It's possible for a small ISP to get several blocks from their
>> upstream, route them inside their network and assign each of their
>> customers with an address out of each of those blocks. Does it scale?
>> Nope. Can it handle failures in the upstream? No. Etc.
>
> First of all, the small ISPs have multiple upstream ISPs.

Yes?

> It is explicitly stated in my draft, which is 3 pages long:
>
>    It is expected that NLIs have multiple prefixes each belonging to
>    multiple TLAs, all of which is delegated to sites.
>
> NLI is an acronym of "Next Level ISP".

Yes? And if the end host selects an address that belongs to a TLI that 
has a internal network failure and the traffic is blaockholed in that 
providers network, how does the end node find out? TCP timeout?

>> There are several of the proposals in multi6 that have never received
>> comments, nor support of any kind.
>
> That's fine, as long as you are indifferent to the issue.

I am not. But it's the multi6 WG that will have to end up selecting 
what to move forward.

> However, as you actively made statement against my draft, you
> are guilty.

"Guilty"!? Whatever.

>> Your document does not address the criterias for being classified in a
>> particular category.
>
> My document does address the criteria for being classified in TLI.
>
> Classification as NLI is up to TLIs.

So each TLI can have their own policy for their down-stream NLIs? Who 
decides who are the TLIs?

>> It does not address what would happen if an ISP
>> grow, get's split/divided.
>
> No, of course.
>
> What if, an ISP having a global routing table entry grow, get's
> split/divided?

Actually, this is an issue today. Not a complex one, but there is 
policies in place for it. And if a TLI no longer is a TLI, that will 
have implications on down-streams.

>> It does not address what the financial
>> models for transit would be.
>
> No, of course.

> It is a policy issue orthogonal to my draft.

Your draft does makes assumptions on how the policy would like. It 
actually makes assumptions that are very different from the model of 
today so I think it would be reasonable to explain the thinking. 
Otherwise I don't think to many ISPs will be interested.

>> It does not address the non-balance of
>> local vs global traffic coverage.
>
> No, of course.
>
> For TLI, only the global traffic is important.

What about TLIs that do have large customer bases in local networks? 
What about very dominant local players that today can force large ISPs 
to peer simply because of the dominance in particular markets?

>> It does not take into account the
>> current peering economics of the Internet.
>
> No, of course.
>
> It is a policy issue orthogonal to my draft.

Again, if you propose something that ignores the polices as they are 
implemented in todays Internet, I would expect at least some 
elaboration on how you see todays ISPs adopt this scheme.

>> Having to renumber when chaining ISPs is not to discourage _change_ of
>> ISP. It's to discourage signing up with that ISP in the first place.
>
> What if an ISP bankrupts (like UUNET) and stop operating?

It creates a nightmare for it's customers. Been there, done that, and 
have plenty of T-shirts to prove it. I think you miss the point. 
customers do not want to renumber if their _ISP change upstream_. That 
have a financial impact on them without them having control of the 
decision.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQNgwp6arNKXTPFCVEQIHOgCgzo+9bGXkc8O5A1wwLbC5C5f68/wAoLom
neT+RDZlLHxQTDdRyTF+Uq7y
=0ZWg
-----END PGP SIGNATURE-----