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" <[email protected]<mailto:[email protected]>> 写于
2014-08-20 20:20:16:
> <[email protected]<mailto:[email protected]>>
> 发件人: "Softwires"
> <[email protected]<mailto:[email protected]>>
>
> 2014-08-20 20:20
>
> 收件人
>
> <[email protected]<mailto:[email protected]>>,
>
> 抄送
>
> [email protected]<mailto:[email protected]>
>
> 主题
>
> [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 protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/softwires
_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires
