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

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.

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

BRs,
Linda Wang

"Softwires" <softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>> 写于 2014-08-20 20:20:16:

> <ian.farrer@telekom.de<mailto:ian.farrer@telekom.de>>
> 发件人:  "Softwires" <softwires-bounces@ietf.org<mailto:softwires-bounces@ietf.org>>
>
> 2014-08-20 20:20
>
> 收件人
>
> <softwires@ietf.org<mailto:softwires@ietf.org>>,
>
> 抄送
>
> draft-ietf-softwire-unified-cpe@tools.ietf.org<mailto:draft-ietf-softwire-unified-cpe@tools.ietf.org>
>
> 主题
>
> [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
> Softwires@ietf.org<mailto:Softwires@ietf.org>
> https://www.ietf.org/mailman/listinfo/softwires