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

Alexandru Petrescu <alexandru.petrescu@gmail.com> Fri, 28 October 2011 19:04 UTC

Return-Path: <alexandru.petrescu@gmail.com>
X-Original-To: mif@ietfa.amsl.com
Delivered-To: mif@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 433A721F8515 for <mif@ietfa.amsl.com>; Fri, 28 Oct 2011 12:04:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LrEbnhyrbVdl for <mif@ietfa.amsl.com>; Fri, 28 Oct 2011 12:04:47 -0700 (PDT)
Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1CDEB21F8509 for <mif@ietf.org>; Fri, 28 Oct 2011 12:04:46 -0700 (PDT)
Received: by wwe6 with SMTP id 6so4441070wwe.13 for <mif@ietf.org>; Fri, 28 Oct 2011 12:04:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=fIDsWcocgIdVw4+/VW/7dben6Cdkt/iV2TsYSAy7g8s=; b=wpYNgJYjEMmWG5pWI2JOh2BtxUmBCcSxBdDDQXTVbJTi+cIOkAVXOUsU84pQrNwmJo ByFQNcvrK0CQ2S7qklmQNzblV/6CkAEl0cKi4ClA638QcimmbJrRjxOaLa0h/OMVKyQq tAX7CMmTrkvL7nDFttcwQUxcjNSm930aUfgB4=
Received: by 10.227.204.135 with SMTP id fm7mr5511860wbb.2.1319828686135; Fri, 28 Oct 2011 12:04:46 -0700 (PDT)
Received: from [127.0.0.1] (bur91-3-82-239-213-32.fbx.proxad.net. [82.239.213.32]) by mx.google.com with ESMTPS id gg13sm17180403wbb.8.2011.10.28.12.04.44 (version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 12:04:45 -0700 (PDT)
Message-ID: <4EAAFCC9.20508@gmail.com>
Date: Fri, 28 Oct 2011 21:04:41 +0200
From: Alexandru Petrescu <alexandru.petrescu@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Tomasz Mrugalski <tomasz.mrugalski@gmail.com>
References: <4EAAB63F.3030808@gmail.com> <4EAAEB8B.6050005@gmail.com>
In-Reply-To: <4EAAEB8B.6050005@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: mif@ietf.org
Subject: Re: [mif] Option size for lifetimed default route: route-option vs drlo
X-BeenThere: mif@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiple Interface Discussion List <mif.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif>, <mailto:mif-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif>
List-Post: <mailto:mif@ietf.org>
List-Help: <mailto:mif-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif>, <mailto:mif-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2011 19:04:48 -0000

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
> mif@ietf.org https://www.ietf.org/mailman/listinfo/mif