Re: [mif] I-D draft-ietf-mif-dhcpv6-route-option-03 published

Hello Tomasz and MIF wg,

I am pleased to see that you took in account our previous comments with 
Alexandru.

But reading this new version of your draft I still think a default route 
should be seen as a special route and thus not treated the same way than 
others.

Default route is an information taking part of what I call the "survival 
kit" for Internet i.e. the 3-tuple of IP address, DNS server address and 
default router address which is the minimum requirement for a client to 
access to Internet. This is why I think the default router configuration 
should have its own DHCPv6 option like default router list option 
described in 
http://tools.ietf.org/search/draft-mouton-mif-dhcpv6-drlo-00 (draft-mouton).

I thus think that a client should be able to require only a default 
route (and no other route). The problem with the options defined in your 
draft is that a client who wants to configure only a default route must 
include NEXT_HOP and RT_PREFIX options in ORO.
In this case the client will obtain unnecessary route information 
because the server will send back all route information it has in 
NEXT_HOP and RT_PREFIX options.

This is why I think the options described in your draft should not allow 
server to provide default router information.

I also think it could be good to share this discussion with dhcwg 
because it covers not only mif scenarios.

Maximilien

Le 11/09/2011 00:42, Tomasz Mrugalski a écrit :
> On 11.09.2011 00:03, internet-drafts@ietf.org wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories. This draft is a work item of the Multiple Interfaces
>> Working Group of the IETF.
>>
>> 	Title           : DHCPv6 Route Options
>> 	Author(s)       : Wojciech Dec
>>                            Tomasz Mrugalski
>>                            Tao Sun
>>                            Behcet Sarikaya
>> 	Filename        : draft-ietf-mif-dhcpv6-route-option-03.txt
>> 	Pages           : 14
>> 	Date            : 2011-09-10
>>
>> This document describes DHCPv6 Route Options for provisioning IPv6
>> routes on DHCPv6 client nodes.  This is expected to improve the
>> ability of an operator to configure and influence a nodes&#39;
>> ability to pick an appropriate route to a destination when this node
>> is multi- homed and where other means of route configuration may be
>> impractical.
> Dear MIF and DHC groups,
>
> This draft was presented in DHC WG in Quebec. While the primary area of
> review was from DHCP protocol perspective, there were quite a few
> insightful comments received related to other aspects. I was also
> presented again in MIF WG.
>
> After a long discussion we reached consensus and solved concerns raised
> during review by Routing Directorate.
>
> Authors would like to thank Joel Halpern, Marcin Siodelski and Alexandru
> Petrescu for their insightful comments and through review.
>
> Significant changes since -03 version:
> - added a route lifetime field. This provides a way to age and expire a
> route
> - route lifetime can be used to revoke a route during renewal
> - IA_RT prefix removed. It was only a container option, so this removal
> does not change the way this option works
> - clarified that default route may be configured with this mechanism
> - provided a way to configure default route in bandwidth-constrained
> networks
> - clarified that this mechanism may be used on routers (e.g. residential
> gateways)
> - added a way to configure on-link routes
> - added a limitation section pointing out that using this mechanism in
> networks that do dynamic routing is usually a bad idea
>
> The only comment that we chose not to implement is a suggestion to
> include MAC address information. We believe that would be wrong for
> number of reasons. If reviewers still thinks this is useful, we would
> like to point out a possible solution. As proposed options are designed
> to be extensible, reviewers who proposed adding MAC address can simply
> define a suboption that will provide necessary information in cases,
> where such information cannot be obtained in the usual way. Such
> approach is also better, because in most cases this information is not
> needed and may even be harmful. This kind of information should be
> requested only in those limited cases, where it is really needed. If
> proponents choose to define such extensions, our belief is that extra
> explanation why such information is needed would be very useful to
> understand their use case.
>
> There are no outstanding issues with this draft. This draft has been
> reviewed by Routing Directorate, by DHC WG and was presented several
> times in MIF meetings and in DHC meeting. As one of the authors (and I
> believe I speak on behalf of all authors) I think this draft is ready
> for last call. Therefore I would like to ask MIF chairs to announce WGLC.
>
> Of course any additional comments are more than welcome.
>
> Cheers,
> Tomek Mrugalski
> _______________________________________________
> mif mailing list
> mif@ietf.org
> https://www.ietf.org/mailman/listinfo/mif