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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Tue, 13 September 2011 16:33 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 4E71D21F8BF7 for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 09:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.424
X-Spam-Level:
X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_FR=0.35]
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 YYmQCurcRlHS for <mif@ietfa.amsl.com>; Tue, 13 Sep 2011 09:33:31 -0700 (PDT)
Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.167.192.142]) by ietfa.amsl.com (Postfix) with ESMTP id 6909621F8BA0 for <mif@ietf.org>; Tue, 13 Sep 2011 09:33:31 -0700 (PDT)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.2) with ESMTP id p8DGZZmX014404 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <mif@ietf.org>; Tue, 13 Sep 2011 18:35:36 +0200
Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p8DGZZND028071 for <mif@ietf.org>; Tue, 13 Sep 2011 18:35:35 +0200 (envelope-from alexandru.petrescu@gmail.com)
Received: from [127.0.0.1] ([132.166.133.183]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p8DGZVTh025824 for <mif@ietf.org>; Tue, 13 Sep 2011 18:35:35 +0200
Message-ID: <4E6F8653.6050708@gmail.com>
Date: Tue, 13 Sep 2011 18:35:31 +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: mif@ietf.org
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com> <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com>
In-Reply-To: <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 16:33:32 -0000

Le 13/09/2011 07:48, Gaurav Halwasia (ghalwasi) a écrit :
> Hi Maximilien,
>
>>> I read this draft, I think similar issue is also being
>>> discussed/solved by draft-dec-dhcpv6-route-option-05 as well.
>>>
>
>> Can you say more about this discussion?
>
> Draft [draft-dec-dhcpv6-route-option-05] handles the cases of both
> default/other static route using one generic option. That's it I was
>  able to gather in my one glance to this draft.

Clarification: do you actually mean
draft-ietf-mif-dhcpv6-route-option-03 (which is a WG item) instead of
draft-dec-dhcpv6-route-option-05?

> On Route lifetime and the length of it's field. I strongly think that
> this field is unnecessary as I don't think default route (given by
> DHCPv6 server) will be that shortlived. Even if it is short lived,
> anyways a new message exchange needs to happen irrespective of this
> field. (either server initiated or client initiated.)
>
> In ND, as the messages are quite periodic (in comparison to DHCPv6),

PEriodicity of ND messages can be tweaked at knob.

Also, DHCP can be quite verbose.

In a WiFi hotspot setting of several APs I see DHCP messages as often as
every minute, or worse - depends on user physical speed - which is
unpredictable.  The quicker the movement, the more often DHCP messages
happen.

> having a lifetime in ND message makes sense. One of the primary use
> of having lifetime in ND is to advertise route as stale (by setting
> lifetime as zero).

Hmm.. yes and no.

Yes prefixes in ND structures may become stale in time, or triggered.

No, thinking the "Router Lifetime" (not "route lifetime") set to 0 in an
RA means that is a default router, and does not mean that is a stale route.

> The main purpose of having RECONFIGURE (sent by Server) message is to
> actually achieve the same thing. At the first place, I feel that
> default routes are not going to be that short lived and even if it is
> (in some scenarios), server can always use RECONFIGURE.

I agree there are a number of choices of what happens when lifetime of a
default route expires.  We have not implemented this because we don't
know for sure what should happen.

> On MAC address issue. Again, think that it's not a good idea to send
>  MAC address of default router in DHCPv6 option. I will probably eat
> a lot of bandwidth in comparison to the benefit it can provide.

The benefit of having (optional) MAC address in the DHCP Advertise next
to the IP address of the default router is that it avoids doing NS-NA to
solve that IP address into a MAC address.

MAC address is 48bit and a pair of NS-NA messages is bigger in terms of
message size.

Alex


> Thanks, Gaurav
>
> -----Original Message----- From: maximilien mouton
> [mailto:maximilien.mouton@gmail.com] Sent: Tuesday, September 13,
> 2011 3:03 AM To: Gaurav Halwasia (ghalwasi) Cc: mif@ietf.org Subject:
> Re: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
>
> Hi Gaurav,
>
> Thank you for your review. See my answers inside.
>
> Le 12/09/2011 07:10, Gaurav Halwasia (ghalwasi) a écrit :
>> Hi,
>>
>>
>>
>> I read this draft, I think similar issue is also being
>> discussed/solved by draft-dec-dhcpv6-route-option-05 as well.
>>
>
> Can you say more about this discussion?
>
>>
>>
>> I see that you are proposing to have lifetime and MAC address in
>> the route option. Why do we want to communicate the lifetime of the
>> route in this option and that too I guess you are proposing to have
>> a upper limit of 150 minutes (9000 seconds) on that. What is the
>> reason behind that.
>
> Actually we are following section 6.2.1 of rfc 4861 but this value
> can be discussed.
>
>> What should be done after the expiry of this 150 minutes..?
>> Information-Request..? or DHCP Renew.?
>
> I tend to Information-Request.
>
>>
>> I don't think that router lifetime will be that short
>
> I understand your comment. What do you propose? 7 days like proposed
>  for a not default route? Do you think this field should be 2 or 4
> bytes long?
>
>
>> and even if router lifetime expires, DHCPv6 server can just send
>> RECONFIGURE.
>
> I agree.
>
>> Normally IPv6 addres lease time will not usually be that less.
>>
>>
>>
>> Further, What's the real need of having MAC/link address in the
>> route list option as there already exists means to get it.
>
> We assume that this option is useful because it gives the client the
> possibility to avoid waiting for na.
>
> Thanks,
>
> Maximilien
>
>>
>> Thanks,
>>
>> Gaurav
>>
>>
>>
>>
>>
>> _______________________________________________ mif mailing list
>> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
> _______________________________________________ mif mailing list
> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif
>