Subject: [DNA] DNAO format revision?

From: Greg Daley <[email-masked]>
Date: Mon, 23 May 2005 12:21:10 +1000

Hi DNA,

I've been talking to Erik and most of my questions regarding
the DNA proposal have been answered.

What I'd like to do now is to ask questions about message
formats and text, in a way which reinforces the hard work
undertaken by the DT.

Here's Q number 1:

Is there a DNA option format which we can agree upon which
preserves Prefix alignment on 8 octet boundaries?

I guess alignment is desirable to allow consistency with
earlier specifications 2461, 3810, and potentially allow
word-size based operations on some hosts.

At the moment, the option format contains a list of
sequential 17 octet records.

With 2 prefixes, the current format 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Len 1  |               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
   |                                                               | 

   +                                                               + 

   |                                                               | 

   +                       Prefix 1                                +
   |                                                               |
   +                                               +-+-+-+-+-+-+-+-+ 

   |                                               | Prefix Len 2  | 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | 

   +                                                               +
   |                                                               |
   +                       Prefix 2                                + 

   |                                                               |
   +                                                               + 

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Padding (32bits)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Erik has convinced me of the need to support 128 bit
prefixes in DNA, for future expansion, but it may be
possible to achieve this while preserving alignment.

One variant makes use of the ordering of prefixes and
their lengths but uses two separate lists (one for
the lengths and one for the prefixes.  Pad is introduced
at the end of the list of prefix lengths, instead
of at the end of the option.

I'll call this Variant #1:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | Prefix Len 1  | Prefix Len 2  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Padding (32bits)                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | 

   +                                                               + 

   |                                                               | 

   +                       Prefix 1                                +
   |                                                               |
   +                                                               + 

   |                                                               | 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | 

   +                                                               +
   |                                                               |
   +                       Prefix 2                                + 

   |                                                               |
   +                                                               + 

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's also possible to have differing storage for
prefixes, so long as it is 8 octet aligned:

The differing legnths of prefix mean that a number of prefixes
indication is required a the front of the prefix length list,
to remove ambiguity (it's not inferred just by the option length).

I'll call this variant 2:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     | #  prefixes   | Prefix Len 1  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Prefix Len 2  |            Padding (24 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               | 

   +                                                               + 

   |                                                               | 

   +                       Prefix 1 (128 bits)                     +
   |                                                               |
   +                                                               + 

   |                                                               | 

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Prefix 2 (64bits)                       + 

   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Variant 1 (along with the current option format) has
the advantage that records are constant length, and that
the prefix lengths don't have to be read in order to
locate any particular prefix.

Variant 2 has the advantage that if the prefix length is
less than or equal to 64 (today's common case), the
storage used is only 8 bytes.  A host would have to read
the list of prefix lengths in order to parse the prefixes though.

Does anyone have an opinion as to whether a change to the
DNA option would be good or not?

Please respond indicating if you like any of the
existing proposals (Current, Variant 1 or Variant 2),
or prefer something different.

Greg

---

From: Brett Pentland <[email-masked]>
Date: Mon, 23 May 2005 16:10:07 +1000

Hi Greg,

We started discussing the DNA option format, but didn't settle on
a fix before needing to get the document out to the WG.  I think
either of these options would be an improvement.

Variant 2 would save quite a few bytes in the common case where
64-bit prefixes are used.  I'd be in favour of it.

Brett.

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 23 May 2005 09:07:09 -0700

> or prefer something different.

I think either one is an improvement over the current one in the draft. 
Whether we want the smaller #2 option (with a bit more complexity) 
depends on how important we think it is to minimize the size of the DNAO.

The DNAO is only sent by a routers when not all routers on the link are 
configured to advertise the same set of prefixes. However, RFC 2461 does 
allow that the routers advertise different sets of prefixes. I'd suspect 
that in all well-run IPv6 networks the routers advertise the same set of 
prefixes (so that they all can be backups for each other). So optimizing 
the size of the DNAO might not be terribly important.
But I don't have a problem with format #2 - just questioning the 
necessity of minimizing something which might not be used much in the 
real world (but is mostly there to deal with the - perhaps unnecessary - 
generality in RFC 2461).

    Erik

---

From: Greg Daley <[email-masked]>
Date: Tue, 24 May 2005 10:57:37 +1000

Hi Erik,

> real world (but is mostly there to deal with the - perhaps unnecessary - 

I understand that this is not the normal case for IPv6 networks.  My
testbed is currently set up to handle this case though, as one of
the tricky cases in DNA.

I'm not sure if it's terribly important to optimize, other than seeing
a few zeros in the Variant 1 which I implemented before trying Variant
2 (since #1 was slightly easier).

Both work though, and I'm happy to go with either.

What's probably most important is that it works with mismatched
(even if poorly configured???) prefixes, rather than worrying about
the size.

If we want to follow the 'keep it simple' principle, then we could
probably choose Variant 1, but keep track of the alternatives in the
issues list.

Does this sound like a good idea?

Greg

---

From: Ranjitsinh Wable <[email-masked]>
Date: Tue, 24 May 2005 16:47:03 +0530

Hi Greg,

If my understanding is correct we can analyse three prefix options as
follows.

Current format:  does not suit bcoz of the 8 byte alignment.
But it has good characterstic of having the prefix length for each of the
prefix mentioned just before the prefix. So processing is easier.

About varient 1: What if the number of prefixes exceed the 6? I know still
We can add the additional 8 bytes for the prefix length with appropriate 
padding.
to start prefix on 8 byte alignment. also we can find the starting of the 
prefix information
using length field in the DNAO and assuming the length of each prefix as 
128.

About varient 2: Again the same problem when number of prefixes exceed 5.
(again same solution can do). Here the additional problem is that - How we 
will decide the
length of the prefix exactly represented. Shall we assume whenever the 
length is less than or equal to
64 bits  it will be always 8 bytes? In that case: If in future a need arised 
to advertise
16 bytes to represent the address even though the prefix is 64 bit. (Same as 
'R' bit in MIPv6).
Then with this approach we are restricting such possibility.

IMHO, desired features could be:
1) 8 byte alignment. (I think 4 byte alignment is also fine)
2) Save bytes when the prefix length is less than or equal to 64 bit.
3) Can represent prefix with 64 and 128 bit even the though the prefix 
length is less than 64.
4) Easy for processing.

In this respect we can make changes to varient 2 to have prefix 
representation of any bytes.
OR come up with different variant.

Let me know your opinion on the same.

Thanks and Regards,

Wable R. U.

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 24 May 2005 11:56:16 -0700

> Does this sound like a good idea?

Works for me.

Hopefully we'll then get some more WG feedback whether it is worth 
making the DNAO smaller for prefixes <= 64 bits.

    Erik