Re: [renum] An observation on 'draft-jiang-6renum-enterprise-00.txt'

Jiangsheng <jiangsheng@huawei.com> Thu, 14 July 2011 02:23 UTC

Return-Path: <jiangsheng@huawei.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 B5FC311E80B4 for <renum@ietfa.amsl.com>; Wed, 13 Jul 2011 19:23:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.41
X-Spam-Level:
X-Spam-Status: No, score=-3.41 tagged_above=-999 required=5 tests=[AWL=-1.411, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 bMVIPQ6ct9EB for <renum@ietfa.amsl.com>; Wed, 13 Jul 2011 19:23:06 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id CEC1611E8089 for <renum@ietf.org>; Wed, 13 Jul 2011 19:23:05 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00EFJX7LGX@szxga05-in.huawei.com> for renum@ietf.org; Thu, 14 Jul 2011 10:21:21 +0800 (CST)
Received: from szxrg02-dlp.huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LOA00GE0X7C4V@szxga05-in.huawei.com> for renum@ietf.org; Thu, 14 Jul 2011 10:21:21 +0800 (CST)
Received: from 172.24.2.119 (EHLO szxeml203-edg.china.huawei.com) ([172.24.2.119]) by szxrg02-dlp.huawei.com (MOS 4.1.9-GA FastPath queued) with ESMTP id ACE89740; Thu, 14 Jul 2011 10:21:19 +0800 (CST)
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by szxeml203-edg.china.huawei.com (172.24.2.55) with Microsoft SMTP Server (TLS) id 14.1.270.1; Thu, 14 Jul 2011 10:21:14 +0800
Received: from SZXEML506-MBX.china.huawei.com ([169.254.4.221]) by szxeml412-hub.china.huawei.com ([169.254.226.192]) with mapi id 14.01.0270.001; Thu, 14 Jul 2011 10:21:17 +0800
Date: Thu, 14 Jul 2011 02:21:14 +0000
From: Jiangsheng <jiangsheng@huawei.com>
In-reply-to: <E1829B60731D1740BB7A0626B4FAF0A65C6B37F268@XCH-NW-01V.nw.nos.boeing.com>
X-Originating-IP: [10.110.98.101]
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-id: <5D36713D8A4E7348A7E10DF7437A4B920121587C@SZXEML506-MBX.china.huawei.com>
MIME-version: 1.0
Content-type: text/plain; charset="us-ascii"
Content-language: zh-CN
Content-transfer-encoding: 7bit
Accept-Language: en-GB, zh-CN, en-US
Thread-topic: An observation on 'draft-jiang-6renum-enterprise-00.txt'
Thread-index: AcxBdXERdFTyM40XSrSml9Cw9XU+jgAEEyswAABfxxD//7X5AIAAEV8A//9AxoA=
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
X-CFilter-Loop: Reflected
References: <E1829B60731D1740BB7A0626B4FAF0A65C6B37F0D7@XCH-NW-01V.nw.nos.boeing.com> <4E1E1076.6060703@gmail.com> <E1829B60731D1740BB7A0626B4FAF0A65C6B37F268@XCH-NW-01V.nw.nos.boeing.com>
Cc: "renum@ietf.org" <renum@ietf.org>
Subject: Re: [renum] An observation on 'draft-jiang-6renum-enterprise-00.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: Thu, 14 Jul 2011 02:23:06 -0000

Hi, Templin,

So far, in this version of our drafts, we do not distinguish the different reasons of changing prefix. So, your mentioned "changing from an IPv6 prefix 'A' assigned to a coexistence mechanism to a different IPv6 prefix 'B' assigned to that same coexistence mechanism" is already included. But we sort it in different dimension.

Regards,

Sheng

> -----Original Message-----
> From: Templin, Fred L [mailto:Fred.L.Templin@boeing.com]
> Sent: Thursday, July 14, 2011 6:41 AM
> To: Brian E Carpenter
> Cc: renum@ietf.org; Jiangsheng; Leo Liu(bing)
> Subject: RE: An observation on 'draft-jiang-6renum-enterprise-00.txt'
> 
> Hi Brian,
> 
> > -----Original Message-----
> > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com]
> > Sent: Wednesday, July 13, 2011 2:39 PM
> > To: Templin, Fred L
> > Cc: renum@ietf.org; jiangsheng@huawei.com; leo.liubing@huawei.com
> > Subject: Re: An observation on 'draft-jiang-6renum-enterprise-00.txt'
> >
> > Fred,
> >
> > It's mentioned in RFC 5887 that one trigger for IPv6 renumbering
> could
> > be migrating from a transitional IPv6 solution to true native IPv6.
> 
> OK. But, renumbering could also include changing from an
> IPv6 prefix 'A' assigned to a coexistence mechanism to a
> different IPv6 prefix 'B' assigned to that same coexistence
> mechanism (i.e., it does not need to entail a migration
> from coexistence to native).
> 
> > In that sense, coexistence mechanisms are (IMHO) in the scope of the
> > 6renum charter, but I think it's limited to that; IPv4 is out of
> scope
> > unless "analysis leads to conclusions that are also
> > applicable to IPv4."
> 
> If by that, you mean that IPv4 renumbering is out of
> scope unless ..., then I am fine with that. My concern
> is for IPv6 renumbering.
> 
> > Of course, this applies to all coexistence mechanisms, not
> > just ISATAP.
> 
> I mention ISATAP only within the context of enterprise
> networks, which is the domain of analysis of the document
> in question.
> 
> > I agree that mentioning renumbering from a coexistence solution to
> > a native solution is reasonable, as it may lead to specific items in
> > the gap analysis.
> 
> Should also include changing from IPv6 prefix 'A' to
> IPv6 prefix 'B' while not changing from coexistence
> to native.
> 
> Thanks - Fred
> fred.l.templin@boeing.com
> 
> > Regards
> >    Brian
> >
> > On 2011-07-14 06:13, Templin, Fred L wrote:
> > >
> > > [[ Re-sending - previous attempt was truncated ]]
> > >
> > > Authors,
> > >
> > > In Section 1 of this document, we see:
> > >
> > >   "This document focuses on IPv6 only, by leaving IPv4
> > >    out of scope. Dual-stack network or IPv4/IPv6
> > >    transition scenarios are out of scope, too."
> > >
> > > This statement seem to me to be dodging a very
> > > important phase in the transition of existing IPv4
> > > enterprise networks into IPv6 supporting enterprises.
> > > Indeed, the document fails to cite the two v6ops
> > > publications on Enterprise network IPv6 considerations,
> > > namely "IPv6 Enterprise Network Scenarios" [RFC4057]
> > > and "IPv6 Enterprise Network Analysis - IP Layer 3
> > > Focus" [RFC4852]". These documents clearly show a
> > > need to account for a mixed IPv4/IPv6 environment
> > > for some time to come.
> > >
> > > Also, in Section 2 of your document:
> > >
> > >   "The complicated IPv4/IPv6 co-existing scenarios are
> > >    out of scope."
> > >
> > > In the case of ISATAP [RFC5214] at least, I disagree
> > > with the characterization of "complicated". Indeed,
> > > using ISATAP, an entire enterprise network can be
> > > automatically renumbered by touching only the site
> > > bordering ISATAP routers when their ISP delegated
> > > prefixes from the ISP change. As far as I can tell,
> > > such would represent possibly the simplest of all
> > > renumbering scenarios. Note also that operational
> > > guidance for IPv6 deployment in IPv4 sites using
> > > is now beind documented in 'draft-templin-v6ops-isops',
> > > which could also be cited by your document.
> > >
> > > Please check these works, and consider citing the
> > > appropriate documents. Please also note that ISATAP
> > > provides a ready-made simple solution for enterprise
> > > network renumbering, which could also be mentioned
> > > in your document.
> > >
> > > Thanks - Fred
> > > fred.l.templin@boeing.com
> > >
> > >
> >