[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Issue 6: DNAHostLinkIDList
- To: JinHyeock Choi <jinchoe@gmail.com>
- Subject: Re: [DNA] Issue 6: DNAHostLinkIDList
- From: Sathya Narayanan <sathya@research.panasonic.com>
- Date: Fri, 26 Jan 2007 15:04:16 -0500
- Cc: Dna <dna@eng.monash.edu.au>
- In-reply-to: <45704479.8060209@Research.Panasonic.COM>
- Organization: Panasonic Technologies Company
- References: <45537A0D.3020009@Research.Panasonic.COM><92e919fb0611162105x39e4fa03u8f9a07c4ec7f27e6@mail.gmail.com><455DDE50.7010204@Research.Panasonic.COM><92e919fb0611200137r174a212apadc4ca2bacbf262f@mail.gmail.com><456F85D1.30509@Research.Panasonic.COM><92e919fb0612010333ob58c56eo827a74128e6126bd@mail.gmail.com><45704479.8060209@Research.Panasonic.COM>
- Sender: owner-dna@ecselists.eng.monash.edu.au
- User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
This is the last email on this subject I can find on the list.
I am going to close this issue, removing LinkID from the solution while
making sure that the points raised by JinHyeock are covered in the text.
I still haven't closed Issue 2:, changes to support Stateful
autoconfiguration scenario. The current text depends on DHCP CONFIRM to
address this scenario. I am still uncomfortable requiring configuration
of each router on the link with the smallest prefix - a sysadmin then
becomes responsible for keeping track of the smallest prefix and
updating the configuration each time. Depending on DHCP CONFIRM is a
more dynamic solution, imho. I will close this later on, after I do
one-on-one discussion with a few people.
Hopefully, I will submit a new version before the end of next week.
Thanks,
Sathya
Sathya Narayanan wrote:
> 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
>
>