Subject: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 14 Jun 2018 01:15:48 +0000

The justification presented for the request for a new DHCPv6 option 111 option code for 464XLAT was that an operator would be running multiple IPv4aas mechanisms and needed to express which they preferred a CE router to make use of. The discussion devolved into MAP vs. 464XLAT. The cases being made for 464XLAT vs MAP seemed to me to make a very strong case against deploying multiple mechanisms.

Deploying multiple mechanisms has all the downsides of all the mechanisms. The only positive thing to say is that if the CE router supports one mechanism, but not the other, then the CE router is still ok.

To me, this one positive aspect is such a weak reason, that I would never use it to justify the additional capex, opex, and customer help desk costs. 

Is there some better justification that I'm missing? If there is no good justification for deploying 464XLAT and MAP-T or MAP-E, then why is a DHCPv6 option 111 option code for 464XLAT needed?
Barbara

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 14 Jun 2018 11:37:03 +0900

On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H <[email-masked]> wrote:

> The justification presented for the request for a new DHCPv6 option 111
> option code for 464XLAT was that an operator would be running multiple
> IPv4aas mechanisms and needed to express which they preferred a CE router
> to make use of. The discussion devolved into MAP vs. 464XLAT. The cases
> being made for 464XLAT vs MAP seemed to me to make a very strong case
> against deploying multiple mechanisms.
>
> Deploying multiple mechanisms has all the downsides of all the mechanisms.

Absolutely. Not just the downsides of all of them, but the cost of
implementing all of them, and the increased operational burden of managing
all of them at the same time, and the increased operational burden of
managing the interaction between multiple mechanisms implemented by the
same device.

To me, this one positive aspect is such a weak reason, that I would never
> use it to justify the additional capex, opex, and customer help desk
> costs.

+1.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 08:54:23 +0200

Hi Barbara,

This change in our draft was done to respond to your requirement (and also Richard ones) that an operator moving from "different" scenarios (for example from dual-stack to a "transition-mechanism-1" then to "transition-mechanism-2" or to both of them for different customers) has the control over the CE transition mechanisms, and that can be done not for all the customers, but in groups or whatever.

If all the CE supported transition mechanisms have the same DHCP "way" to be prioritized and that can be used to turn each on/off, we satisfy your requirement. Otherwise we need to take the decision in the document about how to prioritize *all* them, which may be good for us, but may be not the correct way for other operators later on.

We have not changed the requirements to say that all the mechanisms must be supported, but if you support them, the logic way to do so is having the 464XLAT option, which is the only one missing (because RFC8026 was develop considering only the softwires WG mechanisms, and 464XLAT was done in v6ops).

I still believe that it is a decision of each operator to support one or several transition mechanisms and which ones, but we need to have a CE that can accommodate that in a managed way, and that's why RFC8026 was done.

Regards,

Jordi

-----Mensaje original-----

De: v6ops <[email-masked]> en nombre de "STARK, BARBARA H" <[email-masked]>

Fecha: jueves, 14 de junio de 2018, 3:16

Para: "[email-masked] WG" <[email-masked]>

Asunto: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT

    Barbara

    _______________________________________________

    v6ops mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.

---

From: Lencse Gábor <[email-masked]>
Date: Thu, 14 Jun 2018 09:21:24 +0200

I must disagree with this reasoning.

First of all, having the option does not mandate any ISP to use multiple 
transition mechanisms.

However, there may be situations, when multiple transition mechanisms 
are being used. Let me give you just two simple examples.

1. An ISP decides to change from one mechanism to another. (As we have 
just seen, 464XLAT, MAP-T and MAP-E have different advantages and 
drawback, thus this can be a rational decision.) The change may last for 
a while. (E.g. the new subscribers get the new technology and the old 
subscribers are moved in one year time frame.) Therefore the two 
mechanisms must coexist in the network of the ISP.

