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

Wuyts Carl <Carl.Wuyts@technicolor.com> Fri, 06 January 2012 15:13 UTC

Return-Path: <Carl.Wuyts@technicolor.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 58E7721F87CC for <v6ops@ietfa.amsl.com>; Fri, 6 Jan 2012 07:13:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.474
X-Spam-Level:
X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 R8uYQbjmTKHM for <v6ops@ietfa.amsl.com>; Fri, 6 Jan 2012 07:13:54 -0800 (PST)
Received: from na3sys009aog104.obsmtp.com (na3sys009aog104.obsmtp.com [74.125.149.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCCA21F87B0 for <v6ops@ietf.org>; Fri, 6 Jan 2012 07:13:35 -0800 (PST)
Received: from MOPESEDGE01.eu.thmulti.com ([129.35.174.203]) (using TLSv1) by na3sys009aob104.postini.com ([74.125.148.12]) with SMTP ID DSNKTwcPnTFG97+S66oYqXfQ2ocmn/C8opM5@postini.com; Fri, 06 Jan 2012 07:13:37 PST
Received: from MOPESMAILHC01.eu.thmulti.com (141.11.100.25) by mail3.technicolor.com (141.11.253.22) with Microsoft SMTP Server (TLS) id 8.3.192.1; Fri, 6 Jan 2012 16:07:09 +0100
Received: from MOPESMBX01.eu.thmulti.com ([169.254.1.20]) by MOPESMAILHC01.eu.thmulti.com ([141.11.100.25]) with mapi; Fri, 6 Jan 2012 16:07:17 +0100
From: Wuyts Carl <Carl.Wuyts@technicolor.com>
To: Ole Troan <otroan@employees.org>
Date: Fri, 06 Jan 2012 16:07:15 +0100
Thread-Topic: [v6ops] Fwd: I-D Action: draft-ietf-v6ops-6204bis-05.txt
Thread-Index: AczMg35FW0vy8A1cSM+hHtkhhXfe+wAAFw7A
Message-ID: <867F4B6A1672E541A94676D556793ACD0CB569544D@MOPESMBX01.eu.thmulti.com>
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> <1E00A66B-B0A3-4FFC-AF0E-ED3A2CACEA60@employees.org> <867F4B6A1672E541A94676D556793ACD0CB56953BE@MOPESMBX01.eu.thmulti.com> <2B940363-1E7B-45F9-9FB9-37E6691F57E2@employees.org>
In-Reply-To: <2B940363-1E7B-45F9-9FB9-37E6691F57E2@employees.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 15:13:55 -0000

Ole,

>> 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. ;-)
> 
> [Carl] True, but there will be no "fax" from the ISP to the customer either to ask to switch something in configuration off either if it wouldn't work.  Anyway, I'm always flexible, so I say make it a SHOULD iso MUST, meaning "you should ask it unless you have a good reason not to do so", no ??

the goal here is to specify a CPE that will work on any access network and without any user configuration.
note that this requirement is within an "if block", you only need to do this if you don't want to wait for the RA with the M/O flags.


[carl] Well, we've the ability to either listen to the RA or not; if not, you decide (in fact it is the operator deciding in our deployment model) what mode you want to run in, so firmware configuration for that operator will either include or not include the ia_na option, no interference from user needed.  Thing is.  If you don't listen/wait for the RA option, you fall back on configuration, so nothing happens "auto-magically"; it's just configuration.  Our protocols can fully run independent, as they should, no coupling unless specifically configured.  It's not the first time, and probably not the last :-), that I'm fighting for protocol de-coupling.  And in our case, no user configuration is needed, just plug the box in.  Please note that I think it's only in "Utopia" that all devices will work on all networks.  You're depending on the access side, you're depending on the used DHCPv6 server, proxy, relay or whatever in use, hence the device works in 100% of the cases is virtually impossible.

Have a nice weekend
Carl