Site Renumbering (RENUM) BOF at IETF 80

THURSDAY, March 31, 2011, 1520-1720, Congress Hall II

Chairs: Brian Carpenter + Tim Chown

Sponsoring AD: Ron Bonica

Mailing list: renum@ietf.org
Subscribe: https://www.ietf.org/mailman/listinfo/renum

Description
-----------

As outlined in RFC 5887, renumbering, especially for medium to large 
sites and networks, is viewed as an expensive, painful, and error-prone
process, avoided by network managers as much as possible. Some would
argue that the very design of IP addressing and routing makes automated
renumbering intrinsically impossible.  In fact, managers have an economic
incentive to avoid having to renumber, and many have resorted to private
addressing and Network Address Translation (NAT) as a result.  This has
the consequence that any mechanisms for managing the scaling problems
of wide-area (BGP4) routing that require site renumbering have been
dismissed as unacceptable. Even so, renumbering is sometimes unavoidable.  

It is expected that as the pressure on IPv4 address space intensifies
in the next few years, there will be many attempts to consolidate usage
of IPv4 addresses so as to avoid wastage, which necessarily requires
renumbering of the sites involved.  Unfortunately, current IPv4 deployment
practices mean that automating this process appears extremely difficult.
However, strategically, it is more important to implement and deploy 
techniques for IPv6 site renumbering, so that as IPv6 becomes universally
deployed, renumbering can be viewed as a relatively routine event.

For renumbering to become routine, a systematic address management approach
will be essential. A large site with a short prefix will be divided into
subnets with longer prefixes. In this scenario, renumbering or partial
renumbering can be complicated. Aggregation, synchronisation, coordination, 
etc., need to be carefully managed.

The task of the RENUM working group is to identify specific renumbering
problems in the context of site-wide renumbering, and to develop point solutions
and system solutions to address those problems, or to stimulate such development
in other working groups if appropriate. The principal target will be solutions
for IPv6, but solutions that apply equally to IPv4 may be considered.

RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are starting points
for this work.

Goals/deliverables
------------------

Develop draft-jiang-ipv6-site-renum-guideline as a roadmap for the WG
and for items that should be specified by other WGs.

 - The result of this work will be a more specific list of goals and deliverables

Develop a management model for site renumbering.

Milestones
----------

Jul 2011    draft-jiang-ipv6-site-renum-guideline ready for WGLC
Sep 2011    draft-jiang-ipv6-site-renum-guideline ready for IESG
Oct 2011    management model ready for WGLC
Nov 2011    recharter with specific goals and deliverables
Dec 2011    management model ready for IESG

BOF agenda
----------

0. Agenda Bash, Intro. (5 min)

1. Brief review of RFC 5887. (Brian Carpenter, 10 min)

2. Main lessons from UNH experience (Tim Winters, Lincoln Lavoie, 10 min)

3. Review of draft-jiang-ipv6-site-renum-guideline. (Sheng Jiang, 15 min)

4. Brief review of RFC 4192, and a management model for systematic renumbering. (Fred Baker, 15 min)

5. Brief announcements of "solution space" drafts (1 slide each, 2 min each):

5.1. Border Router Discovery Protocol (BRDP) framework, draft-boot-brdp-framework (Teco Boot)
5.2. IRON for renumbering, RFC 6179 (Fred Templin)
5.3. SAM for renumbering, draft-despres-softwire-sam (Rémi Després )
5.4. Diagnostic function for SLAAC/DHCPv6 conflicts, draft-liu-ipv6-renum-conflicts (Bing Liu)

6. Discussion of goals and milestones. (30 min)

7. Discussion of conclusions (further work justified? WG? Which area?). (10 min)