About RIPE | Contact  | Search | Sitemap    
Homepage RIPE  
RIPE Community Mail Archives
search  
     
RIPE Navigation Ends
About RIPE Maillists
Maillists Archive
Global Lists
Non Active Lists
RIPE NCC Navigation Ends
Next Section
<<< Chronological >>> Author Index    Subject Index <<< Threads >>>

RE: [ipv6-wg@localhost] Re: [lir-wg] IXP networks routing

  • To:
  • From: Måns Nilsson < >
  • 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: pgp00004.pgp
Description: PGP signature


  • Post To The List:
<<< Chronological >>> Author    Subject <<< Threads >>>
 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | © RIPE Community. All rights reserved.
RIPE.NET Homepage LIR Portal RIPE Community