[address-policy-wg] Re: [ipv6-wg] IETF working group on renumbering in IPv6

Hi Shane,

Many thanks for advertising the new WG to these lists.

The charter was refined further since the one below, the final one being listed here:
	 http://datatracker.ietf.org/wg/6renum/charter/

We would welcome any contributions to the renum mail list, see: 
	https://www.ietf.org/mailman/listinfo/renum

Currently I am one chair for the WG, another is being sought.  I'm very happy to take any comments or inputs directly if people have views but do not wish to join the mail list.

There should be a 6renum WG slot in Quebec at IETF81.  I hope to attend RIPE63, so perhaps we can also have a slot for this in the IPv6 WG session there.

Many thanks,
Tim

On 21 Jun 2011, at 10:58, Shane Kerr wrote:

> All, 
> 
> There is some idea to work on the renumbering problem in IPv6.
> 
> This is certainly of interest to IPv6 folks, but I am including the
> address policy folks as this may ultimately have impact there.
> 
> Cheers,
> 
> --
> Shane
> 
> From: IESG Secretary <iesg-secretary at ietf.org>
> Date: 2 June 2011 18:54:54 GMT+01:00
> To: IETF Announcement list <ietf-announce at ietf.org>
> Cc: renum at ietf.org
> Subject: WG Review: IPv6 Site Renumbering (6renum) 
> Reply-To: iesg at ietf.org
> 
> 
> A new IETF working group has been proposed in the Operations and 
> Management Area.  The IESG has not made any determination as yet. The 
> following draft charter was submitted, and is provided for informational 
> purposes only. Please send your comments to the IESG mailing list 
> (iesg at ietf.org) by Thursday, June 9, 2011                            
> 
> IPv6 Site Renumbering (6renum) 
> -------------------------------
> Last Modified: 2011-06-02
> 
> Current Status: Proposed Working Group
> 
> Chairs: TBD
> 
> Area Director: Ron Bonica
> 
> Mailing list
>  Address: renum at ietf.org
>  To Subscribe: https://www.ietf.org/mailman/listinfo/renum
>  Archive: http://www.ietf.org/mail-archive/web/renum/
> 
> Description of Working Group
> -----------
> 
> As outlined in RFC 5887, renumbering, especially for medium to large 
> sites and networks, is currently viewed as an expensive, painful, and 
> error-prone process, avoided by network managers as much as possible. 
> 
> As IPv6 adoption begins to gather momentum, those managers may turn to
> PI addressing for IPv6 to attempt to minimise the need for future 
> renumbering. However, such an approach would create very serious BGP4
> scaling problems if used by millions of end sites; it is thus desirable 
> to develop tools, techniques and practices that may make renumbering a
> simpler process, to reduce demand for IPv6 PI space. In addition, as
> RFC 5887 describes, there are other triggers that mean some cases of
> renumbering are unavoidable, so it should be considered a given that
> a site may need partial or complete renumbering at some stage.   
> 
> Strategically it is thus important to implement and deploy techniques 
> that facilitate simpler IPv6 site renumbering, so that as IPv6 becomes 
> universally deployed, renumbering can be viewed as a more routine event.
> This includes consideration of how the initial assignment and subsequent
> management of address information is performed, as this will affect 
> future renumbering operations.
> 
> For renumbering to become more 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, and the use of 
> manually inserted address literals minimised. In unmanaged scenarios, 
> consideration may need to be made for 'flag day' renumbering (in 
> contrast to the procedure described in RFC4192).
> 
> The task of the 6RENUM working group is to document existing renumbering
> practices for managed (enterprise) and unmanaged (SOHO) networks, to 
> identify specific renumbering problems in the context of site-wide 
> renumbering, and to then recharter with a view 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.
> 
> RFC 4192, RFC 5887, and draft-jiang-ipv6-site-renum-guideline are 
> starting points for this work.
> 
> Goals/deliverables
> ------------------
> 
> The goals of the 6RENUM working group are:
> 
> 1. To undertake scenario descriptions, including documentation of 
>   current capability inventories and existing BCPs for managed 
>   (enterprise) and unmanaged (SOHO) networks.  These texts should 
>   contribute towards the gap analysis and provide an agreed basis for 
>   subsequent WG rechartering towards development of solutions 
>   (potentially in other WGs) and improved practices. Operator input 
>   will be of particularly high value for this stage.
> 
> 2. To examine fully automatic, self-organising networks (manet/autoconf) 
>   as a possible third scenario. 
> 
> 3. To perform a gap analysis for renumbering practices, drawing on RFCs
>   4192 and 5887, to identify generic issues for network design, network
>   management, and renumbering operations. The scenario texts will
>   contribute to the analysis.
> 
> 4. To document existing IP address management models and practices with
>   a view to proposing (at a high level) an appropriate model to allow
>   simplification of any partial or full site renumbering process
>   (this would likely be applicable to managed rather than unmanaged
>   scenarios).
> 
> The general methodology for the WG will be to first build managed and
> unmanaged baseline scenario descriptions, while in parallel undertaking 
> an initial gap analysis from existing work in (at least) RFC4192 and 
> RFC5877. As the scenario texts harden, their contributions will be 
> incorporated into the gap analysis, which can be published once the 
> scenarios are completed.   
> 
> The following topics are out of scope for the working group:
> 
> 1. Renumbering avoidance; this can perhaps be considered by appropriate 
>   IRTF groups.  As documented in RFC5887, renumbering cannot be 
>   completely avoided. The WG is limited to dealing with how to renumber 
>   when it is unavoidable.
> 
> 2. IPv4 renumbering.  While many sites are likely to run dual-stack, 
>   IPv6 is the future and, especially given concerns over extensive use 
>   of IPv6 PI, the most appropriate place to focus effort.
> 
> 3. ISP renumbering; this is potentially the most complex renumbering 
>   case.  More benefit can be achieved by focusing effort on site 
>   renumbering.  The site analysis should include the ISP's role in its 
>   own renumbering event.
> 
> A recharter of the WG will be possible once the gap analysis and 
> scenario descriptions are completed, and the IP address management 
> ('numbering tool') review and (high level) proposal have been published.   
> The rechartering will identify more specific work items within the 
> 6RENUM WG or appropriate protocol WGs. 
> 
> Milestones
> ----------
> 
> Aug 2011    managed (enterprise) scenario draft ready for WG adoption 
>            (partly based on draft-jiang-ipv6-site-renum-guideline)
> 
> Aug 2011    unmanaged (SOHO) scenario draft ready for WG adoption
> 
> Oct 2011    gap analysis document ready for WG adoption (already some 
>            considerations in RFC5887 and 
>            draft-jiang-ipv6-site-renum-guideline)
> 
> Oct 2011    management model draft ready for WG adoption
> 
> Jan 2012    managed (enterprise) scenario draft ready for WGLC
> 
> Jan 2012    unmanaged (SOHO) scenario draft ready for WGLC
> 
> Feb 2012    management model ready for WGLC
> 
> Mar 2012    gap analysis document ready for WGLC
> 
> Apr 2012    recharter WG towards solution space
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce at ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </ripe/mail/archives/address-policy-wg/attachments/20110624/b2b9e89a/attachment.html>