RE: [ipv6-wg@localhost] Re: [lir-wg] IXP networks routing
- Date: Wed, 05 Mar 2003 22:49:15 +0100
--On Wednesday, March 05, 2003 22:27:51 +0100 Jeroen Massar
jeroen@localhost wrote:
> Case one means having more than one prefixes on the cable,
> or in diagram style:
>
> +-----+ +-----------+ 2001:db8:11:22::/64 +------+
>| the +---+ Cable ISP +------------------------+ eth0 |
>| N | +-----------+ | |
>| E | | YOU |
>| T | +-----------+ 3ffe:ffff:33:42::/64 | |
>| +---+ ADSL ISP +------------------------+ eth1 |
> +-----+ +-----------+ +------+
>
> Thus YOU gets 2 different prefixes from 2 different upstreams.
> Ofcourse YOU could also get two /48's routed to him from these
> upstreams or more ofcourse. The fact is that a 'server' eg
> a web server will have 2 IP's; eg:
> www.example.com AAAA 2001:0db8:11:22::80
> AAAA 3ffe:ffff:33:42::80
This is not what we are talking about.
> Ofcourse replace Cable and ADSL with the bigger lines,
> this is just to illustrate that the definition of 'multihoming'
> is quite a different thing for most people. As I said this
> will only work when using SCTP to 'multihome' when one of the
> two uplinks fail.
>
> In case two both upstreams carry "your" prefix, eg 2001:db8:11:22::/64
> to the rest of the world, diagram style:
>
> +-----+ +-----------+ 2001:db8:11:22::/64 +------+ +------+
>| the +---+ Cable ISP +------------------------+ R | | |
>| N | +-----------+ | o | | |
>| E | | u +----+ eth0 |
>| T | +-----------+ 2001:db8:11:22::/64 | t | | |
>| +---+ ADSL ISP +------------------------+ er | | |
> +-----+ +-----------+ +------+ +------+
This is more to the point.
> Note that the moment you only have one physical path to the rest of
> the world you should not be talking about 'multihoming' any more (case
> 3)
>
> I always wonder why people want L3 level 'multihoming' even though
> their L1 and L2 path aren't.
Because even if backhoes are quite common creatures, the network engineer
with fat fingers is even more common.
Having said that, I agree that several redundant links are a practical
prerequisite.
>> Although my idea is to give people so much space in their initial
>> allocation that only the biggest networks will need more than
>> one prefix, thus keeping the routing table as close to
>> "nPrefixes == nAS-numbers" as possible.
>
> Every ISP that can match up to the current requirements for address
> space
> can get a /32 from all three RIRs. If you can't, you simply are not big
> enough and you won't have any multiple links either.
Which is my point, sort of. But I still want the requirements slacked to
fuel deployment.
> If one really wants 99.9% certainty that their inet works one either
> needs
> to do it themselves and thus get multiple L1+L2 paths and the hardware
> along
> with it and then most of the times you are a big enough customer to get
> a
> /32 too. If you aren't you should just get a better upstream.
> Yes, I know, it all sounds quite harsh.
No disagreement there. But I do not think we talk about the same thing, or
at least not in the same scale.
--
Måns Nilsson Systems Specialist
+46 70 681 7204 KTHNOC MN1334-RIPE
We're sysadmins. To us, data is a protocol-overhead.
Attachment:
pgp00005.pgp
Description: PGP signature
|