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/ipv6-wg@ripe.net/
[ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
- Previous message (by thread): [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
- Next message (by thread): [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sascha Lenz
slz at baycix.de
Tue Dec 6 15:59:44 CET 2005
Hi,
Iljitsch van Beijnum wrote:
> My apologies for replying to such an old message, but I couldn't let
> this one go.
>
> On 18-nov-2005, at 12:33, Sascha Lenz wrote:
>
>> In particular, noone came up with an equal solution to BGP Multihoming
>> with "PI"-space, which i hoped for back then.
>
> Well, you haven't been paying attention, because I've presented
> "provider-internal aggregation based on geography" at two different
> RIPE meetings a while ago.
Actually, i did pay attention, but why do you think i consider that as
an equal solution to BGP Multihoming with "PI"-space?
It's _ONE_ alternative solution one might suggest, but still no reason
for disallowing anyone in the globally distributed prefix table.
Why do i want this at all? Because there are globally distributed
prefixes right now, there is no geographically based assigment in sight
anywhere and yes your presentation was a while ago.
IIRC even your presentation said that this would require geographically
based assigments "right now". Right?
Do you expect everyone with a prefix today to give it back and renumber?
"Too late" at least for a full solution. This is just another suggestion
that might be helpful for preventing some amount of global prefixes (see
below), but not god's own solution to the problem.
> The only thing I got was perplexed stares.
>
> You really can't expect to keep doing the same thing we've been doing
> in IPv4 in IPv6 but now with different results (= more reasonable
> routing tables).
*think*
Of course... as mentioned before by many people, IPv6 implicitly solves
some of the problems with "too many routes".
Again, this leads to:
- "usually" only one Prefix per AS even with nowerdays IPv6 policy
==> "more reasonable routing table" per default because almost noone
needs a second Prefix
- no impact on the IPv4 Routing Table size which you have to carry
around for decades anyways.
==> no relief for any router in sight, regardless of the the IPv6 policy
- There _ARE_ multihoming solutions besides world-wide prefix
announcements, there are many. You can suggest all of them to your
customers when they ask for "redundancy" or so. You even could be
required by policy to tell your customers about the solutions as i
suggested during the current thread.
BUT - if someone insists on BGP Multihoming with worldwide prefix
distribution for whatever reason he/she might have, noone must be
forbidden to do so!
==> Even less End-site-customers who want an AS and PI-Prefixes
because some actually _ARE_ OK with alternative.
Noone denies the fact that there are most likely too many prefixes and
probably even too many ASes in todays IPv4 Internet Routing Table.
It's also a fact that many of them are not really needed, and the
desired redundancy could be achieved by other means. Some customers
might even be happy if they don't need to care for BGP Speaking Routers
or so in their network and are pleased if you suggest a different solution.
The main problem is just people who want to tell "me" (not literally)
what's best for "my" network, and disallow "me" in the pond with the big
fish.
..and there are absolutely no technical reasons which would forbid "me"
in this pond if i want to swim there.
--
========================================================================
= Sascha Lenz SLZ-RIPE slz at baycix.de =
= Network Operations =
= BayCIX GmbH, Landshut * PGP public Key on demand * =
========================================================================
- Previous message (by thread): [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
- Next message (by thread): [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirements for IPv6
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ ipv6-wg Archives ]