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