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

<ian.farrer@telekom.de> Wed, 20 August 2014 12:20 UTC

Return-Path: <ian.farrer@telekom.de>
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 D06171A02F9 for <softwires@ietfa.amsl.com>; Wed, 20 Aug 2014 05:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.817
X-Spam-Status: No, score=-1.817 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id G_p0qNl-QBPE for <softwires@ietfa.amsl.com>; Wed, 20 Aug 2014 05:20:20 -0700 (PDT)
Received: from tcmail43.telekom.de (tcmail43.telekom.de []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B48C81A02E4 for <softwires@ietf.org>; Wed, 20 Aug 2014 05:20:19 -0700 (PDT)
Received: from q4de8psa169.blf.telekom.de ([]) by tcmail41.telekom.de with ESMTP; 20 Aug 2014 14:20:17 +0200
X-IronPort-AV: E=Sophos;i="5.01,901,1400018400"; d="scan'208,217";a="645332883"
Received: from he113443.emea1.cds.t-internal.com ([]) by q4de8psazkj.blf.telekom.de with ESMTP/TLS/AES128-SHA; 20 Aug 2014 14:20:16 +0200
Received: from HE111643.EMEA1.CDS.T-INTERNAL.COM ([]) by HE113443.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 20 Aug 2014 14:20:16 +0200
From: <ian.farrer@telekom.de>
To: <softwires@ietf.org>
Date: Wed, 20 Aug 2014 14:20:16 +0200
Thread-Topic: Is there any intest in re-visiting the Unified CPE Problem?
Thread-Index: Ac+8cRnrFBk6a2GxTpOl12WogZdkug==
Message-ID: <8A1B81989BCFAE44A22B2B86BF2B76318AE0634039@HE111643.EMEA1.CDS.T-INTERNAL.COM>
Accept-Language: en-US, de-DE
Content-Language: en-US
acceptlanguage: en-US, de-DE
Content-Type: multipart/alternative; boundary="_000_8A1B81989BCFAE44A22B2B86BF2B76318AE0634039HE111643EMEA1_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/softwires/-8CwURAGi5d6J6jRZbvcJPorzyQ
Cc: 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: Wed, 20 Aug 2014 12:20:23 -0000


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?