Re: [DNA] Issue 6: DNAHostLinkIDList

[Sathya Narayanan <sathya@research.panasonic.com>]

Dear JinHyeock:

You are right. The DNA bit in the RA should be enough to take care of 
non-DNA router messages. If the host doesn't find a prefix in a DNA-RA 
that is already in the DNAHostPrefixList, it can conclude that it has 
changed link - and it would be correct. If it is a non-DNA-RA, it should 
fall back on CPL or wait for another DNA-RA. I will make sure that the 
text is written accordingly.

- Sathya

> Dear Sathya
>
>> Since I didn't hear any other objections, I am going start closing the
>> issues using the suggested changes, except for this issue on
>> DNAHostLinkIDList.
>>
>> My proposal for removing DNAHostLinkIDList is as follows:
>> We remove the concept of identifying a particular prefix as LinkID
>> prefix and mandate the inclusion of the smallest prefix in all RA
>> messages. On the host side, we only need to check if there is a prefix
>> included in the RA that is in the DNAHostPrefixList. This will work if
>> we make sure that when there is a change in the smallest prefix, the RA
>> includes the previous smallest and the current smallest (similar to what
>> is done when the LinkID changes now). So, the algorithm will be:
>>
>> For non-landmark RA or a NO landmark response:
>> Router SHOULD try to send a completeRA.
>> If the completeRA is not possible due size restriction, the RA MUST
>> include the smallest prefix.
>> If the smallest prefix was first seen within 1.5 hours ago, then the
>> second smallest prefix MUST be included in the RA.
>> If the second smallest prefix was first seen within 1.5 hours ago, then
>> the third smallest prefix MUST be included in the RA.
>> And so on... (I don't like that this is open ended, but thats how things
>> are right now with including LinkIDs)
>>
>> For unsolicited RA:
>> MAY be a completeRA.
>>
>> If not a completeRA, same rules as above to include the smallest 
>> prefix(es).
>>
>> What I am trying to do here should be obvious. The functionality is
>> exactly the same as the LinkID component of the current draft, but there
>> is no explicit marking as such and more importantly no explicit LinkID
>> check at the host. The overlapping prefix check covers that for us,
>> removes the need for a DNAHostLinkIDList, thus simplifying the operation
>> significantly on the host side.
>>
>> For future non-prefix linkIDs, they can be included in the LPO and they
>> MUST be 128 bits long. Since LPO cannot be used to configure addresses
>> this won't cause any trouble and cannot overlap with other prefixes
>> since they are 128 bits.
>>
>> I would like to know if people think this is workable - am I overlooking
>> something?
>
> I think the above is workable but have a few concerns.
>
> 1.
>
>>                                                     This will work if
>> we make sure that when there is a change in the smallest prefix, the RA
>> includes the previous smallest and the current smallest (similar to what
>> is done when the LinkID changes now). So, the algorithm will be:
>
> For the above, DNA routers should manage "the smallest prefix list"
> which it recently advertised.
>
> 2. RA should include the indication that this RA includes the smallest 
> prefix.
>
> A DNA router and a non-DNA router may co-exist on a link. If the
> non-DNA router advertises an RA without the smallest prefix, that may
> cause a host to make a mistake.
>
> The inclusion of the smallest prefix can be indicated with
> either 1) DNA router bit in RA or 2) a new bit in PIO.
>
> For the first, a host assumes that the RA from the DNA router includes
> the smallest prefix automatically.
>
> For the second, a host assumes that the RA includes the smallest
> prefix only when there is a smallest prefix bit in PIO/ or LPIO.
>
> Thanks for your kind consideration.
>
> Best Regards
>
> JinHyeock