Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe

Qi Sun <sunqi.csnet.thu@gmail.com> Mon, 03 December 2012 13:13 UTC

Return-Path: <sunqi.csnet.thu@gmail.com>
X-Original-To: softwires@ietfa.amsl.com
Delivered-To: softwires@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8768421F8714 for <softwires@ietfa.amsl.com>; Mon, 3 Dec 2012 05:13:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.299
X-Spam-Level:
X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W98-1z0OqDHq for <softwires@ietfa.amsl.com>; Mon, 3 Dec 2012 05:13:52 -0800 (PST)
Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id F33E921F8704 for <softwires@ietf.org>; Mon, 3 Dec 2012 05:13:51 -0800 (PST)
Received: by mail-pb0-f44.google.com with SMTP id uo1so1874478pbc.31 for <softwires@ietf.org>; Mon, 03 Dec 2012 05:13:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Q+1Yitm7A0vDmY6lAV9DebXJGwKemOe2bW67mS+d3lU=; b=o5pmok0tWKcU4AkDaqGk645lDkL1q7lgQ2+eEHeqMlQ1B6qmCJBWBvo87u6i1b1O1d thYNlKk7FE6XWEnJH5Jq4kualDJmzBi6RkZfMUym9a0KsknnxxVnXFuo5JqmNhZ4Duic Lc+pBzMGTooM6iy4ocMpmRph1m1tHw11k/vVBYpoSkdp4Nq/fpFl7myN7mCLJjbVF4BZ fLTa9cLCSgA1SiwnmUyvTCUa6KS6+u/Z5vr6C1El/F/mESqPmjlOsZbhgeeQ4Pw03D1Y D6Sl9mmLZ3VWzEXt8LLnue96BPuk7MZAtH0aZzYyl49I/CNzbE80LJ9E8qdh8DcS1uId XpYQ==
Received: by 10.68.241.231 with SMTP id wl7mr28674578pbc.164.1354540431670; Mon, 03 Dec 2012 05:13:51 -0800 (PST)
Received: from [192.168.0.109] ([114.255.41.137]) by mx.google.com with ESMTPS id oi3sm8059204pbb.1.2012.12.03.05.13.30 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 03 Dec 2012 05:13:51 -0800 (PST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="utf-8"
From: Qi Sun <sunqi.csnet.thu@gmail.com>
In-Reply-To: <FDDE7D1B-D750-4684-A34D-8CB24D2F19A2@employees.org>
Date: Mon, 03 Dec 2012 21:13:22 +0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <051213C3-F4A1-4EF2-9725-DBCD82975441@gmail.com>
References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <9207CAAE-7907-4103-994C-07961030FAE9@employees.org> <50B9B5C7.107@viagenie.ca> <10C9FD27-2894-4495-90E1-15A9AC9D73B9@employees.org> <8A1B81989BCFAE44A22B2B86BF2B76318954FEE360@HE111643.EMEA1.CDS.T-INTERNAL.COM> <FDDE7D1B-D750-4684-A34D-8CB24D2F19A2@employees.org>
To: Ole Trøan <otroan@employees.org>
X-Mailer: Apple Mail (2.1084)
Cc: softwires@ietf.org
Subject: Re: [Softwires] Unified Softwire CPE: draft-bfmk-softwire-unified-cpe
X-BeenThere: softwires@ietf.org
X-Mailman-Version: 2.1.12
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: Mon, 03 Dec 2012 13:13:52 -0000

Ole,


On 2012-12-3, at 下午5:06, Ole Trøan wrote:

> Ian,
> 
>> Whichever state is selected, NAT is certainly fundamental to how the state will operate and so we tried to weave it into the functional description. I'm not sure that provisioned NAT info enough to be able to use to unambiguously define with operating 'mode' (for want of a better word) to use.
>> 
>> One of the reasons for the use of state in the draft is try and define the operating modes with as little overlap as possible (it's not 100%, but there's only 1 exception at the moment for binding mode and MAP1:1). From this, then it is easier to align the specific solution names to the state characteristics.
> 
> I don't think you should try to define modes such that the map (no pun intended) into the specific solution names.
> shouldn't the purpose of a "unified CPE", be for the CPE not to have to care about the different "deployment modes" on the head end?

[Qi] I think the modes are "functional modes" rather than "deployment modes". CPE has different functional characteristics under different modes and it has to know what behavior it should perform under different mode. 

> 
>> But, with what you've suggested, there is more overlap, i.e. both 2&4 have NAT functions that are supported by two different mechanisms.
>> 
>> However, what you've said does raise the following point:
>> 
>> The way that state is described in the draft at the moment is actually taken from a concentrator perspective. This could be taken to be almost the inverse of the amount of state that is required from the CPEs perspective (i.e. if all of the state is in the providers network (DS-Lite), then the CPE doesn't need it. If the providers network has less state ('per-customer', 'stateless'), then the CPE needs to have more - i.e. dynamic state table for NAT, configuration for local IPv4/port set, MAPing rules etc.
>> 
>> Would describing the different states more from the CPE's perspective make this clearer?
> 
> that would certainly help. although I don't think "state" is the defining characteristic.

[Qi] IMHO, using state as the defining characteristic, the CPE can determine which module to mount and which functionality to perform.

Best Regards,
Qi

> 
> cheers,
> Ole
> _______________________________________________
> Softwires mailing list
> Softwires@ietf.org
> https://www.ietf.org/mailman/listinfo/softwires