Subject: Re: [MEXT] RFC3775 update - Simultaneous Mobility

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Jul 2008 11:02:07 -0700

Hello Ashutosh,

Ashutosh Dutta wrote:
>
>> Did I miss anything? Based on the above, I have a few questions:
>>
>> - If we need to specify something new action on this, should this action 
>> be triggered by (a) data traffic or (b) lack of response to RR packets?
>>     
>
> Ans> It should be triggered by lack of response to RR packets.
>   

What if the mobile node used some perceived loss of data traffic as
a trigger to retry the return routability signaling?

>   
>> - Or is it simply wrong to attempt to do the signaling to the peer's 
>> care-of address, maybe we should require doing it via the home address 
>> instead?
>>     
>
> Ans> Yes, it is better to do it via the home address. 

Maybe it would be better to go by way of the home
address only after signaling to the correspondent's care-of
address fails once.

I think it is agreed that this is a rare scenario, and so we
should not penalize the overwhelming preponderance of
cases when there is a simple remedy for errors in the
rare case.

>   
>> - Why is this issue specific to simultaneous movement? Wouldn't it 
>> happen also if the peer rebooted and got a new address, as well?
>>     
>
> Ans> I think this problem could be applied to other scenarios that you 
> have described as well. Also, it is a matter of timing.
>   

In the case of reboots, there isn't much hope for
continuity of real time communications.  So I would
expect all binding cache entries and so on to be
lost and/or invalidated in this situation.  So I do not
think the same solution would be applicable.

Regards,
Charlie P.

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Jul 2008 11:33:49 -0700

Hello folks,

It seems to me that this does not need to
have an issue created in the tracker.  But if
I'm wrong, let me know and I'll collect
the discussion and create a new ticket.

Regards,
Charlie P.

Alexandru Petrescu wrote:
> Jari Arkko wrote:
>> Alex,
>>
>>> YEs, it was item 1: referenced spec (rfc2473) does have the words 
>>> about the possibility to copy the TC/Flow labels or insert 
>>> pre-configured values.  However, at least one widespread 
>>> implementation doesn't implement the latter feature.
>>>
>>> I think if some implementers realize there may be some issue in
>>> which qos is used with mip6 then we may need to clarify 3775.
>>> Otherwise, if in practice this  aspect was not identified by some
>>> implementers then we may continue as now until the need becomes
>>> apparent.
>> I understand what you want to do. But if our situation is that 
>> implementors are ignoring IETF RFCs, its not going to be helped by 
>> publishing more RFCs. And including things in category 1 would be a 
>> never-ending task. Lets focus on the other categories where we can 
>> actually add some value. And hopefully because of you raising this
>> issue now here on the list some implementors are now going back to
>> fix their code :-)
> 
> I agree on the value adding part and I somehow disagree suggesting stuff
> to implementers.  I am here to suggest back stuff to specifiers.
> 
> I often notice differences between what's being specified and what's
> getting widely implemented.  Protocols don't make it to even a WG item
> yet get deployed, and Proposed Standards protocols whose implementation 
> is still to happen - but I disgress.
> 
> Let me stop commenting on this and come back to Chair's reminder on 
> 3775bis next steps.
> 
> Alex
> 
> 
> ______________________________________________________________________
> This email has been scanned by the MessageLabs Email Security System.
> For more information please visit http://www.messagelabs.com/email 
> ______________________________________________________________________