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

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

Hi Brett.

Thanks for this.

In case people aren't aware I'm travelling to Cairns next week
(hat off again) to the IEEE wireless (802.21/802.11) interim meeting.
It's a chance to express opinions just before my e-mail
becomes intermittent.

Brett Pentland wrote:
[cut]
>> 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).
> 
> 
> Yes, the primary reason for it being there was for a fallback when the
> unicast response isn't possible.

I guess that if we're prepared to accept "no additional prefixes" option
as a tax for solicited RAs even if there's no requested landmark (even 
if it's multicast),  Then the DNAO could be used as both completeRA and
landmarking solution, without consuming RA header bits.

Please note that I'm not worried about completeRA for unsolicited RA,
or even the "Completeness" part, although that's neat.

What I'm thinking of is:

Here are a bunch of prefixes I've learned are on the link: it didn't
cost me much more to send them (even if the set is incomplete).

[cut]
>>
>> So the option contents are the same, I guess the option should be
>> too.
> 
> 
> They are the same if you don't use the yes/no flags for answering
> the landmark question.  If you do, then you need to tie the flags to
> a particular prefix in the option (maybe there is only one in that
> case) or match the RS/RA with a nonce as you suggest below, and the
> overload get a bit uglier.


Well, if you guarantee a "MUST" on the requested prefix if it is known,
then it doesn't matter with overload.  You'd just advertise "I'm
overloaded, please don't infer that the prefix is absent".

Note that overloaded is different to "decided not to advertise".

>>> 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).
> 
> 
> It's true that you can match responses with a SEND nonce, but I
> wouldn't call this a faked up response match because response
> matching was not the primary goal.  The matching is being done
> between the answer and the question, and one could argue that it's
> cleaner doing that match fully contained within the RA, rather than
> across the RS/RA using a nonce.

Well I thought SEND was a SHOULD anyway.

If we SHOULD send it it will already be present in most RS's,
nodes interested but otherwise unwilling to implement SEND
may be able to buy in at a fairly low cost (16 octets over the
combined RS/RA).

Reception of an RA with your nonce means that other information,
like which question you were asking (is this a valid prefix?)
Don't need to be contained in the message.

The gain may be considered to be marginal, except that the
"No" response is required (perhaps in a separate option), every
time movement occurs.  That's the case to optimize...

Sure the host would have to remember the question, to match the Nonce,
but I'd argue that it probably would anyway, in order to modify state.

Plus the nonce makes a good basis for a hash lookup key ;)

Greg