On 09/14/11 15:03, Brian E Carpenter wrote: > 2. For serious enterprise networks, renumbering still needs work (see RFC 5887).
> That work is starting, please join in: http://datatracker.ietf.org/wg/6renum/charter/
> The more operator input we have into that work, the better.
I took a look a the 6RENUM charter. This "out-of-scope" part of the
charter bugs me a bit: > 3. ISP renumbering; this is potentially the most complex renumbering
> case. However, more benefit can be achieved by focusing effort on site
> renumbering. The enterprise site analysis should include the ISP's role
> in the site's renumbering events.
A huge chunk of the IPv4 table bloat is not coming from end sites
announcing their multi-homed networks via BGP.[1,2] A lot of v4 table
bloat is caused by SPs that aren't able/willing to aggregate, either
because they got their fragmented prefixes over many years or they
acquired other providers and couldn't aggregate their prefixes (but
still wanted the address space).
So far, most of the IPv6 renumbering effort has focused on end-sites.
But in IPv4, there's a lot of theoretical ground to be gained by
renumbering service providers, *in addition to* end sites.
I can imagine end sites looking askance at SPs who appear to keep
focusing on site renumbering and ignoring the thorny, but important
issue of SP renumbering. As long as the costs appear skewed toward the
end-sites, even if they are low, you're not going to get a whole lot of
sites choosing end-site renumbering over BGP multihoming. That's partly
because the renumbering question only deals with the
renumbering-avoidance motivation for BGP multihoming; the 6RENUM WG
doesn't seem to delve into the fault-tolerance that is gained by the
instantaneous failover that BGP multihoming provides.
Looks like interesting work, though, and I will take a closer look.
*speaking for myself, noting that I currently work at an ISP.
 See http://www.cidr-report.org/
 RAS's presentation at NANOG 50 was pretty good at going through the
issues and not pointing (too many) fingers: http://www.nanog.org/meetings/nanog50/presentations/Monday/NANOG50.Talk49.Steenbergen.routingtable.pdf