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

From: Alexandre Petrescu <[email-masked]>
Date: Mon, 2 Nov 2015 19:02:58 +0900

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.

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

Alex

---

From: Philip Matthews <[email-masked]>
Date: Mon, 2 Nov 2015 19:52:47 +0900

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.
> 
> This (maintain IPv4 ok while migrating) is the most important requirement in the networks I work.
> 
> Alex
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: joel jaeggli <[email-masked]>
Date: Tue, 3 Nov 2015 06:51:27 +0900

On 11/2/15 7:52 PM, Philip Matthews wrote:
>> With respect to the design-choices draft, I think it is worth to
>> mention in the discussion that backwards compatibility is a 'pro' when

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

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

>> [email-masked] <mailto:[email-masked]>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 11:26:54 +1300

On 03/11/2015 10:51, joel jaeggli wrote:

...
> but  support of your existing model while building the new is incremental.

It seems to me that *this* draft should simply state that there are
two main options for service continuity for IPv4 applications (dual
stack or IPv4 as a service) but this is out of scope for the current
document. Otherwise the draft will get bogged down for months.

    Brian

---

From: Philip Matthews <[email-masked]>
Date: Tue, 3 Nov 2015 09:06:47 +0900

The draft is explicitly about IPv6-only and dual-stack networks, and it seems to me that even mentioning IPv4-as-a-service is not really necessary. 
- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 13:46:05 +1300

> The draft is explicitly about IPv6-only and dual-stack networks, and it seems to me that even mentioning IPv4-as-a-service is not really necessary.

I don't feel strongly about this.

   Brian