RE: Criteria for initial PA Allocation
On Tuesday, May 22, 2001 23:03, Poul-Henning Kamp [SMTP:phk@critter.freebsd.dk] wrote:
In message <002101c0e301$8b591f00$0600000a@hph>, "Hans Petter Holen" writes:
| >I think it makes sense - if you are not able to fill a /22, your network | >is "smallish". So using PA space and renumbering when changing ISPs is | >not *that* hard, if done properly (DHCP, DNS, no hard-coded IP addresses | >anywhere). | | I know several companies who would be willing to renumber once per year | as long as they can be multihomed...
Why should I have to renumber once a year to be multi-homed ?
I'm not saying you should, I'm saying people are willing to it.
To me that indicates that we are not looking at the problem right now, but on a symptom of the >real< problem.
I think the solution to the real problem is to find a better method for assignment of routable IPs to multihomed customers.
Exactly. Allowing /22's to be allocated is probably not a good idea and certainly doesn't solve anything on the longer term. However imposing a certain amount of minimal usage doesn't also solve the real problem. The base rule for address assignments is that people ought to get what they technically need, no more and no less. The base rule for an allocation is that people should get one if they technically need one. They will need to explain this in their application for a LIR. The only problem of course is what are the technical criteria for this. For a start we could ask the potential LIR to specify why he is not able to use any alternative method and only grant the allocation if he is able to provide a satisfying answer or if he can justify a minimal usage of a /22 (within 2 years time?) I don't think that there is a need for justifying why the person wants to be multi-homed. Even if it's not a good reason, everybody should have the freedom choosing multiple ISP's. How are we going to apply those rules in IPv6 BTW? Justifying the usage of a quarter of the minimal allocation is going to be difficult for anyone. Regards, Bert
-- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by
incompetence.
In message <D4AB12F271F2D31198CD00902727DF0302470E96@ams500nt.colt-telecom.nl>, "Hogeloon, Bert van" writes:
I don't think that there is a need for justifying why the person wants to be multi-homed. Even if it's not a good reason, everybody should have the freedom choosing multiple ISP's.
Maybe this is the way we should attack the problem ? Rather than allocating /22 to each customer who wants to be multihomed, why not allocated the /22 jointly to the two ISP's to use for this and other future multihomed customers ? At least it scales a lot better routing wise... In all likelyhood, we could even generate a new market where ISP's team up and offer multihoming as a service without exploding the routing tables... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.
A lot of the problem seems to boil down to education of the customer. Last year I suggested a method of creating multihomed-ness without the need for customers to use a public AS and lots of address space. A few people commented on it. It transpired that the technique had been suggested before by other people as well. http://uk.geocities.com/maff2k/multi.doc It's by no means finished and I haven't done any more to it since last year. If we can get customers to adopt different methods of multihoming then we should be able to solve the problem. Otherwise we might as well accept that the routing table is going to explode :-( Matthew
On Wednesday 23 May 2001 11:41, Matthew J Robinson wrote:
It's by no means finished and I haven't done any more to it since last year.
If we can get customers to adopt different methods of multihoming then we should be able to solve the problem. Otherwise we might as well accept that the routing table is going to explode :-(
I'm just think about routing table size - allowing customers to multi-home (and perferably load balance over both of their links) - and am not really worrying about IP space conservation. ie. basically thinking in an IPv6 world. As with Matt's document, ISPs that want to provide multi-homed service from co-operative pairs. There is no reason why an ISP connect be a participant in multiple pairs. When forming this relationship they go to RIPE and get a 'special' pair block of reasonable size - ie. large enough to fit a good number of potential customers. It would be great if a very large block could be set aside for this purpose so that such blocks are easily recognised. Both ISPs announce this block as a single route. This route will naturally be seen on the Internet sourced from two ASs - is that so bad? I can't think of it breaking BGP. Customers who purchase a multi-homed service from these ISPs get allocated an IP range within this block. Routing of the customer's block (which can be any size, but in an IPv6 world doesn't need to be that small...) can be done either by the ISPs statically routing to the customer or talking BGP to the customer with the customer using a 'private AS' as with Matt's document. The two ISPs advertise all more-specifc routes within this special block to each other - but no-one else. Should one of the customer links fail any traffic that does go to the failed provider should be transfered to the other ISP for delivery. As with everything, it has a few problems, If the customer wants to change either provider they need to re-number - which is not nice. It could be possible for ISP A to break, still announce the large special block and not have access to either the customer or ISP B - in which case ISP A could be blackholing the customer's data for some parts of the Internet - again not nice ;-( Oh, yeah, it requires someone to use ipv6 ;-) Regards, aid -- Adrian Bool | http://noc.vianetworks.net/ Director, Global Network | tel://+44.1925.484061/ VIA NET.WORKS Inc. | noc://+49.203.3093.1111/
Adrian;
I'm just think about routing table size - allowing customers to multi-home (and perferably load balance over both of their links) - and am not really worrying about IP space conservation. ie. basically thinking in an IPv6 world.
So, global routing table size should be <<10K.
If the customer wants to change either provider they need to re-number - which is not nice.
It could be possible for ISP A to break, still announce the large special block and not have access to either the customer or ISP B - in which case ISP A could be blackholing the customer's data for some parts of the Internet - again not nice ;-(
Oh, yeah, it requires someone to use ipv6 ;-)
A serious problem is that there are many tuples of ISPs. Masataka Ohta
participants (5)
-
Adrian Bool -
Hogeloon, Bert van -
Masataka Ohta -
Matthew J Robinson -
Poul-Henning Kamp