Subject: [DNA] Issue 6: DNAHostLinkIDList

From: Sathya Narayanan <[email-masked]>
Date: Thu, 09 Nov 2006 13:57:17 -0500

Issue: Even though the issue was framed differently at the beginning of 
the meeting, at present the issue is: Can we remove the idea of 
DNAHostLinkIDList from the solution? Advantages of removing is obviously 
simplicity, both in logic and the text. The disadvantage in removing it 
is that the presence of LinkIDs allows for some kinda forward 
compatibility for future links which may have non-prefix link IDs.

Agreement at the meeting: Lets remove LinkID list from the solution. 
Forward compatibility can be easily supported by the LPO. Non-prefix 
linkIDs can be advertised on the LPO - since entries in LPO cannot be 
used for address configuration, it won't cause any problems - the only 
condition is that the non-prefix LinkIDs MUST be in a different 
number-space - this can be achieved by requiring that non-prefix LinkIDs 
MUST be 128 bits.

This change simplifies the host operation logic and the text in terms of 
maintaining multiple lists (DHAHostPrefixList and DNAHostLinkIDList).

Any objections?

-Sathya

---

From: JinHyeock Choi <[email-masked]>
Date: Fri, 17 Nov 2006 14:05:36 +0900

> maintaining multiple lists (DHAHostPrefixList and DNAHostLinkIDList).

Allow me a clarifying question.

Do you propose to remove only 'DNAHostLinkIDList' or 'LinkID' itself?
We can keep the 'LinkID' notion, even if we delete 'DNAHostLinkIDList'
by, maybe, putting a flag for a LinkID prefix in DNAHostPrefixList.

In case of the first, I agree. In case of latter, I need to think it
over mover.

Best Regards

JinHyeock

---

From: Sathya Narayanan <[email-masked]>
Date: Fri, 17 Nov 2006 11:07:44 -0500

JinHyeock -

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.

- Sathya

---

From: JinHyeock Choi <[email-masked]>
Date: Mon, 20 Nov 2006 18:37:26 +0900

> 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: Sathya Narayanan <[email-masked]>
Date: Thu, 30 Nov 2006 20:30:57 -0500

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