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

Benoit Claise <bclaise@cisco.com> Tue, 11 December 2012 17:24 UTC

Return-Path: <bclaise@cisco.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 3F40B21F850D for <renum@ietfa.amsl.com>; Tue, 11 Dec 2012 09:24:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.023
X-Spam-Level:
X-Spam-Status: No, score=-10.023 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-8]
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 DesTXspHzzu0 for <renum@ietfa.amsl.com>; Tue, 11 Dec 2012 09:24:13 -0800 (PST)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id 406D321F84CD for <renum@ietf.org>; Tue, 11 Dec 2012 09:24:13 -0800 (PST)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBBHOAit016871; Tue, 11 Dec 2012 18:24:10 +0100 (CET)
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by strange-brew.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id qBBHO8fs028797; Tue, 11 Dec 2012 18:24:09 +0100 (CET)
Message-ID: <50C76C38.9000103@cisco.com>
Date: Tue, 11 Dec 2012 18:24:08 +0100
From: Benoit Claise <bclaise@cisco.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: renum@ietf.org
References: <50C73F18.5000408@cisco.com>
In-Reply-To: <50C73F18.5000408@cisco.com>
X-Forwarded-Message-Id: <50C73F18.5000408@cisco.com>
Content-Type: multipart/alternative; boundary="------------070901080709000007030302"
Subject: [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: Tue, 11 Dec 2012 17:24:14 -0000

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