This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/address-policy-wg@ripe.net/
[address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Previous message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Next message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Kurt Erik Lindqvist
kurtis at kurtis.pp.se
Tue Jun 22 16:14:19 CEST 2004
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>> 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? > > Read the draft of end to end multihoming. Ok, so you are actually proposing that we a) Change the allocation policies according to draft-ohta-multihomed-isps-00.txt and b) Adopt the mechanisms in draft-ohta-e2e-multihoming-06.txt ? > It is an issue of transport/application layer. So we need to modify the application layer according to the e2e draft? > Application may use UDP with its own timeout. So all UDP applications need to modified (or not used at multihomed sites)? >> But it's the multi6 WG that will have to end up selecting >> what to move forward. > > It's your problem that you failed to properly control the WG. This is a discussion that doesn't belong here, but it's not the role of the WG chairs to control the WG. It's the chairs job to conclude what solutions there are support for and which ones there are not. This is the reason for the classification of solutions sent to the multi6 WG and the statement that many of them simply do not have any support. >> So each TLI can have their own policy for their down-stream NLIs? Who >> decides who are the TLIs? > > If you need an example policy, read the draft. Make a bidding round for the TLI roles? So you want an open market for default-free address space? >>>> It does not address the non-balance of >>>> local vs global traffic coverage. > >> 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? > > Dominant local players may be treated as NLI or it can be an > independent TLI. > > I know Yahoo, for example, has certain influence on its ISPs. So Yahoo would qualify as a TLI? If they won a TLI assignment in the bidding round? While for example NTT might not? >>> 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. > > I do recognize the policies and says them orthogonal. Well, the bidding for address space has a large chance to off-set the financial models of the Internet today. >> 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. > > You miss the point. I'm saying all the ISPs have chance to change > its prefix. Why would customers go to NLIs in the first place? I for one would only by service from TLIs. - - kurtis - -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQNg+vqarNKXTPFCVEQKuBgCfThWCvXgCnbYfsyFvRFxUlBsbnMUAn3hs LKmspmiIwsGGSWDu80HV4m56 =lPg6 -----END PGP SIGNATURE-----
- Previous message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
- Next message (by thread): [address-policy-wg] Re: Fallacy by Kurt (was Re: IPv6 Policy Clarification - Initial allocation criteria "d)")
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]