Re: [mif] Comments about default route and draft-ietf-mif-dhcpv6-route-option-02

[MOUTON Maximilien <[e-mail]>]

Hello MIF working group, Marc and Ted,

> On Aug 2, 2011, at 11:30 AM, Marc Blanchet wrote:
>> I don't agree with your assessment of waste of memory and
>> bandwidth. This usage of bandwidth is completly noise compared to
>> a single http request on the wire.

I agree a single http request is quite bigger than these 136 bits. But
for some deployment scenarios, economizing the sending of 136 bits is
useful (think resource limited sensor networks, no http traffic, but
single heartbeat temperature samples every 10s.)

Ted Lemon wrote:
> Calling this a bandwidth issue is kind of a misnomer.   This is
> really an issue of space in the DHCPv6 packet. It's a UDP packet, of
>  limited size, and it's not completely unreasonable to want to save 9
>  bytes in it.

We grant we should not have called this issue a waste of memory and
bandwidth but rather a waste of place in DHCPv6 packet.
(one would also notice that since a default router doesn't need a
metric, the metric 1byte field could be saved as well, thus the total
unnecessary place is 10 bytes for a default router.)

> Having said that, I find this argument unconvincing, for the simple
> reason that when you count the additional overhead of sending two
> options, you've already lost four of those nine bytes.

In a sense yes, two options rather than one is consuming additional header.

But not necessarily.

We save at least 6bytes for each default router encoded, if we use
default router list option (draft-mouton), and often even more.

Here is why: imagine the route option contains only one default
router and compare the route-option encoding with using default router
list option we propose.

The route-option encoding is 46 bytes, whereas draft-mouton is 23 bytes
(half of it).

route option

route option header =  4 bytes
next hop sub option header =  4 bytes
next hop addr = 16 bytes
route prefix sub option header =  4 bytes
prefix length + metric + prefix = 18 bytes
total = 46 bytes

default router list option

default router list option header =  4 bytes
default router address = 16 bytes
router lifetime + link layer address length =  3 bytes
total = 23 bytes

The difference draft-mouton vs route-option for encoding one default
route is not just 9/10 bytes but 23.

And, while saving these 23 bytes the draft-mouton still communicates the
lifetime too.

> The other argument is about lifetimes.   But DHCP already has
> lifetimes;

Yes, actually DHCPv6 defines 4-byte lifetimes used in IA address option
and T1/T2 mechanism of IA_NA in the same manner than neighbor discovery
protocol defines valid and preferred lifetime in
prefix information option.

> if this is unclear in the draft, perhaps the draft needs to be made
> more clear.

Actually the draft is relatively clear.

One aspect is this.  route-option draft says:
> One notable exception with respect to [RFC4191] is however that a
> Route Lifetime element is not defined.

I do not agree with this.

route-option draft says:
> The information conveyed by the DHCPv6 Route Option is considered
> valid until changed or refreshed by general events that trigger
> DHCPv6 or route table state changes on a node, thus not requiring a
> specific route lifetime.

Yes, this makes sense, but does not work consistently with ND.

> I haven't read it with this question in mind (indeed, I haven't read
> it in over a year) so I can at least imagine that this is a valid
> criticism, but if it is an accurate criticism, it is valid not only
> for the default route, but for all other routes as well, and so it
> needs to be addressed in the current draft.

Yes and no, the lifetime format mentioned above fits for route lifetime.
But the default router lifetime corresponds to the router lifetime
defined in rfc 4861 section 4.2, a 2-byte field which maximum
value defined in section 6 is 9000 seconds (not for other routes).

Thank you for your comments.

I would like to ask you and the group about the other comments Alex and
myself raised about route-option draft (MAC address, scope generic vs
basic connectivity)?

Maximilien