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 ]