Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 13 September 2011 22:43 UTC

Return-Path: <alexandru.petrescu@gmail.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 95A2D21F8CDE for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 15:43:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.543
X-Spam-Level:
X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=1.056, 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 JKAA-2sxGZYA for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 15:43:59 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id C25B721F8CDB for <mif@ietf.org>; Tue, 13 Sep 2011 15:43:58 -0700 (PDT)
Received: by fxd18 with SMTP id 18so1115724fxd.31 for <mif@ietf.org>; Tue, 13 Sep 2011 15:46:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=ydvkHFDjjghJLMLnGY+iqP8xfPil7SLNLCt1+pWbRMQ=; b=vpKMXX2clVwPBFcNnsOMP3lVKHENI3cucm8ZLW3CrKSdQuKFLbz1Gh6lgd6KLbDgyd f3xm7DDPJHVYmayetwq9lx9h8OTMpfTyQ/E4XcOfV/JO5vEQQHH40F9rPYT4/qhwdfhR mvEDOtNSXbOl3b6pBVY/llOsFOU645jCnaVkk=
Received: by 10.223.5.155 with SMTP id 27mr154050fav.90.1315953965583; Tue, 13 Sep 2011 15:46:05 -0700 (PDT)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id c2sm1631365faf.16.2011.09.13.15.46.03 (version=SSLv3 cipher=OTHER); Tue, 13 Sep 2011 15:46:04 -0700 (PDT)
Message-ID: <4E6FDD26.4070206@gmail.com>
Date: Wed, 14 Sep 2011 00:45:58 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: Ted Lemon <Ted.Lemon@nominum.com>
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <4E6EAFC2.5060906@gmail.com> <4E6EDEA8.3080108@gmail.com> <CFDF82EE-052B-4A61-AE1B-152337822B6E@nominum.com> <4E6F825C.3080303@gmail.com> <3D0B3661-8A8F-4BB2-A8EF-25007BEAF66C@nominum.com> <4E6F923F.7090304@gmail.com> <7061CEB8-8084-41D5-B31E-9F8E3B6C7091@nominum.com> <4E6F9B91.7010503@gmail.com> <B987CA14-569C-428C-8D8A-C97A0E42EF48@nominum.com> <4E6FA049.1040309@viagenie.ca> <4E6FC41E.6010002@gmail.com> <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com>
In-Reply-To: <10031B1F-30BC-4475-8866-C21CD4E1E819@nominum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: "<mif@ietf.org>" <mif@ietf.org>
Subject: Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
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: Tue, 13 Sep 2011 22:43:59 -0000

Le 13/09/2011 23:31, Ted Lemon a écrit :
> On Sep 13, 2011, at 4:59 PM, Alexandru Petrescu wrote:
>> One particular use case is:
>
> Sorry, to be clear, a use case is an example of usage that requires
> new protocol action, because existing functionality cannot address
> the use case.

The use case is a wifi-3G phone whose default route is provided by DHCP
on WiFi and must point to a virtual interface - current spec does not
allow for it.

Must also be expirable at the same time as ND - current spec does not
allow for it.

> Use cases have to be real, concrete things, not hypotheticals.

Protocol specs must be coherent in text and not hypotheticals either.
Or, current spec says "Each IPv6 route consists of an IPv6 next hop
address, an IPv6 destination prefix (a.k.a. the destination subnet), and
a host preference value for the route."

There is no preference in the draft.  And, non-hypothetical IPv6 routes
consist in more than nexthop, dstprefix, preference.  Examples are:
number of hops to reach that nexthop, interface name and lifetimes.

Protocol specs should be implementable.  Ideally, one would take the
implementation and write the draft literally after it; and less ideally
the other way around.

> I can always make up a hypothetical example to justify any sort of
> protocol extension, but if there is no real-world use case that
> requires it, all the work of doing that protocol extension is
> wasted.

The use cases I have described are all hands-on that I have
experimented several times.  They are not hypotheticals.

> What you've given in this particular message are a couple of
> examples of how the option could be used. These are not relevant use
> cases, because they could also be addressed with the existing
> proposed option. That is, they do not motivate additional work.

The proposed option is incomplete, not implemented, and missing some
reference to existing base.

It is difficult to suggest improvements to it because it takes a wrong
direction.  We have made some suggestions, and we did discuss f2f a few
times, and we are thankful for having taken some of our comments; but
not all messages get through.  This is one reason we suggest a different
option for default route.

Alex

>