Re: [mif] Route option for DHCPv6 - next steps?

Ted Lemon <Ted.Lemon@nominum.com> Sun, 01 April 2012 10:34 UTC

Return-Path: <Ted.Lemon@nominum.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1157521F868C for <mif@ietfa.amsl.com>; Sun, 1 Apr 2012 03:34:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.74
X-Spam-Level:
X-Spam-Status: No, score=-104.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 8BC6MlAfV-Nl for <mif@ietfa.amsl.com>; Sun, 1 Apr 2012 03:34:28 -0700 (PDT)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A377721F868A for <mif@ietf.org>; Sun, 1 Apr 2012 03:34:24 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKT3gvMHxaU/eJxlrQ0c9toLOHXA88oU/X@postini.com; Sun, 01 Apr 2012 03:34:27 PDT
Received: from archivist.nominum.com (archivist.nominum.com [64.89.228.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by shell-too.nominum.com (Postfix) with ESMTP id 91FD71B82BB for <mif@ietf.org>; Sun, 1 Apr 2012 03:34:23 -0700 (PDT)
Received: from webmail.nominum.com (cas-01.win.nominum.com [64.89.228.131]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client CN "mail.nominum.com", Issuer "Go Daddy Secure Certification Authority" (verified OK)) by archivist.nominum.com (Postfix) with ESMTPS id 00CE9190064; Sun, 1 Apr 2012 03:34:23 -0700 (PDT) (envelope-from Ted.Lemon@nominum.com)
Received: from MBX-01.WIN.NOMINUM.COM ([64.89.228.133]) by CAS-01.WIN.NOMINUM.COM ([64.89.228.131]) with mapi id 14.02.0247.003; Sun, 1 Apr 2012 03:34:11 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Tony Hain <alh-ietf@tndh.net>
Thread-Topic: [mif] Route option for DHCPv6 - next steps?
Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gB1uXCAAAojCT4=
Date: Sun, 01 Apr 2012 10:34:10 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>
References: <75459BC2-E733-45C0-BC1C-25A19BBA1137@gmail.com> <CAE97176.17DF4%wdec@cisco.com> <CANF0JMD_zfXGcfMy+rCOFXS1aCZ3RPHoRtkBeS8kDgOFcfQ8Fg@mail.gmail.com> <75D251D1-9828-4AFE-9BEF-B376E97133C7@nominum.com> <CANF0JMBbhrF0G=hSvcvyZAddAMW7oSO5KpzUmcJXCtwcnmyWOw@mail.gmail.com> <4A221CE5-ECF0-4E07-9329-E6BAA3F06A96@nominum.com> <4EC4AADB.8030803@piuha.net> <DD1241D5-B794-49C3-A3A2-4294248DDD10@gmail.com> <4F719186.3060507@gmail.com> <CAKD1Yr3tSoDPcheriWdZEeKyhqpDANCP7Co0wVVqK5+mXc7e5A@mail.gmail.com> <4F72CD22.3080604@gmail.com> <CAKD1Yr3RUUthiawKrmxjSNqzEbJcOLpHvDGb9XLtdiU-tfEYyw@mail.gmail.com>, <4F744831.3070406@gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4175@mbx-01.win.nominum.com> <4F7453FC.3010502@gmail.com> <4F74546D.4060808@gmail.com>, <72C42575-6BE2-4F27-B7F4-AA4539DA7EF9@lilacglade.org> <8D23D4052ABE7A4490E77B1A012B6307472D43A1@mbx-01.win.nominum.com>, <069301cd0dd2$5954df00$0bfe9d00$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D45F6@mbx-01.win.nominum.com>, <075201cd0f8e$94cb8170$be628450$@tndh.net>
In-Reply-To: <075201cd0f8e$94cb8170$be628450$@tndh.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.1.10]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "mif@ietf.org" <mif@ietf.org>
Subject: Re: [mif] Route option for DHCPv6 - next steps?
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 01 Apr 2012 10:34:29 -0000

*sigh*

This is why we keep failing to complete anything: people who want the option think the use cases are obvious, and don't want to go to the trouble of clearly articulating them.   People who don't want the option then look at the incompletely articulated use cases, recognize that they aren't valid, and quite rightly ask us to stop working on something for which there is no clear motivating use case.

If you are experiencing operational pain as a result of not having the route option, I would like to hear about that operational pain.   If you just think there ought to be a route option because that's what we did in IPv4, I don't agree with that argument.   I think there are real uses cases that involve real operational pain.   We should focus on addressing those use cases, hopefully in a way that fits in with the rest of the internet architecture, rather than trying to replicate IPv4 functionality just for the sake of completeness.

As for whether this ought to be a DHC or MIF item, part of what happened here is that I pushed pretty hard to *not* have this as a DHC item, because I don't think it's particularly a matter for the DHC working group unless we get a mandate from some other working group to work on it.  I personally am not experiencing any pain as a result of not having this option, and I am not aware of anybody who is except Alexandru and BBF, who actually have two very different use cases.

I personally have no wish to involve DHCPv6 route options in the operation of my home network, and I am pretty sure the ops team at Nominum doesn't need or want this option to operate their networks.   It's something that makes sense in a few cases, not generally.   So it's simply not work the DHC working group would ever adopt on its own, without some clear use case or some clear request from another working group that has already developed the use case.