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

wang.cui1@zte.com.cn Thu, 21 August 2014 07:14 UTC

Return-Path: <wang.cui1@zte.com.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 116AA1A03F4; Thu, 21 Aug 2014 00:14:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Status: No, score=-102.417 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ZL0Hm5CrX8Ps; Thu, 21 Aug 2014 00:14:16 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn []) by ietfa.amsl.com (Postfix) with ESMTP id DF0901A00D8; Thu, 21 Aug 2014 00:14:15 -0700 (PDT)
Received: from mse02.zte.com.cn (unknown []) by Websense Email Security Gateway with ESMTPS id 3EE4B126577F; Thu, 21 Aug 2014 15:14:03 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([]) by mse02.zte.com.cn with ESMTP id s7L7E4p0098522; Thu, 21 Aug 2014 15:14:04 +0800 (GMT-8) (envelope-from wang.cui1@zte.com.cn)
In-Reply-To: <8A1B81989BCFAE44A22B2B86BF2B76318AE0634039@HE111643.EMEA1.CDS.T-INTERNAL.COM>
References: <8A1B81989BCFAE44A22B2B86BF2B76318AE0634039@HE111643.EMEA1.CDS.T-INTERNAL.COM>
To: <ian.farrer@telekom.de>
MIME-Version: 1.0
X-KeepSent: 64F4AF5C:1086B6F5-48257D3B:00227AC8; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011
Message-ID: <OF64F4AF5C.1086B6F5-ON48257D3B.00227AC8-48257D3B.0027BD1C@zte.com.cn>
From: wang.cui1@zte.com.cn
Date: Thu, 21 Aug 2014 15:14:04 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-08-21 15:14:04, Serialize complete at 2014-08-21 15:14:04
Content-Type: multipart/alternative; boundary="=_alternative 0027BD1848257D3B_="
X-MAIL: mse02.zte.com.cn s7L7E4p0098522
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/fsVqEtXs5IpHo177MM3p-73vh-8
Cc: softwires@ietf.org, Softwires <softwires-bounces@ietf.org>, draft-ietf-softwire-unified-cpe@tools.ietf.org
Subject: [Softwires] Is there any intest in re-visiting the Unified CPE Problem?
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: softwires wg discussion list <softwires.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/softwires>, <mailto:softwires-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/softwires/>
List-Post: <mailto:softwires@ietf.org>
List-Help: <mailto:softwires-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/softwires>, <mailto:softwires-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Aug 2014 07:14:20 -0000


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

 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.

Linda Wang

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

> <ian.farrer@telekom.de> 
> 发件人:  "Softwires" <softwires-bounces@ietf.org>
> 2014-08-20 20:20
> 收件人
> <softwires@ietf.org>rg>, 
> 抄送
> 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
> https://www.ietf.org/mailman/listinfo/softwires