2. An ISP buys up another one and the two networks use two different 
mechanisms for providing IPv4 as a service. As both infrastructures are 
ready, it may be a rational decision to keep up both and move some users 
between them. (E.g. move MAP users, who complained about lack of port 
situation, to 464XLAT.)

So, IMHO, it is useful to have the option to choose among the different 
mechanisms.

Best regard,

Gábor Lencse

On 6/14/2018 4:37 AM, Lorenzo Colitti wrote:
> On Thu, Jun 14, 2018 at 10:16 AM STARK, BARBARA H <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     The justification presented for the request for a new DHCPv6
>     option 111 option code for 464XLAT was that an operator would be
>     running multiple IPv4aas mechanisms and needed to express which
>     they preferred a CE router to make use of.. The discussion
>     devolved into MAP vs. 464XLAT. The cases being made for 464XLAT vs
>     MAP seemed to me to make a very strong case against deploying
>     multiple mechanisms.
>
> implementing all of them, and the increased operational burden of 
> managing all of them at the same time, and the increased operational 
> burden of managing the interaction between multiple mechanisms 
> implemented by the same device.
>
>     To me, this one positive aspect is such a weak reason, that I
>     would never use it to justify the additional capex, opex, and
>     customer help desk costs. 
>
>
> +1.
>
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2018 09:28:41 +0200

There may be one *very common* more reason as well.

The ISP has a group of customers with CEs that only support one mechanism, which is different to the (actually) preferred transition mechanism, and the ISP don’t want to replace those CEs, or not immediately.

This was the main rational used in RFC8026:

“A common feature shared among all of the differing modes is the
   integration of softwire tunnel endpoint functionality into the

   Customer Premises Equipment (CPE) router.  Due to this inherent data

   plane similarity, a single CPE may be capable of supporting several

   different approaches.  Users may also wish to configure a specific

   mode of operation.

   A service provider's network may also have more than one S46

   mechanism enabled in order to support a diverse CPE population with

   differing client functionality, such as during a migration between

   mechanisms or where services require specific supporting softwire

   architectures.”

Regards,

Jordi

De: v6ops <[email-masked]> en nombre de Lencse Gábor <[email-masked]>
Fecha: jueves, 14 de junio de 2018, 9:22
Para: <[email-masked]>
Asunto: Re: [v6ops] MAP vs 464XLAT and request to updating RFC8026 to support 464XLAT

First of all, having the option does not mandate any ISP to use multiple transition mechanisms.

However, there may be situations, when multiple transition mechanisms are being used. Let me give you just two simple examples.

1. An ISP decides to change from one mechanism to another. (As we have just seen, 464XLAT, MAP-T and MAP-E have different advantages and drawback, thus this can be a rational decision.) The change may last for a while. (E.g. the new subscribers get the new technology and the old subscribers are moved in one year time frame.) Therefore the two mechanisms must coexist in the network of the ISP.

2. An ISP buys up another one and the two networks use two different mechanisms for providing IPv4 as a service. As both infrastructures are ready, it may be a rational decision to keep up both and move some users between them. (E.g. move MAP users, who complained about lack of port situation, to 464XLAT.)

So, IMHO, it is useful to have the option to choose among the different mechanisms.

Best regard,

Gábor Lencse

The justification presented for the request for a new DHCPv6 option 111 option code for 464XLAT was that an operator would be running multiple IPv4aas mechanisms and needed to express which they preferred a CE router to make use of.. The discussion devolved into MAP vs. 464XLAT. The cases being made for 464XLAT vs MAP seemed to me to make a very strong case against deploying multiple mechanisms.

Absolutely. Not just the downsides of all of them, but the cost of implementing all of them, and the increased operational burden of managing all of them at the same time, and the increased operational burden of managing the interaction between multiple mechanisms implemented by the same device.

+1. 

_______________________________________________ v6ops mailing list [email-masked] https://www.ietf.org/mailman/listinfo/v6ops