Re: [renum] draft-ietf-6renum-enterprise: review

Sheng Jiang <jiangsheng@huawei.com> Wed, 12 December 2012 08:56 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 2B7BF21F8951 for <renum@ietfa.amsl.com>; Wed, 12 Dec 2012 00:56:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.264
X-Spam-Level:
X-Spam-Status: No, score=-6.264 tagged_above=-999 required=5 tests=[AWL=-0.266, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=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 BEdn5FhOfqmH for <renum@ietfa.amsl.com>; Wed, 12 Dec 2012 00:56:04 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3005421F894E for <renum@ietf.org>; Wed, 12 Dec 2012 00:56:03 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AMK37325; Wed, 12 Dec 2012 08:56:02 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 08:55:11 +0000
Received: from SZXEML413-HUB.china.huawei.com (10.82.67.152) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 16:56:00 +0800
Received: from SZXEML545-MBS.china.huawei.com ([169.254.2.174]) by szxeml413-hub.china.huawei.com ([10.82.67.152]) with mapi id 14.01.0323.003; Wed, 12 Dec 2012 16:55:50 +0800
From: Sheng Jiang <jiangsheng@huawei.com>
To: Ronald Bonica <rbonica@juniper.net>, Benoit Claise <bclaise@cisco.com>, "renum@ietf.org" <renum@ietf.org>
Thread-Topic: draft-ietf-6renum-enterprise: review
Thread-Index: AQHN18iivnxTqWIYdEaNunfic33G3JgU17CA
Date: Wed, 12 Dec 2012 08:55:49 +0000
Message-ID: <5D36713D8A4E7348A7E10DF7437A4B9239FD4003@szxeml545-mbs.china.huawei.com>
References: <50C73F18.5000408@cisco.com> <50C76C38.9000103@cisco.com> <2CF4CB03E2AA464BA0982EC92A02CE2501DCE108@BY2PRD0512MB653.namprd05.prod.outlook.com>
In-Reply-To: <2CF4CB03E2AA464BA0982EC92A02CE2501DCE108@BY2PRD0512MB653.namprd05.prod.outlook.com>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.111.98.140]
Content-Type: multipart/alternative; boundary="_000_5D36713D8A4E7348A7E10DF7437A4B9239FD4003szxeml545mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [renum] draft-ietf-6renum-enterprise: review
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, 12 Dec 2012 08:56:05 -0000

Hi, Benoit & Ron,

It was the conclusion from the WG was fairly clear that we were not really making any normative recommendations. But we probably need a new version anyway for clarifications, based on the other reviews.

For overlapping, yes, there are many document mentioned renumbering, only because it is a common issue. Different from other documents that mention renumbering as a minor relevant consideration, the 6renum-enterprise is dedicated for renumbering issue. It focuses on enterprise scenarios and makes a comprehensive analysis, which is not provided by the other documents.

BTW, Benoit’s editorial comments has been fixed in the ongoing version.

Best regards,

Sheng, Bing, Brain

From: renum-bounces@ietf.org [mailto:renum-bounces@ietf.org] On Behalf Of Ronald Bonica
Sent: Wednesday, December 12, 2012 1:54 AM
To: Benoit Claise; renum@ietf.org
Subject: Re: [renum] draft-ietf-6renum-enterprise: review

Folks,

Because the document attracted similar comments from another AD, I have removed the document from Thursday’s telechat so that the WG could take whatever time it needed to discuss the matter.

If we decided to move forward with this document, as is, I will put it back on the next telechat agenda.

Authors, could I ask you to respond to Benoit?

                                              Ron


From: Benoit Claise [mailto:bclaise@cisco.com]
Sent: Tuesday, December 11, 2012 12:24 PM
To: renum@ietf.org
Cc: Ronald Bonica
Subject: draft-ietf-6renum-enterprise: review

Dear all,

I've been reviewing draft-ietf-6renum-enterprise

I have a concern with this document. Not really an objection in the form of a DISCUSS, but ...
From the charter, I believe that this document fits the following:
1. To undertake scenario descriptions, including documentation of
current capability inventories and existing BCPs, for enterprise
networks, including managed and unmanaged elements. These texts should
contribute towards a gap analysis and provide an agreed basis for
subsequent WG rechartering towards development of solutions (which may
be more appropriate for other WGs to undertake) and improved practices.
Operator input will be of high value for this text.
Reading this reading, I asked myself: what is the specific scope of this document? I see a mix of scenarios, listing of the existing solutions, best current practices, etc... and I'm wondering where this document fits in all the IPv6 documents renumbering documents: RFC 5887, this document, Enterprise IPv6 Deployment Guidelines draft-ietf-v6ops-enterprise-incremental-ipv6-01, rfc4192, etc...
By "etc", I mean searching for "renum" in https://www.ietf.org/download/rfc-index.txt.
It seems that many of these documents have the same type of content. Too many actually. Don't get me wrong, there is good text in this document.

Bottom line: if someone is interested in renumbering, what is the ordered list of documents to be read, with the respective content. My conclusion is that there will be a lot of overlap. I would happy to stand corrected.

Btw, this document title mentions "guidelines", while BCP is mentioned all over.

Note: I did my home trying to find the answer: read RFC 5887, listened to the IETF 85 meeting recording, etc...


- A side note!question, and I'm not sure it has to be addressed by this draft, but one day, I would like to find an answer.
How does a NMS do a discovery of a pure IPv6 network? With something better than ping sweep obviously...


Editorial
1.
Section 1, paragraph 1

   PI space is not always available

   for enterprises Therefore, it is desirable to develop mechanisms that

   simplify IPv6 renumbering.
Missing a "."

2.
Section 1, paragraph 1

   However, widespread use of PI might

   create serious BGP4 scaling problems
A reference, or a small explanation, would be welcome

Regards, Benoit