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

Simon Perreault <simon.perreault@viagenie.ca> Fri, 30 November 2012 14:30 UTC

Return-Path: <simon.perreault@viagenie.ca>
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 9802221F89A9 for <softwires@ietfa.amsl.com>; Fri, 30 Nov 2012 06:30:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
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 pSf6aONe7pII for <softwires@ietfa.amsl.com>; Fri, 30 Nov 2012 06:30:39 -0800 (PST)
Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by ietfa.amsl.com (Postfix) with ESMTP id C634521F8935 for <softwires@ietf.org>; Fri, 30 Nov 2012 06:30:39 -0800 (PST)
Received: from porto.nomis80.org (85-169-39-219.rev.numericable.fr [85.169.39.219]) by jazz.viagenie.ca (Postfix) with ESMTPSA id 9529A4038B; Fri, 30 Nov 2012 09:30:38 -0500 (EST)
Message-ID: <50B8C30D.9000506@viagenie.ca>
Date: Fri, 30 Nov 2012 15:30:37 +0100
From: Simon Perreault <simon.perreault@viagenie.ca>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2
MIME-Version: 1.0
To: mohamed.boucadair@orange.com
References: <94C682931C08B048B7A8645303FDC9F36E98AB16AD@PUEXCB1B.nanterre.francetelecom.fr> <50B8ADAD.5010409@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D6F6@PUEXCB1B.nanterre.francetelecom.fr> <50B8B37F.7000609@viagenie.ca> <94C682931C08B048B7A8645303FDC9F36E99E2D777@PUEXCB1B.nanterre.francetelecom.fr>
In-Reply-To: <94C682931C08B048B7A8645303FDC9F36E99E2D777@PUEXCB1B.nanterre.francetelecom.fr>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "softwires@ietf.org" <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: Fri, 30 Nov 2012 14:30:40 -0000

Le 2012-11-30 15:18, mohamed.boucadair@orange.com a écrit :
>> MAP-E:
>> - Lw4o6 set of provisioning information
>> - Forwarding mapping rules
>
> Med: Because of the dependency between the IPv4 address/IPv6 prefix, additional parameters are needed for MAP. This is why the table included two entries for MAP.

I don't follow. A MAP default mapping rule is exactly like a forwarding 
mapping rule, with added semantics saying "this chunk of IPv4 is yours". 
That can be split into a forwarding mapping rule + the usual LW4o6 
parameters, can't you?

>> My intuition is that with a unified CPE we don't need MAP to
>> differentiate between "basic mapping rule", "forwarding mapping rule",
>> and "default mapping rule".
>> - Basic mapping rule is just a forwarding mapping rule + IPv4
>> address +
>> port set.
>> - Default mapping rule is just the remote IPv4-in-IPv6 tunnel endpoint.
>>
>> So in MAP mode we can just provide forwarding mapping rules in
>> addition
>> to the stuff that L4o6 already requires.
>
> Med: you need also MAP parameters (offset, EA-...).

That stuff is included in a "forwarding mapping rule".

>> One thing I expected to see is that if you take a unified CPE
>> that only
>> implements up to LW4o6 mode, and provision it with full MAP mode
>> parameters, it will still work. It will ignore the forwarding mapping
>> rules, and thus will not do mesh networking, but it will still work.
>
> Med: Isn't this covered by the combination of these two points:
>
>     o  A network which supports one or several modes MUST return valid
>        configuration data allowing requesting devices to unambiguously
>        select a single mode to use for attachment.
>
> and
>
>     (1)  If a given mode is enabled (DS-Lite, Lw4o6 or MAP-E), the CPE
>          MUST be configured with the required provisioning information
>          listed in Table 4.  If all of the required information is not
>          available locally, the CPE MUST use available provisioning means
>          (e.g., DHCP) to retrieve the missing configuration data.
>
> If one mode is enabled, the CPE won't ask for more than what it needs.
> If its receives more, it will ignore them. I can add this to text if you think it is missing.

I think it would be good, and I would even add a specific example of 
what happens if you plug a LW4o6 CPE in a MAP-enabled network. (What I 
wrote above.)

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca