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

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