Re: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt

["George, Wes" <[e-mail]>]

Generally I think this is good, and it's probably ready to go after a revision to address WGLC comments.

I do see one area where I've made previous comments that never really made it into this gap analysis, which is as it relates to the need for a layer of abstraction for IP-specific configuration within routers/switches and hosts (servers, etc). While you discuss filtering updates in section 7, the number of places where a bare IP is configured in your average router is quite a lot more than just there, sometimes even including things like derived values (using the unique portion of the loopback address to generate an ISIS net ID is common, for example).

Some of this can be solved because IPv6 allows multiple addresses and can do make before break renumbering (changing the addresses on interfaces, BGP sessions, etc) but I've said more than once that this is still a fairly manual and resource-intensive process, prone to mistakes. Likewise, use of FQDN everywhere that it's supported helps, but it's not supported everywhere you'd use an IP, nor is it always appropriate on a box that might need the IP address in order to keep working even if DNS is dead. We could see a lot of benefit from implementations of configuration management tools/CLI that allow you to use inheritance so that there is only one place in the config where the IP address is defined, whether statically or via dynamic means, and the rest of the config simply references and inherits it. There are a lot of "devil in the details" problems here about how you automatically update the inherited or parent/child config without causing disruption or non-deterministic behavior, but that's worth discussing as a problem to be solved. A well-parameterized configuration management system also has the net benefit of solving some of the filtering problems you discuss. Some of this would be implementation-specific, but I think we can articulate clear gaps there to give good guidance to implementers to make this easier.
With the advent of SDN and Openflow, I'm thinking that it's perhaps less of an intractable problem than it might have been in the past, so for completeness, we do need to discuss it in this gap analysis. It may be appropriate to have this in the static draft, but I wanted to raise it here and let the authors and WG decide how best to address it.

Thanks,

Wes

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf
> Of Howard, Lee
> Sent: Thursday, September 06, 2012 12:18 PM
> To: [e-mail]
> Subject: [renum] Working Group Last Call: draft-ietf-6renum-gap-
> analysis-03.txt
>
> We are requesting a Working Group Last Call on this document.  Please
> review and provide comments before September 19, since this may be the
> final review of this document.
>
> Thanks,
>
> Lee
>
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On Behalf
> > Of internet- [e-mail]
> > Sent: Monday, September 03, 2012 11:38 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: [renum] I-D Action: draft-ietf-6renum-gap-analysis-03.txt
> >
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> >  This draft is a work item of the IPv6 Site Renumbering Working Group
> of the IETF.
> >
> >       Title           : IPv6 Site Renumbering Gap Analysis
> >       Author(s)       : Bing Liu
> >                           Sheng Jiang
> >                           Brian Carpenter
> >                           Stig Venaas
> >       Filename        : draft-ietf-6renum-gap-analysis-03.txt
> >       Pages           : 20
> >       Date            : 2012-09-03
> >
> > Abstract:
> >    This document briefly introduces the existing mechanisms could be
> >    utilized by IPv6 site renumbering and tries to cover most of the
> >    explicit issues and requirements of IPv6 renumbering. Through the
> gap
> >    analysis, the document provides a basis for future works that
> >    identify and develop solutions or to stimulate such development as
> >    appropriate. The gap analysis is presented following a renumbering
> >    event procedure clue.
> >
> >
> >
> >
> > The IETF datatracker status page for this draft is:
> > https://datatracker.ietf.org/doc/draft-ietf-6renum-gap-analysis
> >
> > There's also a htmlized version available at:
> > http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-03
> >
> > A diff from the previous version is available at:
> > http://www.ietf.org/rfcdiff?url2=draft-ietf-6renum-gap-analysis-03
> >
> >
> > Internet-Drafts are also available by anonymous FTP at:
> > ftp://ftp.ietf.org/internet-drafts/
> >
> > _______________________________________________
> > renum mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/renum
>
> Lee Howard
> Director, Network Technology
> Time Warner Cable
> [phone]
> 13820 Sunrise Valley Drive, Herndon VA 20171
>
>
>
> This E-mail and any of its attachments may contain Time Warner Cable
> proprietary information, which is privileged, confidential, or subject
> to copyright belonging to Time Warner Cable. This E-mail is intended
> solely for the use of the individual or entity to which it is addressed.
> If you are not the intended recipient of this E-mail, you are hereby
> notified that any dissemination, distribution, copying, or action taken
> in relation to the contents of and attachments to this E-mail is
> strictly prohibited and may be unlawful. If you have received this E-
> mail in error, please notify the sender immediately and permanently
> delete the original and any copy of this E-mail and any printout.
> _______________________________________________
> renum mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/renum

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.