Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09

joel jaeggli <joelja@bogus.com> Mon, 02 November 2015 21:51 UTC

Return-Path: <joelja@bogus.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ACC51A8833 for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 13:51:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zp5bTcJ004pW for <v6ops@ietfa.amsl.com>; Mon, 2 Nov 2015 13:51:35 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 343E01A882D for <v6ops@ietf.org>; Mon, 2 Nov 2015 13:51:35 -0800 (PST)
Received: from mb-2.local (122x210x83x163.ap122.ftth.ucom.ne.jp [122.210.83.163]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id tA2LpWJJ077966 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 2 Nov 2015 21:51:33 GMT (envelope-from joelja@bogus.com)
To: Philip Matthews <philip_matthews@magma.ca>, Alexandre Petrescu <alexandre.petrescu@gmail.com>
References: <563734D2.2@gmail.com> <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca>
From: joel jaeggli <joelja@bogus.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <5637DADF.8090308@bogus.com>
Date: Tue, 03 Nov 2015 06:51:27 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Thunderbird/42.0
MIME-Version: 1.0
In-Reply-To: <01D87BBE-112A-4F40-9F1B-2272B2471457@magma.ca>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="7AMXVmbJRB4aNFH5KtlaqTTvw2lBXS06V"
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/lK3AMOE12an47aflbV2yFqbSV-M>
Cc: "v6ops@ietf.org" <v6ops@ietf.org>
Subject: Re: [v6ops] Comment on draft-ietf-v6ops-design-choices-09
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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, 02 Nov 2015 21:51:36 -0000

On 11/2/15 7:52 PM, Philip Matthews wrote:
> Can you explain a bit more what you mean by that?  
> - Philip
> 
> 
> On 2015-11-02, at 19:02 , Alexandre Petrescu wrote:
> 
>> Hello,
>>
>> With respect to the design-choices draft, I think it is worth to
>> mention in the discussion that backwards compatibility is a 'pro' when
>> considering PA/PI/ULA schemes for enterprise networks.  It is not a
>> drawback.

I'm not sure what is meant by backwards compatibility, there isn't any
with respect to the ipv6 elements of the deployment.

>> This (maintain IPv4 ok while migrating) is the most important
>> requirement in the networks I work.

dual stack  deployment is a common operating modality and has been for a
rather long time. there's definitely a tax to be payed with respect to
resource usage, and complexity that doesn't exist in a v6 only network,
but  support of your existing model while building the new is incremental.

>> Alex
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org <mailto:v6ops@ietf.org>
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 
> _______________________________________________
> v6ops mailing list
> v6ops@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
>