Re: [DNA] [Issue X] LinkID v.s. Landmark Prefix

[Brett Pentland <brett.pentland@eng.monash.edu.au>]

Hi JinHyeock,

>>>By adding another router and a few more packet losses, we can make
>>>a pathological case with a problem.
>>
>>Can you provide an example?
> 
> 
> ok. I admit this is a crude one but all I can think of right now.  
> (Because it's not clear to me how a host base its decision 
> on CompleteRA, I switch to landmark one.) 
> 
> Assume a link with two routers R1 and R2 and a host H. 
> R1 advertises Prefix1 and R2 Prefix2. 
> 
> R2 stops advertising Prefix2 and starts advertising Prefix3. 
> R2 announces the prefix change by sending an RA but
> both R1 and H don't receive it. 
> 
> Then H happens to change its AP in the same link 
> and send an RS with landmark Prefix2. It also happens that 
> R2 replies first and sends an RA with NO and Prefix3. 
> H falsely assumes a link change.  

I think you might have found one :)  Actually, there was some
discussion recently on whether a NO answer should only include
explcitly configured PIOs or should include a DNA option as well.
You may have found a good reason to include the DNA option.

In this case the DNAO in the NO answer would include P1 which would
allow the host to correctly recognise that there has been no change.

>>>Then next time H receives CompleteRA with
>>>Prefix2, it will falsely assume a link change.
>>
>>Actually not; if will only assume a link change if it receives a link up
>>event notification between the last time it heard a RA with Prefix1 and
>>the first time it heard an RA with Prefix2.
> 
> 
> The above is not clear to me yet. Allow me a question to help 
> my understanding.  
> 
> Assume a host moves to a different link but fails to receive a 
> Link Up event Notification. Then the host will not assume a link 
> change even if it receives a different unsolicted CompleteRA? 

As written, I don't think the draft ties the decision making to a link
layer indication.  In the instance you brought up an incorrect decision
would be made.  However, this is the pathological case I mentioned the
other day and the fix is the same as for LinkID.  That is, to require
the router to advertise both prefixes (or in fact just some overlap in
the sets of prefixes) for some period of time.  There is nothing
fundamental about LinkID that lets it cope with this situation.  It's
just that the LinkID draft has a bit of text that says not to do that.

Brett.