Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

"Antonio M. Moreiras" <moreiras@nic.br> Wed, 14 August 2013 01:11 UTC

Return-Path: <moreiras@nic.br>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D81A21E817A for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 18:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q+oiSfaq5tGV for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 18:11:44 -0700 (PDT)
Received: from mail.nic.br (mail.nic.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 62B9D21E808D for <v6ops@ietf.org>; Tue, 13 Aug 2013 18:11:44 -0700 (PDT)
Received: from sarierom-2.local (unknown [177.81.133.204]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.nic.br (Postfix) with ESMTPSA id 761372080145; Tue, 13 Aug 2013 22:11:43 -0300 (BRT)
Message-ID: <520AD94F.1050604@nic.br>
Date: Tue, 13 Aug 2013 22:11:43 -0300
From: "Antonio M. Moreiras" <moreiras@nic.br>
Organization: NIC.br
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: "George, Wes" <wesley.george@twcable.com>
References: <5207D42F.2030302@nic.br> <5207E319.6070601@nic.br> <8C48B86A895913448548E6D15DA7553B97DA03@xmb-rcd-x09.cisco.com> <CA+z-_EWFAGFqyo3E3LzrEhpMRV6axdLJTC50BNwXMNGuJtZuTA@mail.gmail.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABEFA4@PRVPEXVS15.corp.twcable.com> <A84D9405-B3D2-4D55-BAEE-FE25ACE45EB6@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF00C@PRVPEXVS15.corp.twcable.com> <7E5164F5-CB38-49D1-94F5-5125FCD2416E@delong.com> <52095DAF.2050505@nic.br> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF61A@PRVPEXVS15.corp.twcable.com> <4910BB30-FF77-4E69-8B60-E35E5847DB2F@delong.com> <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com>
In-Reply-To: <2671C6CDFBB59E47B64C10B3E0BD59230439ABF936@PRVPEXVS15.corp.twcable.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2013 01:11:45 -0000

On 13/08/13 16:58, George, Wes wrote:

>> The original proposal for a larger doc prefix is all about being able to
>> > write books and training scenarios that use a doc prefix and talk about
>> > carving up larger chunks of address space.

> [WEG] The thing I don't understand about that is how carving x subnet blocks 
> out of a /32 is different from carving x blocks out of a /48 or x blocks out  > of a /20 or whatever you start with as it concerns documentation.
Other than
> the prefix lengths being somewhat longer, the examples of how to subnet, how 
> to configure routing, etc still hold, don't they? AFAICT, as long as you 
> don't end up subnetting below /64, there's really no issue. Yes, real routing 
> policy likely won't pass a bunch of /64s, but for a lab such as what you 
> detailed, and the subtending documentation that should work just fine, no? 
> Especially given that the goal is to teach someone how to do something, 
> instead of simply giving them something to copy with no understanding of 
> what it's doing.

For one of our trainings at NIC.br, each group of students have a small
ISP with two PoPs. We try to follow the recommendations in this BCOP,
for address planing:

http://www.ipbcop.org/wp-content/uploads/2012/02/BCOP-IPv6_Subnetting.pdf

Then, all ISPs in the lab connect to two upstreams for transit, two
IXPs, and do private peering among themselves. We have a serie of
exercises about traffic engineering, that depend on the address plan.

Yes, we could use /48, instead of /32 for each ISP. But doing that, we
could not follow strictly the BCOP recommendations. Yes, we could use a
/32 from ULA space, instead of from GLA space. But we think it would
generate confusion.

I think we are not really talking about impossibilities, but about
options. We are talking about to write documents easier to read, labs
easier to understand.

In some situations, for teaching, or writing scripts for labs, howtos,
books, brochures, etc, it's better, simpler, easier, more precise, more
clear, to use a prefix shorter than /32. In some situations we are doing
that, and we have seen other groups doing the same.

Moreiras.