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

"Alejandro Acosta" <alejandroacostaalamo@gmail.com> Mon, 12 August 2013 21:25 UTC

Return-Path: <alejandroacostaalamo@gmail.com>
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 37FD621F992B for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 14:25:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.2
X-Spam-Level:
X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 oVqTwp5k0L6d for <v6ops@ietfa.amsl.com>; Mon, 12 Aug 2013 14:25:36 -0700 (PDT)
Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6E64021F90A7 for <v6ops@ietf.org>; Mon, 12 Aug 2013 14:25:35 -0700 (PDT)
Received: by mail-ee0-f53.google.com with SMTP id b15so3827876eek.12 for <v6ops@ietf.org>; Mon, 12 Aug 2013 14:25:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:subject:to:cc:reply-to:mime-version :content-type:content-transfer-encoding; bh=PY3DQezypCyKWeZqAYnoRKdmLcdKNKXBnNFoQMPNhdc=; b=i6y+LKgldjewwV6eo3ib0AEZxonRV9KKZGRvdDyq2NUyf+QBhJ8XnKKOFXcjiXaDL4 fE3Zz51+5Efxe0vqeT9BVoKTlft0eQVvilZSgKOeKhK1no2s7AmPRij2tJR6ldf9QzH2 CmbN/hy4lDS01fxPaKYJaS8MIMtVVkUAp+vVwDmvCDZZTey0VkfTqxoqx4NbaNQ+KkGr BvwhdnMPV06HtIrFX0wLyo+bWwcFvGr2kctikvT09Nqvr3mqM/VxLEX4/Cgd/rmnfJfW O8zzTC1WMn5d5VGviZOz+5uY1zbOKXuSo2U3o0gzTkCkQeXcnPe7cCz9O6GbjTk9aBKF ordg==
X-Received: by 10.14.214.136 with SMTP id c8mr1219741eep.6.1376342734513; Mon, 12 Aug 2013 14:25:34 -0700 (PDT)
Received: from lhrnms-0059-fe.pr.nmsg.s.nokia.com (em1x-25.lhr.messaging.nokia.com. [131.228.18.25]) by mx.google.com with ESMTPSA id k3sm60789252een.16.2013.08.12.14.25.33 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 12 Aug 2013 14:25:33 -0700 (PDT)
Message-ID: <520952cd.83c10e0a.2f50.6638@mx.google.com>
Date: Mon, 12 Aug 2013 21:25:25 +0000
From: "Alejandro Acosta" <alejandroacostaalamo@gmail.com>
To: "Fred Baker (fred)" <fred@cisco.com> , "Owen DeLong" <owen@delong.com>
MIME-Version: 1.0
X-Priority: 3
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Cc: Alejandro Acosta <aacosta@rocketmail.com>, "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
Reply-To: alejandroacostaalamo@gmail.com
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: Mon, 12 Aug 2013 21:25:44 -0000

Hi Owen, thanks a lot for your example.
I'm going to mention one more case:

Recently I had to write a document explaining an IPv6 address plan, one part of the document consisted in an example of multi regional ISP. In those cases the ISP generally receives blocks larger than /32 from the RIR.  I could not use the current 2001:db8::/32 and unfortunately I had to write the examples using other prefixes.

Thanks a lot,


-----Mensaje original-----
De: Owen DeLong
Enviados:  08/12/2013 2:01:18 PM
Para: Fred Baker (fred)
Cc: Alejandro Acosta; <v6ops@ietf.org>
Asunto:  Re: [v6ops] draft-moreiras-v6ops-rfc3849bis-00

If you are trying to demonstrate or teach peerings across multiple ASNs and show examples of how multiple ISPs might carve up their /32s (or larger) differently, it's very hard to do all of that within a single /32.

Antonio and I do very similar types of training from the sounds of it and we have encountered the same issues.

A larger doc prefix would be useful. I don't see it as critical, but I don't see any significant reason not to do so. I understand the objection raised by Cameron, but, really, anything the IETF does likely creates some amount of work for operators. Thus is the nature of operating a network built on an evolving technology. You knew the job was dangerous when you took it.

Owen

On Aug 12, 2013, at 10:17 , "Fred Baker (fred)" <fred@cisco.com> wrote:

> Speaking as a chair, I don't have a problem with it being discussed in v6ops, but I think the issue belongs in 6man by charter.
> 
> Speaking as a document author (think of RFCs 6052, 6144, 6145, 6146, and 6147, which I helped edit or write), I'm not sure I have ever had a case in which a /32 was not enough. I might, for example, need to use layers of prefixes like
>    2001:db8::/32
>    2001:db8:100::/40
>    2001:db8:202::/48
>    2001:db8:300:300::/56
>    2001:db8:400:440::/60
>    2001:db8:400:444::/64
> but I seem to have plenty of layers at my disposal. I'd be interested to understand the cases in which you find yourself cramped?
> 
> On Aug 11, 2013, at 12:16 PM, Antonio M. Moreiras <moreiras@nic.br> wrote:
> 
>> Hi.
>> 
>> I would like to ask you to please review and comment the following draft:
>> 
>> http://tools.ietf.org/html/draft-moreiras-v6ops-rfc3849bis-00
>> 
>> It intends to ask IANA to reserve another IPv6 prefix for documentation.
>> Something larger than the 2001:db8::/32, reserved by APNIC 10 years ago.
>> 
>> The prefix 2001:db8::/32 showed to be very useful. It is widely used.
>> But we are still facing the same problem that RFC 3849 tried to address:
>> in some kind of documents, tutorials and didactic laboratories, we have
>> been using other prefixes, because a /32 isn't enough to represent the
>> scenario.
>> 
>> We consider that a /20 would be enough.
>> 
>> If possible, we would like to ask IANA to reserve something easy to
>> remember, and self explaining, such as:
>> 
>> 2D0C::/20
>> 
>> but *this suggestion is not stated in the document*. This prefix is from
>> the global unicast space, and 2d00::/8 is currently marked as reserved
>> by IANA [1], so it would be possible. Anyway, we think it would be
>> better to discuss the question in the mailing-list.
>> 
>> Reviewing the archives from when draft-huston-ipv6-documentation-prefix
>> (that became RFC 3849) was being discussed, both questions (the
>> necessity of a larger prefix, or multiple prefixes, and the possibility
>> to reserve something easier to remember and self explaining) were
>> raised. I am not sure why none of them led to something concrete.
>> Probably because the draft just intended to document an allocation
>> already made by APNIC, and maybe it was not so clear then how useful it
>> would be.
>> 
>> If you agree in principle with the proposal, other point to discuss is
>> if this subject is compatible with v6ops. Maybe it should be addressed
>> in 6man, or other place.
>> 
>> Thanks.
>> Moreiras.
>> 
>> [1]
>> http://www.iana.org/assignments/ipv6-unicast-address-assignments/ipv6-unicast-address-assignments.xhtml
>> 
>> 
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops

_______________________________________________
v6ops mailing list
v6ops@ietf.org
https://www.ietf.org/mailman/listinfo/v6ops