Subject: [Softwires] Is there any intest in re-visiting the Unified CPE Problem?

From: <[email-masked]>
Date: Wed, 20 Aug 2014 14:20:16 +0200

Hi,

At the last Softwire meeting in Toronto, I presented a question around whether the expired Unified CPE draft needs to be brought back to life (http://www.ietf.org/archive/id/draft-ietf-softwire-unified-cpe-01.txt). There was little support for this during the meeting, so I'm taking it to the list to gauge if there's wider interest in this problem.

Currently in our network we are facing some of the problems that the Unified CPE intended to solve. Specifically, we will have DS-Lite, lw4o6 and public 4over6 in the operator network. The deployed HGWs may support DS-Lite only (RFC6204 compliant 'off-the-shelf' CPEs) or may be capable of all three. A individual HGW may also need to use different mechanisms at different points in its lifecycle (e.g. lw4o6 initially, but public 4over6 if the customer is located a full IPv4 address to use with non A+P compatible L4 protocols)

So, my questions here are whether there are other operators (or vendors) that see problems of this type in their networks, and is there enough interest to open up the unified CPE problem again?

Thanks,
Ian

---

From: [email-masked]
Date: Thu, 21 Aug 2014 15:14:04 +0800

Hi，Ian

 Since multiple IPv6 transitions technologies have been deployed in 
current network. It seems 
urgent to have a standard draft providing a unified mechanism to integrate 
these 
scenarioes in a network with unifed cpe(s) and unifed network gateway(s), 
as well as unified 
provisioning mechanism.

 I guess it would be better advanced if some problems listed below can be 
better addressed:

 1. whether it would be better to expand the IPv4-in-IPv6 softwire to all 
softwires including 
    IPv4-in-IPv6 tunnel、IPv6-in-IPv4 tunnel and translation mechanism. 
Because no matter 
    encapsulation or decapsulation or translation are all basic funtions 
for cpe(s).It seems 
    kind of limited if this draft is only restricted to IPv4-in-IPv6 
softwire.

 2. It seems better to notify directly the role of the unified 
cpe(s):whether this cpe is a B4
    or a lwB4 or a MAP-E CE or a MAP-T CE, through a DHCP option or 
TR-069. Because it seems
    kind of complicated for the unifed cpe to ascertain what role it is.

After all, only reviving it, then we can complete it in a better fashion.

BRs,
Linda Wang

"Softwires" <[email-masked]> 写于 2014-08-20 20:20:16:

> <[email-masked]> 
> 发件人:  "Softwires" <[email-masked]>
> 
> 2014-08-20 20:20
> 
> 收件人
> 
> <[email-masked]>, 
> 
> 抄送
> 
> [email-masked]
> 
> 主题
> 
> [Softwires] Is there any intest in re-visiting the Unified CPE Problem?
> 
> Hi,
> 
> At the last Softwire meeting in Toronto, I presented a question 
> around whether the expired Unified CPE draft needs to be brought 
> back to life (http://www.ietf.org/archive/id/draft-ietf-softwire-
> unified-cpe-01.txt). There was little support for this during the 
> meeting, so I’m taking it to the list to gauge if there’s wider 
> interest in this problem.
> 
> Currently in our network we are facing some of the problems that the
> Unified CPE intended to solve. Specifically, we will have DS-Lite, 
> lw4o6 and public 4over6 in the operator network. The deployed HGWs 
> may support DS-Lite only (RFC6204 compliant ‘off-the-shelf’ CPEs) or
> may be capable of all three. A individual HGW may also need to use 
> different mechanisms at different points in its lifecycle (e.g. 
> lw4o6 initially, but public 4over6 if the customer is located a full
> IPv4 address to use with non A+P compatible L4 protocols) 
> 
> So, my questions here are whether there are other operators (or 
> vendors) that see problems of this type in their networks, and is 
> there enough interest to open up the unified CPE problem again?
> 
> Thanks,
> Ian
>  _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: [email-masked]
Date: Thu, 21 Aug 2014 16:53:51 +0800

Hi Ian & softwirers，

  I have reviewed the document. I agree with Linda.
  Since there are many transition technologies, appling the 
method of this document, is it necessary to analyze any other 
technologies except MAP/LW4o6/DS-Lite?

Thanks,
Wei

"Softwires" <[email-masked]> Re 2014/08/21 15:14:04:

> urgent to have a standard draft providing a unified mechanism to 
> integrate these 
> scenarioes in a network with unifed cpe(s) and unifed network 
> gateway(s), as well as unified 
> provisioning mechanism. 
> 
>  I guess it would be better advanced if some problems listed below 
> can be better addressed: 
> 
>  1. whether it would be better to expand the IPv4-in-IPv6 softwire 
> to all softwires including 
>     IPv4-in-IPv6 tunnel、IPv6-in-IPv4 tunnel and translation 
> mechanism. Because no matter 
>     encapsulation or decapsulation or translation are all basic 
> funtions for cpe(s).It seems 
>     kind of limited if this draft is only restricted to 
IPv4-in-IPv6softwire.

---

From: <[email-masked]>
Date: Thu, 21 Aug 2014 09:41:48 +0000

Hi Ian,

Thank you for initiating this thread.

I do still think this draft is useful. The motivations for writing it are still valid.

Cheers,
Med

De : Softwires [mailto:[email-masked]] De la part de [email-masked]
Envoyé : mercredi 20 août 2014 14:20
À : [email-masked]
Cc : [email-masked]
Objet : [Softwires] Is there any intest in re-visiting the Unified CPE Problem?

Hi,

Thanks,
Ian

---

From: <[email-masked]>
Date: Thu, 21 Aug 2014 12:49:17 +0200

Hi Linda,

Please see inline.

Cheers,
Ian

Hi，Ian

 Since multiple IPv6 transitions technologies have been deployed in current network. It seems
urgent to have a standard draft providing a unified mechanism to integrate these
scenarioes in a network with unifed cpe(s) and unifed network gateway(s), as well as unified
provisioning mechanism.

 I guess it would be better advanced if some problems listed below can be better addressed:

 1. whether it would be better to expand the IPv4-in-IPv6 softwire to all softwires including
    IPv4-in-IPv6 tunnel、IPv6-in-IPv4 tunnel and translation mechanism. Because no matter
    encapsulation or decapsulation or translation are all basic funtions for cpe(s).It seems
    kind of limited if this draft is only restricted to IPv4-in-IPv6 softwire.

[ian] I hadn’t really thought about including 6 in 4 softwires in the scope. There’s going to be some interesting technical questions that arise here, depending on whether the Unified CPE describes just a mechanism for the CPE to deduce the best softwire mechanism to use, or if there are actually protocol extensions to communicate this. If there are protocol extensions, e.g. New DHCPv4 or DHCPv6 options, then I’m not sure that a single document with both makes sense. Is there a situation where a device could receive configuration for both 6in4 and 4in6 tunnels concurrently, have both a v4 and v6 plane available and have to make a decision about what the best softwire to configure is? This sounds like a dual stacked network and so the best softwire is probably no softwire at all.

However, I’m happy to discuss this and if the WG sees value in putting this in scope then that’s fine.

 2. It seems better to notify directly the role of the unified cpe(s):whether this cpe is a B4
    or a lwB4 or a MAP-E CE or a MAP-T CE, through a DHCP option or TR-069. Because it seems
    kind of complicated for the unifed cpe to ascertain what role it is.

[ian] I agree that the current mechanism of provisioned option combinations currently described in the Unified CPE draft is going to be difficult to extend. If the WG does decide to re-open this draft, then we would need to re-evaluate the scope of the draft and re-visit the current solution as it may be that a completely new mechanism is needed.

BRs,
Linda Wang

"Softwires" <[email-masked]<mailto:[email-masked]>> 写于 2014-08-20 20:20:16:

> <[email-masked]<mailto:[email-masked]>>
> 发件人:  "Softwires" <[email-masked]<mailto:[email-masked]>>
>
> 2014-08-20 20:20
>
> 收件人
>
> <[email-masked]<mailto:[email-masked]>>,
>
> 抄送
>
> [email-masked]<mailto:[email-masked]>
>
> 主题
>
> [email-masked]<mailto:[email-masked]>

---

From: Qi Sun <[email-masked]>
Date: Thu, 21 Aug 2014 20:02:50 +0800

Hi Ian,

I think this problem is still valid. 

IPv6 transition might be a relatively long process. Different requirements may be raised as time goes on. When remained IPv4 is quite scare, dynamic manage management of IPv4-IPv6 bindings might necessary. As the scale of IPv6 network enlarges and the number of recycled IPv4 addresses increases, static configuration of v4-v6 binding would be more convenient. Rather than replacing CPEs all the time, I would prefer a CPE prepares for those potential requirements. And a logic for mechanisms selecting is necessary.

Thanks,
Qi

On Aug 20, 2014, at 8:20 PM, <[email-masked]> <[email-masked]> wrote:

> Hi,
>  
> At the last Softwire meeting in Toronto, I presented a question around whether the expired Unified CPE draft needs to be brought back to life (http://www.ietf.org/archive/id/draft-ietf-softwire-unified-cpe-01.txt). There was little support for this during the meeting, so I’m taking it to the list to gauge if there’s wider interest in this problem.
>  
> Currently in our network we are facing some of the problems that the Unified CPE intended to solve. Specifically, we will have DS-Lite, lw4o6 and public 4over6 in the operator network. The deployed HGWs may support DS-Lite only (RFC6204 compliant ‘off-the-shelf’ CPEs) or may be capable of all three. A individual HGW may also need to use different mechanisms at different points in its lifecycle (e.g. lw4o6 initially, but public 4over6 if the customer is located a full IPv4 address to use with non A+P compatible L4 protocols)
>