Re: [mif] A request for Last Call on draft-ietf-mif-dhcpv6-route-option

[maximilien mouton <[e-mail]>]

Tomek,

You use a wrong argument for criticize our proposition of defining 
separate options.
You quote Ted saying it is not a good idea having two different ways 
providing the same information but it is actually not what we proposed.
We proposed the same organization than DHCPv4 option router and classful 
static route option defined in RFC 2132 ie not allow route option to 
provide default route and use a specific option for default route.
Thus there is no interoperability problem in our proposition.

But this mail doesn't aim to continue this discussion.

Anyway my only comment is that I think lifetime field of the default 
route should be up to 65535 (no more for compatibility reasons) with a 
recommendation to limit it at 9000 to be consistent with ND.

Maximilien

Le 27/10/2011 14:17, Tomasz Mrugalski a écrit :
> Dear Chairs, Dear MIF,
>
> DHCPv6 Route Option draft has been presented in MIF several times. It
> was also presented in DHC WG and most* (see below) comments were addressed.
>
> I would also like to point out that this draft incorporates changes
> after Routing Directorate review, especially insightful comments from
> Joel Halpern about potential problems in networks that use dynamic
> routing. The lastest (-03) drafts contains clear warning that
> configuring routing over DHCPv6 in networks that use dynamic routing is
> a very bad idea (unless you exactly now what you are doing).
>
> * Authors chose to not incorporate some of the comments, raised by
> authors of dlro draft. There was a discussion in MIF list. Route option
> authors believe that:
>
> 1. defining separate option for just default route would be wrong. Let
> me qoute Ted Lemon (DHC chair): "It's always a bad idea to have two ways
> of specifying the same information—it creates a very clear potential for
> interoperability problems.". On a related note, I was involved in work
> on DS-Lite configuration over DHCPv6 and we initially had the same idea
> - define two options (address and FQDN) for the same thing. This
> approach was firmly rejected during IESG review. The message was clear:
> "choose one option".
>
> 2. conveying MAC (or link-layer in general) address is not necessary.
> There are other mechanisms like ND to obtain that information. Forcing
> this information on every client is just a waste of space as all clients
> that I know of can obtain this information on their own. They can do
> that in a timely manner, so raised argument about speed-up is not valid
> in my opinion. Another aspect is operational consideration. It would be
> very cumbersome to deploy and use. If operator changes interface in its
> router, DHCP configuration had to be updated and reconfigure procedure
> initiated. It could work in theory, but reconfigure is not commonly
> supported. DHCP server configuration would require knowledge of
> link-layer addresses of announced router(s). We could gain nothing by
> including MAC address, but get a lot of problems in the process.
> Therefore dhcpv6-route-option authors chose to not include link-layer
> information field.
>
> I would like to point out again that route-option proposal is
> extensible. It is designed as a minimal useful set of informations
> necessary for routing configuration. There are many more aspects of
> routing that may be useful in *some* cases. Therefore we made it clear
> that proposed options are extensible. If there are valid cases when
> extra information is useful, it should be defined as extension option.
> That's they recommendation I offer to anyone who says "can you add
> parameter X to route options? I really need it".
>
> To summarize this summary, we believe that mif-dhcpv6-route-option draft
> received enough reviews by experts in MIF, DHC and routing fields and is
> ready for WGLC. Therefore I'd like to ask MIF chairs to announce one.
>
> If we choose to have LC done in a timely fashion, we could discuss the
> results in Taipei. If that is the case, I would like to request time
> slot in Taipei meeting. I can't guess how many comments we will receive
> during WGLC, but I hope 10 or 15 minutes will be enough.
>
> Cheers,
> Tomek
>
> _______________________________________________
> mif mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mif