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

Re: [ipv6-wg] Re: [address-policy-wg] Re: 200 customer requirementsfor IPv6

  • To: Iljitsch van Beijnum <
    >
  • From: Sascha Lenz <
    >
  • Date: Tue, 06 Dec 2005 15:59:44 +0100
  • Cc:
    ,
  • Organization: BayCIX GmbH

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@localhost         =
= Network Operations                                                   =
= BayCIX GmbH, Landshut                  * PGP public Key on demand *  =
========================================================================




 

Next Section
     About RIPE | Site Map | LIR Portal | About the RIPE NCC | Contact | Copyright Statement
RIPE.NET Homepage LIR Portal RIPE Community