Re: FW: [Monami6] FW:I-DACTION:draft-hong-multipleif-mn-pb-statement-00.txt

[Nicolas Montavont <[e-mail]>]

Hi,

Just few remarks inline.

[...]

>>
>>Comments inline, but first, I would like to point out that a new version
>>of draft-montavont-mobileip-multihoming-pb-statement (i.e. -05) has been
>>sent Monday, but not yet announced (we hope it to be renamed to
>>draft-montavont-monami6-multihoming-pb-statement)
>>
>>Here is the link:
>>http://www.nautilus6.org/doc/drafts/draft-montavont-monami6-multihoming-
>>pb-statement-05.txt
>>http://www.nautilus6.org/doc/drafts/draft-montavont-monami6-multihoming-
>>pb-statement-05.html
>>    
>>
I just get a response from the secretariat, and the new revision will be 
draft-montavont-mobileip-multihoming-pb-statement-05.txt, because we 
couldn't change the name. Sorry for that.

[...]

>>>
>>>=============================================================
>>>
>>>In my draft, I describe some practical problems.
>>>
>>>1. Mobile IPv6-specific Issues
>>> : When a mobile node has multiple interfaces, it must have the
>>> ability to
>>>look at
>>>  all RA messages from multiple network interfaces to determine
>>>  network
>>>movement.
>>>      
>>>
>>The problem you describe in your draft is an implementation specific
>>issue, as pointed out by Romain Kuntz.
>>
>>In draft-montavont, we have a section "considerations for MIP6
>>implementation". So, at best some text could be added there.
>>    
>>
Using RA reception to determine a movement or even to determine the 
availibility/unavailibility of an interface is an information that we 
want to consider in general. Note that in our revision, we changed media 
detection to failure detection, in order to consider all failure that 
can occur on the entire path between the MN and its CN. It can be on the 
media (interface connected or not at L2, or no IPv6 prefix on the link), 
or a failure on the path between the MN and the HA, or between the HA 
and the CN.

So, for me, RA reception is part of failure detection. We may have to 
add text to explicitly mention that it is considered. Anyway, I think we 
have lot of work to clarify failure detection.

>>    
>>
>>>2. General network Issues
>>> : The mobile node also must update the relation between a destination
>>>address and
>>>  a network interface when it changes a network interface.
>>>      
>>>
>>The problem yoiu describe in your draft is related,  when considering a
>>mobile node, to  the HoA address, and you ranged it into a "generic
>>issue" because it can apply to a fixed node with multiple interfaces,
>>right?  I think this is a problem in which SHIM6 is qualified (how
>>to change the locator, but not the identifier).
>>    
>>
>
>Even though this problem that end node should update the relation between
>destination address and specific network interface to prevent dissonance
>between active network interface and changed IP address was happened in
>fixed end node, I do not agree that the SHIM6 should qualify this problem.
>
>AFAIK, SHIM6 is considering environment where an end node has multiple paths
>(multiple IPv6 address prefix) by connecting to different ISP that means
>site multihoming. So site multihomed an end node does not have necessarily
>multiple interfaces and it only has to obtain multiple addresses from
>different site exit routers. But the mobile node equipped multiple
>interfaces are down for discussion in MONAMI6 WG clearly.
>
>Therefore, if we have consensus, which this problem must be solved for using
>multiple interfaces, I think that the MONAMI6 is more suitable place than
>SHIM6.
>  
>
Can you clarify what you mean by "the MN also must update the relation 
between a destination address and a network interface when it changes a 
network interface?

A "destination address" is a CN address, or a CoA?

[...]

Regards,

Nicolas

_______________________________________________
Monami6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/monami6