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

"Tony Hain" <alh-ietf@tndh.net> Mon, 02 April 2012 16:18 UTC

Return-Path: <alh-ietf@tndh.net>
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 2C1A821F851B for <mif@ietfa.amsl.com>; Mon, 2 Apr 2012 09:18:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.846
X-Spam-Level:
X-Spam-Status: No, score=-0.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, RDNS_DYNAMIC=0.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 I0OZ-KmVWt6z for <mif@ietfa.amsl.com>; Mon, 2 Apr 2012 09:18:47 -0700 (PDT)
Received: from tndh.net (75-149-170-53-Washington.hfc.comcastbusiness.net [75.149.170.53]) by ietfa.amsl.com (Postfix) with ESMTP id 7436D21F865B for <mif@ietf.org>; Mon, 2 Apr 2012 09:18:47 -0700 (PDT)
X-AuthUser: alh-ietf@tndh.net
Received: from eaglet ([172.20.144.31]:40052) by tndh.net with [XMail 1.27 ESMTP Server] id <S19200EB> for <mif@ietf.org> from <alh-ietf@tndh.net>; Mon, 2 Apr 2012 09:18:44 -0700
From: Tony Hain <alh-ietf@tndh.net>
To: 'Ted Lemon' <Ted.Lemon@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$94cb817 0$be628450$@tndh.net> <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D5C5B@mbx-01.win.nominum.com>
Date: Mon, 02 Apr 2012 09:18:42 -0700
Message-ID: <00c301cd10ec$46f39ff0$d4dadfd0$@tndh.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGYocXPKzopiDhicKFSNXe3ky5PRQFWcj/vAj3jZD8CE4SQEAM8EDN1Aal2DB8CuqDa4AGu3TE6AouFInYBmOpBUgHiAfgSAabbPDMCVhY93gK9RQNgAaU+fSYBVklIJAKKPEcuAtiEBeIBI67GfQHRMw/lAfaPfVACiVre65WUMZKQ
Content-Language: en-us
Cc: 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: Mon, 02 Apr 2012 16:18:48 -0000

Ted,

I agree that you don't do something just because it was done in IPv4, but
your response is exactly the same as your complaint about the public
lynching. Just because your local network is not using this mechanism is no
reason to deny others from having it for theirs. 

I didn't put more detail in the initial response because I thought it needed
more time to do it justice. I still intend to do an offline set of comments
about splitting the existing doc so that there is a dhcp mechanism and an RA
approach, but in short; people do operate VPNs with split tunneling, and
need a way to push the internal routes to the client. The operational pain
will occur when there is no option 121 for those networks that use it for
IPv4. The alternative is what I am doing; manually running a static route
script every time the vpn goes up and another when it goes down to pull them
back out. That is not operationally viable at scale, and is more than
annoying even during the interim while the nonsense fighting over the
"correct" operational model continues in the IETF. It really doesn't matter
what your local network uses or wants, what matters is can people clearly
articulate a use case and a mechanism to deal with it. 

As I said earlier, there are networks that want to use dhcp as their
centralized point of management control. For those networks we need to
document the IPv6 version of RFC 3442. At the same time there are networks
that want to avoid deploying dhcp just for one mechanism, so an alternative
needs to be defined. Not that it matters, but my corporate network only uses
IPv6 dhcp to provision a router that requires it for 6rd testing, and that
will go away at some point. I really don't want to keep dhcp just for the
VPN clients, but that is better than manual scripts. In the big picture
though, it really doesn't matter what my network uses any more than any
other. 

Widespread deployment requires that people have the tools they want to use
for managing their local network. Continued fighting in the IETF over why
someone else's operational model is "wrong" is simply delaying deployment.
MIF is supposed to be identifying all the operational issues raised by the
multiple interface case, then the resolutions. People have raised use cases
for why routes need to be pushed, yet MIF seems more interested in denying
the operational concerns than in documenting solutions.

Tony


-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com] 
Sent: Sunday, April 01, 2012 3:34 AM
To: Tony Hain
Cc: mif@ietf.org
Subject: RE: [mif] Route option for DHCPv6 - next steps?

*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.