Subject: [manet] <prefix-length> field(s)

From: Ulrich Herberg <[email-masked]>
Date: Fri, 16 Nov 2007 08:54:32 +0100

Hi,

In the newest version of the draft (draft-ietf-manet-packetbb-11.txt)
one or more <prefix-length> fields have been introduced. I wondered 
whether the following scenario might happen:

One has for example 99 addresses in the <address-block> with all having
the same prefix length (e.g. 128 bits) and one address at the end with
another prefix length (e.g. /64 to aggregate all the preceding addresses
using CIDR). In the current draft, there would be 100 <prefix-length>
fields. My idea would be to modify the <prefix-length> field in the
following way: if the value is greater than 128 (which cannot be the
case for a prefix) one could erase the first bit of the field
<prefix-length> and use this number x for saying: "the next x addresses
have the same prefix length". In the example:

<prefix-length_1><prefix-length_2><prefix-length_3>
|   11100011    |   10000000     |   01000000     |

where: (in decimal)
prefix-length_1 = 227, this cannot be a prefix, so erase first bit = 99
prefix-length_2 = 128, this has to be a prefix. So the next 99 addresses
  will have the prefix 128
prefix-length_3 = 64, this has to be a prefix. This is the prefix of the
  last address.

This is only an idea of mine, but instead of using 100 <prefix-length>
fields (and thus bytes) this would only need 3 bytes assuming that the
addresses are sorted by their prefix. Even if the addresses are not 
sorted, one could compact the message from at least three messages with
the same prefix on. 

Maybe one could combine several of
these special prefix-length fields consecutively to indicate even more
than the 127 possible repetitions of the following prefix. (e.g. by
multiplying: 128 * 128 * <prefix_length1> + 128 *  <prefix_length2> +
<prefix_length3> repetitions of the prefix <prefix_length4>). What do
you think?

Regards
Ulrich

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 16 Nov 2007 09:28:08 -0000

It's possible to come up with cases that the new format
is less efficient than the old. But in this case the
easiest approach is splitting into two address blocks.
I think the approach you are suggesting is really going
to get very messy in explanation and implementation.
Over more usual cases, which I think will be almost all
the cases really met, there's actually a small saving
(two octets).

-----Original Message-----
From: Ulrich Herberg [mailto:[email-masked]] 
Sent: 16 November 2007 07:55
To: [email-masked]
Subject: [manet] <prefix-length> field(s)

               *** WARNING ***

This mail has originated outside your organization,
either from an external partner or the Global Internet. 
     Keep this in mind if you answer this message. 

Hi,

where: (in decimal)

Regards
Ulrich

********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 16 Nov 2007 11:16:43 +0100

Hello Christopher,

you are certainly right that this would be more complicated in the
specification and in implementations, and could be easily avoided by
splitting into several address blocks (e.g. one for each distinct prefix
length). But then this would be up to the user (or protocol) that uses
packetbb to make the split. The user might not be aware that splitting
up addresses might reduce the message size significantly (depending on
the addresses used in the address block). In addition, that would also
complicate every implementation of a protocol, rather than only one
implementation of the message format.

Best regards,
Ulrich