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

[Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>]

Kurt Erik Lindqvist;

>>Kurt, as I made presentation in front of you and Brian
>>Carpenter at multi6 WG meeting of IETF58 in Minneapolis

> I think I have seen close to 40 presentations that all would solve the 
> multihoming problem one way or the other, or at least parts of it.

40?

Below is the agenda of the last Minneapolis meeting.

   Agenda bashing, Chairs (5 min)
   DT2 Update, David&Marcelo (5 min)
   DT1 Update, Tony&Iljitsch (5 min)
   MAST, Dave Crocker (15 min)
   draft-arifumi-tcp-mh-00, Arifumi Matsumoto (10 min)
   draft-ohta-multihomed-isps-00, Masataka Ohta (15 min)
   draft-ohira-assign-select-e2e-multihome-02, Kenji Ohira (10 min)
   LIN6 update, Masahiro Ishiyama  (5 min)
   draft-nordmark-multi6-threats-00, Erik Nordmark (5 min)
   draft-nordmark-multi6-noid-01 and draft-nordmark-multi6-sim-01, Erik Nordmark (10 min)
   Update from chairs and where we go next
   Open microphone

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

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

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

>>Since then, you made no counter argument against my
>>presentation that it is your fallacy to say things
>>against the presentation.

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

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

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

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

The issue is orthogonal to my draft.

> It does not address what the financial 
> models for transit would be.

No, of course.

It is a policy issue orthogonal to my draft.

> It does not address the non-balance of 
> local vs global traffic coverage.

No, of course.

For TLI, only the global traffic is important.

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

> So it's really hard to say 
> anything regarding it.

which means you have been indifferent to multi6 issues.

>>>If he changes the single upstream his customers needs to
>>>renumber.
>>
>>If one changes homing, one needs to renumber, of course.

> Which is a limiting factor that I think you will that customers will 
> find unacceptable.

Huh?

What can the customer do, then?

Note that it is not acceptable for the customer to switch to
other ISP only to change its address.

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

Are you saying to discourage signing up with any ISP which
may possibly stop operating in the future?

							Masataka Ohta