Re: [DNA] Issue 6: DNAHostLinkIDList

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

Greg -

There was a discussion on this (may be within the DT). It was the 
dormant node argument why we decided to keep a 1.5 hours overlap, I 
think. It is the same condition the current draft uses when a prefix is 
reassigned, using 1.5 hour overlap with old prefixes. If we change that 
for the LinkID, we should change it for the prefix reassignment also. I 
also agree with JinHyeock about the dormant node problem.

- Sathya
> Hi Sathya,
>
> It's not necessary to have a DNAHostLinkIDList and send the old LinkID
> prefix
> for 1.5 hours.
>
> Routers advertising the next three RAs rapidly (including both prefixes
> in either
> a PIO or LPO) after a link ID change would be sufficient.
>
> This could be analogous to the changes in prefixes advertised in Prefix
> Lists as in RFC 2461.
>
> Any prefix in common between a new received RA and the DNAHostPrefixList
> will
> merge them, and most listening hosts would be fixed up by the
> readvertisement of
> the routers across 15 seconds or so (having received both the old and
> new LinkIDs).
>
> Stragglers will only perceive change erroneously if the RA has no prefixes
> in common with the DNAHostPrefixList and their existing prefix list is
> considered complete.  Otherwise they will solicit and determine which
> prefixes
> exist on-link (or use a landmark).
>
> My gut reaction is that including the second LinkID for 1.5 hours
> further diminishes
> the optimization's usefulness.
>
> Greg
>
>
> ----- Original Message -----
> From: Sathya Narayanan <sathya@research.panasonic.com>
> Date: Friday, December 1, 2006 12:34 pm
> Subject: Re: [DNA] Issue 6: DNAHostLinkIDList
> To: JinHyeock Choi <jinchoe@gmail.com>
> Cc: Dna <dna@eng.monash.edu.au>
>
>   
>> 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?
>>
>> - Sathya
>>
>> JinHyeock Choi wrote:
>>     
>>>> I can't see how you can remove the DNAHostLinkIDList without 
>>>>         
>> removing>> the concept of LinkID itself. As I mentioned in issue 2, 
>> we will mandate
>>     
>>>> the inclusion of the "smallest" prefix in the RA, particularly the
>>>> multicast RA, and achieve the advantage of LinkID, but remove the
>>>> complexity. I am not 100% sure about this either, but I can't think
>>>> anything wrong with doing this. Lets think it over.
>>>>         
>>> I am ok to remove DNAHostLinkIDList but am not sure about removing
>>> 'LinkID' itself. I agree that we would think this over further.
>>>
>>> Best Regards
>>>
>>> JinHyeock
>>>       
>>