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

Ted Lemon <Ted.Lemon@nominum.com> Fri, 30 March 2012 09:36 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 E688D21F8918 for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 02:36:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.49
X-Spam-Level:
X-Spam-Status: No, score=-106.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, 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 la-pv09YVPJx for <mif@ietfa.amsl.com>; Fri, 30 Mar 2012 02:36:11 -0700 (PDT)
Received: from exprod7og104.obsmtp.com (exprod7og104.obsmtp.com [64.18.2.161]) by ietfa.amsl.com (Postfix) with ESMTP id BE88821F8917 for <mif@ietf.org>; Fri, 30 Mar 2012 02:36:10 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob104.postini.com ([64.18.6.12]) with SMTP ID DSNKT3V+igfBQIPGHN+T1m7NZBzKEAYX3YB8@postini.com; Fri, 30 Mar 2012 02:36:10 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 002C81B8225 for <mif@ietf.org>; Fri, 30 Mar 2012 02:36:10 -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 EDF47190064; Fri, 30 Mar 2012 02:36:09 -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; Fri, 30 Mar 2012 02:36:10 -0700
From: Ted Lemon <Ted.Lemon@nominum.com>
To: Margaret Wasserman <mrw@lilacglade.org>
Thread-Topic: [mif] Route option for DHCPv6 - next steps?
Thread-Index: AQHNDL2jhfr6t6vyVEeGR+93z5NinJZ/3M2AgAG+LoD//4t2bYAAgpgAgAAAh4CAABcYAP//i0r4gAC0mQD//8qt3gAjg1aA//+udoc=
Date: Fri, 30 Mar 2012 09:36:09 +0000
Message-ID: <8D23D4052ABE7A4490E77B1A012B6307472D47A7@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 >, <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org>
In-Reply-To: <550B9F79-1642-469F-9ED3-96DA26AA40AB@lilacglade.org>
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: Fri, 30 Mar 2012 09:36:12 -0000

> One alternative that was raised at the mic, but that has not (to my
> knowledge actually been proposed anywhere) was the use of unicast
> ND for cases when you want to configure different routes on different
> nodes.  Are there problems in this space that would not be solved by
> doing that?  If so, what are they?  If not, perhaps we need to write
> up a unicast ND mechanism?

We talked about Unicast RA in Taipei as well.   It does solve the problem, but it is only really useful in cases where you have a single router or a small number of routers that need to be configured with these unicast ND routes.   In a large network with many routers, the information distribution problem becomes truly painful.   This is a specific use case for something like a DHCP route option, and I was suprised not to see it mentioned yesterday.

It's true, as Jari said, that this can be accomplished in other ways, and maybe it would be better if it would.   If there were some better central management solution for populating unicast RA mappings on the router, then unicast RA would indeed address the exact use case that I think we care about.   But without the mechanism for populating routers, we still have a poorly-addressed use case.   And then the question is, do we want to develop a whole new protocol just to solve this one small problem?

It might be worth developing the protocol just to put this issue to bed.