Subject: Re: [DNA] Issue 6: DNAHostLinkIDList

From: Greg Daley <[email-masked]>
Date: Fri, 01 Dec 2006 16:51:16 +1100

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 <[email-masked]>
Date: Friday, December 1, 2006 12:34 pm
Subject: Re: [DNA] Issue 6: DNAHostLinkIDList
To: JinHyeock Choi <[email-masked]>
Cc: Dna <[email-masked]>

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

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 01 Dec 2006 20:33:29 +0900

Dear Sathya

> Since I didn't hear any other objections, I am going start closing the
> 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
> If the smallest prefix was first seen within 1.5 hours ago, then the
> If the second smallest prefix was first seen within 1.5 hours ago, then
> And so on... (I don't like that this is open ended, but thats how things
> If not a completeRA, same rules as above to include the smallest prefix(es).
>
> 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
> removes the need for a DNAHostLinkIDList, thus simplifying the operation
> 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
> 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

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

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 01 Dec 2006 20:33:40 +0900

Greg

> a PIO or LPO) after a link ID change would be sufficient.

What if an MN is in dormant mode and misses those 3 RAs? Then after
waking up, the MN may make a wrong decision.

Best Regards

JinHyeock

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 01 Dec 2006 10:04:25 -0500

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

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 01 Dec 2006 10:00:03 -0500

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