Re: [DNA] Issue 6: DNAHostLinkIDList

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

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