Re: [mif] Option size for lifetimed default route: route-option vs drlo

[Alexandru Petrescu <[e-mail]>]

Le 28/10/2011 19:51, Tomasz Mrugalski a écrit :
> On 28.10.2011 16:03, Alexandru Petrescu wrote:
>> DHCP to communicate a default route with lifetime, to Client:
>>
>> - with route-option, the option size is: 48bytes.
>
> Not true. You can convey default route information using just
> NEXT_HOP option, which is 20 octets actually.

Yes, if one wants to convey solely the IPv6 address .

Correct me if I'm wrong, but if one wants to add the lifetime (Subject
says "lifetimed default route") then the size is 48bytes.  Even though
the size of the lifetime field could be very small (2 or 4bytes), the
fact that this lifetime is encoded as part of OPTION_RT_PREFIX it adds
many other unnecessary fields (type, option-len, Prefix-len, Metric,
Prefix) - Figure 2 of route-option:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       OPTION_RT_PREFIX        |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Route lifetime                        |
      +-------------------------------+-------------------------------+
      | Prefix-Length |     Metric    |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                            Prefix                             |
      |                          (16 octets)                          |
      |                                                               |
      |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                               |                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      .                                                               .
      .                         RT_PREFIX options                     .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


> Please read section 3.1, paragraphs 2 and 3 (discussion about
> bandwidth limited cases)

Yes, section 3.1 says:
> In bandwidth constrained networks, server MAY send NEXT_HOP option
> without any RT_PREFIX options.

Right, the RT_PREFIX options part of the OPTION_RT_PREFIX is eliminated
and this is already reduction of encoding space compared to the earlier
version of route-option draft.

But if one needs to convey lifetime to this default route then one is
forced to include the OPTION_RT_PREFIX option (even though the RT_PREFIX
options is absent) - am I wrong?

> and section 4.1 of route-option-03.

Yes, section 4.1 tells how the IPv6 address and prefix are conveyed.
Prefix can indeed be removed by this draft (it is "0").  But if one
wants to convey the lifetime then the OPTIONS_RT_PREFIX must be
included, no?

> I'd like to remind you that this paragraph was added specifically to
> address your concerns about bandwidth limitations.

Yes, and thank you for that addition.  When I noticed that addition I
was happy that my comment was taken into account.  However, it was added
without consulting me.  If I were to be consulted then I would have
recommended a different way of doing it, as it is done in the drlo draft.

>> - with drlo, the option size is: 28bytes.
>
> I take your word for it. I read that draft a long a ago.

Thank you for having read it.  It has not changed since then. The DRLO
encoding is:
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   OPTION_DEFAULT_ROUTER_LIST  |          option-len           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                        router_address                         |
      |                                                               |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        router_lifetime        |    lla_len    |               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
      .                 router_link_layer_address(opt)                .
      .                              ...                              .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

> As you see, route-option is more flexible (supports specific routes
> and a default route) and it can be more efficient if you need it.

It is extensible yes, but not such that small messages can be
conveyed.

> While I acknowledge that your specific use case exists, you must
> also acknowledge that not every use case is exactly like yours.

I acknowledge that not every use-case is like this.

The single specific use case that I am referring to may mean a much
larger number of devices than those considered by all other numerous use
case taken all together.

I am referring to the single specific use-case of:

Low-cost devices in Machine-to-Machine communications in LTE future
generation systems.

> I see that you are trying to find one specific very narrow metric
> and use that to point out that one solution is better than another.
> Please don't assume that if you need something, everyone else needs
> it as well.

Well I don't assume so.  But I do appreciate default route different
than specific routes: e.g. it is the only route needed by simplest
devices, the prefix is "0", the metric is 1, the lifetime is like 9000
and the MAC address could  optionally help.

This one specific case can happen on a very large number of devices.  It
is like the 80-20 rule: optimize the cases which risk happening most of
the time.

> Have a nice weekend, Tomek

Thanks for the reply and have a nice long weekend :-)

Alex

> _______________________________________________ mif mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mif