Re: Re: [NSIS Mobility draft] Updating from -07 to -08

Hi Jukka,

see comment inline.

Jukka MJ Manner wrote:
> On Thu, 15 Nov 2007, Roland Bless wrote:
> 
>> Hi Jukka,
>>
>> [I'm taking this to the list now...]
>>
>> Jukka MJ Manner wrote:
>>> I think we are talking about the same thing. The main point is that if IP 
>>> addresses change, the MRI is invalidated, and the QNI must then, in one 
>>> way or another be notified. There must be (otherwise nothing works) some 
>>> mobility signaling where the QNI gets to know the new IP of the MN, and 
>>> can then reissue a RESERVE with a new MRI.
>> Ok, however, I believe that your proposed solution doesn't work:
>> you proposed to send a NOTIFY towards the CN. This will require usage
>> of the new flow's MRI and the resulting GIST Query must be sent in
>> _upstream_ direction, i.e., PC-MRI(CN->MN-newCoA, D-Flag=1) - upstream.
>> Now there is the problem of choosing the correct encapsulation for the
>> Query: only _upstream_ Q-mode encapsulation would be an option, but this
>> is not appropriate to use in this case due to its limited applicability
>> to certain environments. Even if the MN could send the NOTIFY to its
>> new access router (QNE4 below), there is no routing state installed yet
>> in upstream direction in QNE4, i.e., it doesn't know any next peer
>> in upstream direction, so only upstream Q-mode could be used, but that
>> is not really applicable in this case. So only the last paragraph of
>> section 4.3.3 applies:
>>    o  If no routing state exists, GIST can attempt to use Q-mode as in
>>       the Query case: either sending a Data message with the Q-mode
>>       encapsulation, or using the event as a trigger for routing state
>>       setup (see Section 4.4).  If this is not possible, e.g. because
>>       the encapsulation for the MRM is only defined for one message
>>       direction, then this is an error condition which is reported back
>>       to the local signalling application.
>>
>> So an error will be reported back to the application.
>> As a conclusion: sending a NOTIFY in upstream direction does not
>> work along paths that have no routing state yet.
> 
> 
> [JM]: If the CN requests reliable or secure transport, GIST will send an 

I don't know what it has to do with reliable and secure transport?

> empty Query to the next, set up routing state, and only then send the 
> NOTIFY. This will hit QNE4. Now QNE4 does not know about the SID in 
> question, so should it send an error back, or forward the message in the 
> same way towards the CN? 

Please read the above text again. The problem lies in the fact that
you have to send a GIST-Query _upstream_ and no routing state exists
yet. So even if an MA exists, it cannot be used.
This could only be done with _upstream_ Q-mode encapsulation, but this
is definitely not applicable in a general way.

> [JM]: Yet, also with unreliable/unsecure transport, what would happen, if 
> QNE4 would actually decide not to peer? It sees a NOTIFY for a SID it 
> doesn't know about, so it could as well forward the message further, 
> right? The message will eventually hit a QNE (or eventually the CN), who 
> then knows about the SID.

See above. The GIST Query has to find its way first. This is the real
problem.

Regards,
 Roland