Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt

Ole Troan <otroan@employees.org> Fri, 06 January 2012 13:16 UTC

Return-Path: <ichiroumakino@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7EC521F8470 for <v6ops@ietfa.amsl.com>; Fri, 6 Jan 2012 05:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.524
X-Spam-Level:
X-Spam-Status: No, score=-3.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eeHEnLLlTzbX for <v6ops@ietfa.amsl.com>; Fri, 6 Jan 2012 05:16:48 -0800 (PST)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 155E821F8449 for <v6ops@ietf.org>; Fri, 6 Jan 2012 05:16:47 -0800 (PST)
Received: by werb14 with SMTP id b14so1337074wer.31 for <v6ops@ietf.org>; Fri, 06 Jan 2012 05:16:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=0+iXOtLy5a2Ss2oRmGXHlV0PV1pM8YvtAl3o9K4Rwgs=; b=PD7TUxixhCLmdLbzA2UatT/GGKVZcofEsKTuSj5ZNlIHUKCOd083DDdIKQb/LMegVj ydaxCFPe9+Hodf8gKoKKITuaiGilYFaW6Jug1cBl5X/30dG4CMGD2/vtT8DEbhGJRVPc jFGxbZkzsj0omzX82/1vqZuTFB/Vw/DdiACKg=
Received: by 10.216.135.154 with SMTP id u26mr2989520wei.20.1325855807209; Fri, 06 Jan 2012 05:16:47 -0800 (PST)
Received: from [10.147.13.99] (64-103-25-233.cisco.com. [64.103.25.233]) by mx.google.com with ESMTPS id q5sm19508138wbo.8.2012.01.06.05.16.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 06 Jan 2012 05:16:46 -0800 (PST)
Sender: Ole Troan <ichiroumakino@gmail.com>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Ole Troan <otroan@employees.org>
In-Reply-To: <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com>
Date: Fri, 06 Jan 2012 14:16:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org>
References: <20111222210318.22621.37105.idtracker@ietfa.amsl.com> <B265E089-2FDF-4648-865B-A4A879B49AAD@cisco.com> <867F4B6A1672E541A94676D556793ACD0CB56952D5@MOPESMBX01.eu.thmulti.com> <8FFE15EA-B90E-4553-A776-7C2C5C221852@employees.org> <867F4B6A1672E541A94676D556793ACD0CB569536F@MOPESMBX01.eu.thmulti.com> <478BBBA2-3D32-4038-A5E4-CD886A417EB8@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953B7@MOPESMBX01.eu.thmulti.com>
To: Wuyts Carl <Carl.Wuyts@technicolor.com>
X-Mailer: Apple Mail (2.1084)
Cc: "v6ops@ietf.org WG" <v6ops@ietf.org>
Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Jan 2012 13:16:49 -0000

Carl,

> if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA?
> 6204 solution is to require the device to always ask.
> [Carl]Just configuration, nothing more, nothing less.  If you want ia_na, ask ia_na, if you don't, don't ask, no need to enforce this.  What if you enforce ia_na and the server doesn't answer anyway ?  Nothing accomplished.  What if you ask ia_na and the server is configured as such to not hand-out anything if ia_na is requested (full match of requested options, if not match fully: nak)
> Keep it simple, it's usually the best.  If customer wants ia_na, configure the device as such, don't expect the CPE to do these things "auto-magically"

this isn't up to the customer. it is a choice by the access network. and I don't think the "here is a fax from your ISP, just type in these parameters" scheme is the best we can do. ;-)

cheers,
Ole

> 
> 
> -----Original Message-----
> From: Ole Troan [mailto:ichiroumakino@gmail.com] On Behalf Of Ole Troan
> Sent: vrijdag 6 januari 2012 14:08
> To: Wuyts Carl
> Cc: Fred Baker; v6ops@ietf.org WG
> Subject: Re: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt
> 
> Carl,
> 
>>> Why should the CPE being charged with a task like this ?  If CAN be configured like this, but for sure it's no mandatory thing!!  As I've mentioned a couple of times before now, from residential CPE point-of-view, too many tasks are being put on the CPE shoulders.  There's no valid reason to enforce the behavior of WPD-5!!!
>>> A CPE must be capable of configuring all kind of models, so be very flexible to meet the customer requirements, but the WPD-5 is nothing to be enforced at all!!
>> 
>> actually this requirement was trying to achieve the exact opposite. to simplify the CPE. avoiding a coupling between RA processing and DHCP.
>> with the above text the two processes can run independently from each other.
>> 
>> (the above assumes that the DHC working group will figure out a solution to multiple stateless option in a single DHCP session).
>> 
>> [Carl] Indeed, de-coupling RA processing from DHCP is exact what I've suggested before, and glad to see some activity on this. However DHCPv6 client can be configured in many ways.  Enforcing "automatic" ia_na requesting is not a good idea.  If you want the CPE to ask for IA_NA, then configure it as such.  With the current statement, there's still coupling of DHCPv6 and RA, but in a different way than before.  I don't see any reason to keep this requirement at all, it does not bring any added value.
> 
> if we want to keep RA and DHCP processes independent. meaning that the two state machines can be run in parallel.
> for the purpose of DHCP, the M/O bits are basically ignored.
> 
> if the network only offers addresses via DHCP, how does the network trigger the CPE to ask for an IA_NA?
> 6204 solution is to require the device to always ask.
> 
> cheers,
> Ole