Re: [renum] An observation on 'draft-jiang-6renum-enterprise-00.txt'
"Templin, Fred L" <Fred.L.Templin@boeing.com> Wed, 13 July 2011 22:41 UTC
Return-Path: <Fred.L.Templin@boeing.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 5192011E8075 for <renum@ietfa.amsl.com>; Wed, 13 Jul 2011 15:41:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.17
X-Spam-Level:
X-Spam-Status: No, score=-6.17 tagged_above=-999 required=5 tests=[AWL=-0.171, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
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 fLrGoIUlWBRd for <renum@ietfa.amsl.com>; Wed, 13 Jul 2011 15:41:25 -0700 (PDT)
Received: from slb-smtpout-01.boeing.com (slb-smtpout-01.boeing.com [130.76.64.48]) by ietfa.amsl.com (Postfix) with ESMTP id ACB0E21F8B4F for <renum@ietf.org>; Wed, 13 Jul 2011 15:41:25 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id p6DMfItX029368 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Jul 2011 15:41:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with SMTP id p6DMfHIA025350; Wed, 13 Jul 2011 15:41:17 -0700 (PDT)
Received: from XCH-NWHT-02.nw.nos.boeing.com (xch-nwht-02.nw.nos.boeing.com [130.247.70.248]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id p6DMfDqI025225 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Wed, 13 Jul 2011 15:41:13 -0700 (PDT)
Received: from XCH-NW-01V.nw.nos.boeing.com ([130.247.64.120]) by XCH-NWHT-02.nw.nos.boeing.com ([130.247.70.248]) with mapi; Wed, 13 Jul 2011 15:41:13 -0700
From: "Templin, Fred L" <Fred.L.Templin@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Date: Wed, 13 Jul 2011 15:41:12 -0700
Thread-Topic: An observation on 'draft-jiang-6renum-enterprise-00.txt'
Thread-Index: AcxBpU1cPoo8Ul5VRXy/tLJrngApYAAB50xQ
Message-ID: <E1829B60731D1740BB7A0626B4FAF0A65C6B37F268@XCH-NW-01V.nw.nos.boeing.com>
References: <E1829B60731D1740BB7A0626B4FAF0A65C6B37F0D7@XCH-NW-01V.nw.nos.boeing.com> <4E1E1076.6060703@gmail.com>
In-Reply-To: <4E1E1076.6060703@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 13 Jul 2011 22:41:26 -0000
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 > > > > >
- [renum] An observation on 'draft-jiang-6renum-ent… Templin, Fred L
- Re: [renum] An observation on 'draft-jiang-6renum… Brian E Carpenter
- Re: [renum] An observation on 'draft-jiang-6renum… Templin, Fred L
- Re: [renum] An observation on 'draft-jiang-6renum… Jiangsheng