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

"Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com> Tue, 13 September 2011 05:46 UTC

Return-Path: <ghalwasi@cisco.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 97F3221F8B12 for <mif@ietfa.amsl.com>; Mon, 12 Sep 2011 22:46:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.791
X-Spam-Level:
X-Spam-Status: No, score=-9.791 tagged_above=-999 required=5 tests=[AWL=0.808, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 J5p8YaHd7WKX for <mif@ietfa.amsl.com>; Mon, 12 Sep 2011 22:46:13 -0700 (PDT)
Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 6F57A21F8B11 for <mif@ietf.org>; Mon, 12 Sep 2011 22:46:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=ghalwasi@cisco.com; l=3417; q=dns/txt; s=iport; t=1315892899; x=1317102499; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=nj//NNQ/zXwkzBAVduz3rjCEm9tWzpz9arZKYm+ljsE=; b=D5nFGEqB/eVRV4kqhklNiakm5tLKBL4uGyY9GrZLqCXTgROZzcRk545x ailrwsr/wLZUzMLUOxmJDtO7XL8qUWg7jPvgnuQf/vlylC6cKO2LjPBUB Xu+4TsVGvT7daUSxYL5eDPEnnxXz7w+BiyLmjf9WmSpEiBguIw92LORMu M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsoAAJDtbk5Io8US/2dsb2JhbABCmGOPEHiBUgEBAQECAQEBAQ8BHT4LBQcEAgEIEQQBAQsGFwEGASAGHwkIAQEECwgIGodVBJd8AZ5Jhg5gBIc+LZBxhGiHHg
X-IronPort-AV: E=Sophos;i="4.68,372,1312156800"; d="scan'208";a="54299013"
Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-2.cisco.com with ESMTP; 13 Sep 2011 05:48:16 +0000
Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p8D5mEGw005554; Tue, 13 Sep 2011 05:48:16 GMT
Received: from xmb-bgl-41e.cisco.com ([72.163.129.220]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Sep 2011 11:18:16 +0530
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 13 Sep 2011 11:18:14 +0530
Message-ID: <3CF88B99A9ED504197498BC6F6F04B81040FC010@XMB-BGL-41E.cisco.com>
In-Reply-To: <4E6E7A72.9030208@gmail.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mif] Comments on draft-mouton-mif-dhcpv6-drlo-00
Thread-Index: Acxxk5M+uurvpeTvTlSqs6hlC7s9TQAM8ULA
References: <3CF88B99A9ED504197498BC6F6F04B81040FBDA9@XMB-BGL-41E.cisco.com> <4E6E7A72.9030208@gmail.com>
From: "Gaurav Halwasia (ghalwasi)" <ghalwasi@cisco.com>
To: "maximilien mouton" <maximilien.mouton@gmail.com>
X-OriginalArrivalTime: 13 Sep 2011 05:48:16.0088 (UTC) FILETIME=[BB94FD80:01CC71D8]
Cc: 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 05:46:14 -0000

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.

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), 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).

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.

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.

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