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

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

>>> 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).

Yes, the primary reason for it being there was for a fallback when the
unicast response isn't possible.

> 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.

Yes, and this is why we originally had it there.  The result of our
discussion was that since the RA is not complete and the host would not
be able to make a decision based on that RA alone, there wasn't all
that much value in it.  If folks think that the assistance this provides
in building a CPL is worthwhile, it could be put back.

>>> 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.

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.

>> 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.

Brett.