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

Brian E Carpenter <brian.e.carpenter@gmail.com> Sat, 15 September 2012 20:19 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: renum@ietfa.amsl.com
Delivered-To: renum@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42B0921E803C for <renum@ietfa.amsl.com>; Sat, 15 Sep 2012 13:19:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.599
X-Spam-Level:
X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+YxTKLbzc0U for <renum@ietfa.amsl.com>; Sat, 15 Sep 2012 13:19:01 -0700 (PDT)
Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3C22621F84AF for <renum@ietf.org>; Sat, 15 Sep 2012 13:19:01 -0700 (PDT)
Received: by ieak13 with SMTP id k13so8813609iea.31 for <renum@ietf.org>; Sat, 15 Sep 2012 13:19:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=EZ7yJ3H3zXcIU8k5V+IIYJiYyUxUMD37n8D6Tcsme2w=; b=qfqPa2DzY+NFto28TrK52jt7NIr12xoKbrcx7BeezdcZ2UusY0g5MfVK+fjVxgQJcp LLgUP8xF5rJCYF0bWfmcvh6Z81BycKw/bHmJzIbps6IgN6wj2qdNY5jtsLQIQT9K3jUY j1ChOSfOKM5ClvKBKHNt4nxX5mf4srf1db1V5XagsziD52pgxC8kOMv0dEXj/t0pBRS9 lU2Lnh0ZJ0BQmlMmbp0zI2KdmbQ/XioT6NQ3C3zbAtj+5T6cbYleIkRX5B2w/6H5T+cj VRgDtI/X60Jkkh6XPrMH6Ro2HxlRhOslUMCgq5bwxWnZppmIztk/wt27zPbEOtuPaYHk RIkw==
Received: by 10.42.23.207 with SMTP id t15mr5659358icb.3.1347740340456; Sat, 15 Sep 2012 13:19:00 -0700 (PDT)
Received: from [10.255.25.102] (50-76-68-140-static.hfc.comcastbusiness.net. [50.76.68.140]) by mx.google.com with ESMTPS id fu4sm2058989igc.4.2012.09.15.13.18.58 (version=SSLv3 cipher=OTHER); Sat, 15 Sep 2012 13:18:59 -0700 (PDT)
Message-ID: <5054E2C3.80008@gmail.com>
Date: Sat, 15 Sep 2012 21:19:15 +0100
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>
References: <99B887114EDB1449941CFBC8EC279FA12CB43E09@PRVPEXVS17.corp.twcable.com> <2671C6CDFBB59E47B64C10B3E0BD59235E0DA40F@PRVPEXVS15.corp.twcable.com>
In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59235E0DA40F@PRVPEXVS15.corp.twcable.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: Re: [renum] Working Group Last Call: draft-ietf-6renum-gap-analysis-03.txt
X-BeenThere: renum@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Renumbering discussion mailing list." <renum.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/renum>, <mailto:renum-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/renum>
List-Post: <mailto:renum@ietf.org>
List-Help: <mailto:renum-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/renum>, <mailto:renum-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Sep 2012 20:19:02 -0000

Wes,

Simply put, I think you're saying that "A well-parameterized configuration management system"
is an essential tool, and I completely agree. Actually defining all the details of
that is a product design issue, but do you think we should aim at a requirements
document for such a tool?

As for whether this should be added as a specific gap in this draft or in
draft-ietf-6renum-static-problem, I'll await guidance from the WG chairs.

Regards
   Brian

On 14/09/2012 20:39, George, Wes wrote:
> 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 
beh
>  avior, 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: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf
>> Of Howard, Lee
>> Sent: Thursday, September 06, 2012 12:18 PM
>> To: renum@ietf.org
>> 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: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf
>>> Of internet- drafts@ietf.org
>>> Sent: Monday, September 03, 2012 11:38 PM
>>> To: i-d-announce@ietf.org
>>> Cc: renum@ietf.org
>>> 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
>>> renum@ietf.org
>>> https://www.ietf.org/mailman/listinfo/renum
>> Lee Howard
>> Director, Network Technology
>> Time Warner Cable
>> (703) 345-3513
>> 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
>> renum@ietf.org
>> 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.
> _______________________________________________
> renum mailing list
> renum@ietf.org
> https://www.ietf.org/mailman/listinfo/renum
>