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

"Antonio M. Moreiras" <moreiras@nic.br> Wed, 14 August 2013 04:08 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 9DADD21E8095 for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 21:08:10 -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 x5SoBCB-VewQ for <v6ops@ietfa.amsl.com>; Tue, 13 Aug 2013 21:08:09 -0700 (PDT)
Received: from mail.nic.br (mail.cgi.br [IPv6:2001:12ff:0:4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 44A5011E8116 for <v6ops@ietf.org>; Tue, 13 Aug 2013 21:08:08 -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 82EFA2080196; Wed, 14 Aug 2013 01:07:57 -0300 (BRT)
Message-ID: <520B029C.3010308@nic.br>
Date: Wed, 14 Aug 2013 01:07:56 -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: Mark ZZZ Smith <markzzzsmith@yahoo.com.au>
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> <520AD94F.1050604@nic.br> <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.com>
In-Reply-To: <1376445275.5223.YahooMailNeo@web142501.mail.bf1.yahoo.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 04:08:13 -0000

On 13/08/13 22:54, Mark ZZZ Smith wrote:
> ----- Original Message -----
>> 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.
> 
> ISPs don't just get a /32, they can get larger if they need it. Placing too much value on using a /32 in your examples can strongly imply that all IPv6 addressing plans must fit within a /32.

We are the NIR in our country, we are aware of that. But the vast
majority of our allocations are indeed /32. The BCOP are also aware of
that, and if we want a experiment where we can follow strictly its
recommendations, then we need a /32 or something shorter.

> The trouble is that if you are too prescriptive, it then creates opportunities for people to be lazy in their learning. They rote learn rather than understand, and that means they may not be able to cope with the situation is even the slightest bit different. 
> 
> I think teaching people to subnet using a range of bits should be taught first, so that they can work with a range allocations. Whether it is a /32, a /48 or a /29 then doesn't matter. Then give examples of how to apply those techniques to various sized IPv6 prefixes to re-enforce the methods.

My team have been working with IPv6 trainings for 4 years. We trained
more than 3000 people, from hundreds of ISPs, in a 36h (1 week) hands on
course during this time, 32 people in each class. We tried a lot of
different approaches in these years. I don't want to appear rude, or
smug. I am just trying to demonstrate that we do have some experience in
this task, and that we know our specific public. I can't say you are
wrong. Your suggestions are good. Things can be done the way you are
proposing. But we would prefer, for now and based on our previous
experience, to do them the way I described before.

I would like also to stress the point that we are not the only group
working with IPv6 learning, using prefixes other than 2001:db8::/32 in
labs and documents.

>> 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.