Re: [DNA] Design Team solution 1: Question about DNA Option

[Greg Daley <greg.daley@eng.monash.edu.au>]

Hi Brett,

Please be aware that any hats I have are off,
and I'm trying to work on engineering issues,
providing personal opinions.

Brett Pentland wrote:
> Greg Daley wrote:
> 
>> from draft-pentland-dna-protocol-00.txt:
>>
>> Section 4.3:
>>
>> The learned prefixes in the DNA option are not
>> 8 octet aligned, and include prefix lengths.
> 
> 
> Yes this is something that needs more thought.
> 
>> Assuming that advertised prefixes are global
>> addresses, can't the prefixes be:
>> 1) 8 octet aligned and
> 
> 
> Probably necessary.
> 
>> 2) 8 octets (64 bits) long
>>
>> With no prefix length field.
>>
>>  From RFC 3513 (S2.5.1):
>>
>>    For all unicast addresses, except those that start with binary value
>>    000, Interface IDs are required to be 64 bits long and to be
>>    constructed in Modified EUI-64 format.
> 
> 
> Does this imply that all advertised prefixes MUST be 64 bits long?
> If so it would simplify the DNAO considerably.

2462Bis Section 5.5.3 talks about this in some detail.

The prefixes in PIOs in 2462Bis are described as being potentially
variable length.

What would be sufficient here is to use the DNAO header to identify
the number of 64 bit prefixes present in the option (which would
consume a portion of the option's size), with the
space after that explicitly ignored.

This would allow for arbitrary sized prefixes later, and not penalize
existing 3513 compliant systems which advertise 64 bit IIDs (and 64 bit
Prefixes), except for 8 bits which are reserved (out of 40).


>> This would lead to 6 octets overhead (which is the minimum additional
>> cost when you consider the size of prefix lengths).
>> One of those octets could indicate the known number of prefixes,
>> and the option length could indicate how many prefixes are advertised
>> (effectively indicating if the RA is complete or not when the PIOs
>> are counted).
> 
> 
> The known number of prefixes is something which we had in there and
> removed.  The thinking was that if the number didn't match the number of
> prefixes in PIOs and the DNAO, then it wasn't really much use, and thus
> its function was no greater than a "complete" bit.  That bit could go in
> the DNAO, but then the DNAO would need to be included, even when there
> were no learned prefixes (ie. when routers all advertise the same set of
> prefixes on a given link).  This would then mean that 64 bits were
> being included to carry one bit of information.

Well the document either does CompleteRA (on every unsolicited RA) now,
or it has a prefix landmark in it.

The benefits of putting the completeness information into all the
unsolicited RAs is of very marginal benefit (only helps for
packet loss, since the initial assumption of the document is that
L2 hints are available).

The solicited RAs then already have space for either a landmark or
a completeRA (DNA) Option.  Each of the specifications will have
wasted space, which can be put to use for other purposes.

It's actually not one bit of information either.

The fact that a host knows all the number of prefixes but can't fit
them in an RA can be used to compose a complete prefix list which is
provably (with SEND) complete.  At least the MN can stop hunting for new
prefixes if in the responses from two or more routers, it can see that
a conjoined (and complete) set of prefixes is available.

>> This would remove the need to get two bits from the RA header in the
>> case of
>>
>> Also, if there is a requested landmark prefix, could it not appear
>> in the DNA option, even if the option is does not provide complete RA?
>> The minimum NACK for an unknown landmark would then be 8 octets
>> (no prefixes in the list), on top of the existing RA.
>>
>> The DNA option could then be used in both solicitor and receiver.
> 
> 
> Yes, I think this could be done.  It would be overloading two separate
> functions on the DNAO.  Does it provide some advantage to do this?

Yes.

One option is defined for solicitor and receiver.

The storage of the prefixes for both completeRA and Prefix Landmarks
are the same (they both collect a list of prefixes).

The selection of a prefix from the known prefix set for transmission
is just an ordering issue (for example, if it's not possible to transmit
the whole set).

So the option contents are the same, I guess the option should be
too.

> As the draft stands, we have two modes of operation and the Landmark
> Option is used for one, and the DNA Option for the other.  The preferred
> mode is a unicast response.  The host uses a Landmark Option to ask
> if a prefix is being advertised on a link, and any router can unicast a
> response including a Landmark Option indicating yes or no for that
> prefix.  The DNA Option is used in multicast RAs as a fallback position
> when a unicast is not possible (due to rate limiting or insufficient
> information).  It allows the RA to contain enough information for hosts
> to be able to make a decision on their own.  The intention is that this
> is a fallback position, however, and that the normal state of affairs
> would be a simple "Is prefix X being advertised on this link?" - "Yes,
> prefix X is" or "no, prefix X isn't".

I don't like the yes/no either.

Well, SEND already has better response matching than this
using its Nonce Options (which are mandaroty for SEND responses).

It's also possible to use this without SEND as detailed in:

draft-daley-dna-nonce-resp-01.txt

Sorry about the self plug, but I think it's a good solution.

(much cleaner than the yes/no as a faked up response match).

Greg