Re: [Softwires] Is there any intest in re-visiting the Unified CPE Problem?
meng.wei2@zte.com.cn Thu, 21 August 2014 08:54 UTC
Return-Path: <meng.wei2@zte.com.cn>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9AE1A00BB; Thu, 21 Aug 2014 01:54:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.417
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r60JolY7c3v2; Thu, 21 Aug 2014 01:54:27 -0700 (PDT)
Received: from mx6.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9361A0008; Thu, 21 Aug 2014 01:54:26 -0700 (PDT)
Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id 35A04B75C; Thu, 21 Aug 2014 16:54:10 +0800 (CST)
Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 9007273BAC3; Thu, 21 Aug 2014 16:54:08 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s7L8rn5Q053935; Thu, 21 Aug 2014 16:53:49 +0800 (GMT-8) (envelope-from meng.wei2@zte.com.cn)
In-Reply-To: <OF64F4AF5C.1086B6F5-ON48257D3B.00227AC8-48257D3B.0027BD1C@zte.com.cn>
To: wang.cui1@zte.com.cn
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OF8CDC708B.BEA20938-ON48257D3B.002CF399-48257D3B.0030F29F@zte.com.cn>
From: meng.wei2@zte.com.cn
Date: Thu, 21 Aug 2014 16:53:51 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-08-21 16:53:50, Serialize complete at 2014-08-21 16:53:50
Content-Type: multipart/alternative; boundary="=_alternative 0030F29D48257D3B_="
X-MAIL: mse02.zte.com.cn s7L8rn5Q053935
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/J81rPXPdnQBeo_sdR7RNr77z1kw
Cc: softwires@ietf.org, Softwires <softwires-bounces@ietf.org>, draft-ietf-softwire-unified-cpe@tools.ietf.org
Subject: Re: [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 08:54:29 -0000
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" <softwires-bounces@ietf.org> Re 2014/08/21 15:14:04: > 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-IPv6softwire. > > 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" <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>, > > > > 抄送 > > > > 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 > _______________________________________________ > Softwires mailing list > Softwires@ietf.org > https://www.ietf.org/mailman/listinfo/softwires
- [Softwires] Is there any intest in re-visiting th… ian.farrer
- [Softwires] Is there any intest in re-visiting th… wang.cui1
- Re: [Softwires] Is there any intest in re-visitin… meng.wei2
- Re: [Softwires] Is there any intest in re-visitin… mohamed.boucadair
- Re: [Softwires] Is there any intest in re-visitin… ian.farrer
- Re: [Softwires] Is there any intest in re-visitin… Qi Sun