Re: Terminology and scenario (wasRe: [Monami6] about draft-montavont-mobileip-multihoming-pb-statement-05current)

[Ryuji Wakikawa <[e-mail]>]

Hi Marcelo

On 2005/07/27, at 0:29, marcelo bagnulo braun wrote:

>
> El 26/07/2005, a las 16:19, Ryuji Wakikawa escribió:
>
>>>>> I will only consider CoAs, now.
>>>>> Suppose that you have a given visited network, which is  
>>>>> multihomed to
>>>>> ISPA and ISPB, and each one of the ISPs has delegated a prefix  
>>>>> i.e.
>>>>> PrefA and PrefB
>>>>>
>>>>> The MN arrives to the visited network and configures one CoA  
>>>>> from each
>>>>> prefix, let's say PrefA:MN and PrefB:MN
>>>>>
>>>>> The situation then is:
>>>>>
>>>>>
>>>>>         +---------------------+
>>>>>         | Rest of the Internet|---------|
>>>>>         +---------------------+         |
>>>>>           |                 |          +----+
>>>>>        +-----+          +-------+      | CN2|
>>>>>        |ISPA |          | ISPB  |--|   +----+
>>>>>        +-----+          +-------+  |
>>>>>           |                 |     +----+
>>>>>         +---------------------+   | CN1| PrefB:CN1
>>>>>         | Visited Network     |   +----+
>>>>>         |    PrefA    PrefB   |
>>>>>         +---------------------+
>>>>>                 |
>>>>>              +-----+
>>>>>              |  MN | CoA1: PrefA:MN
>>>>>              +-----+ CoA2: PrefB:MN
>>>>>
>>>>> Now consider the case where the link between ISPB and the rest  
>>>>> of the
>>>>> internet fails
>>>>> Which addresses does MN has to use in order to maintain a
>>>>> communication
>>>>> with CN1? and with CN2?
>>>>>
>>>>> With CN1, the only path available between CN1 and the MN is  
>>>>> through
>>>>> ISPB, so the MN must use PrefB:MN as CoA for this communication
>>>>>
>>>>
>>>> I think PrefB:MN can be selected according to the same mechanism of
>>>> IPv6 source address selection. (i.e. by Address longest match).
>>>>
>>>>
>>>
>>> right
>>>
>>>
>>>>> With CN2, the only path available between CN2 and the MN is  
>>>>> through
>>>>> ISPA, so the MN must use PrefA:MN as CoA for this communication
>>>>>
>>>>
>>>> It depens on where the HA is located, but..
>>>>
>>>
>>> right
>>>
>>>
>>>> When the MN attempts to use PrefB:MN, it fails to send CoTI/HoTI  
>>>> and
>>>> will
>>>> not receive CoT/HoT.  Therefore, it will give up using PrefB:MN and
>>>> will
>>>> pick up PrefA:MN. right?
>>>>
>>>>
>>>
>>> ok, this is interesting, since the HoTI/HoT CoTI/CoT message  
>>> could in
>>> fact be used, as you mention, as a mechanism to explore paths
>>>
>>>
>>>> So is there any possible issue here?
>>>>
>>>>
>>>
>>> i don't know, but maybe it is worth exploring a bit further...
>>> The point in this scenario is that you need to use different CoAs to
>>> communicate with different CN.
>>>
>>
>> OK.
>>
>>
>>> I mean, only the following combination of address work:
>>> - PrefB:MN, CN1
>>> - PrefA:MN, CN2
>>>
>>> The other two combinations, i.e. PrefA:MN, CN1 and PrefB:MN, CN2  
>>> don't
>>> work
>>>
>>> So, when the MN is in RO mode, it would need to use different  
>>> CoAs with
>>> different CNs, which i am not sure it is supported...
>>> in particular, which CoA will the MN register in the HA in this
>>> scenario?
>>>
>>
>> To send CoTI for both PrefA:MN and PrefB:MN, the MN must register the
>> CoAs to HA (i.e. MCoA). The MN may stop using RO mode and sends
>> packets through its HA.
>>
>>
>>> I guess that only one CoA will be reachable from the HA, depending
>>> whether the HA is in ISPB or somewhere else.
>>>
>>
>> right. However, the MN will know the destination unreachable by
>> receiving ICMP error messages.  Then, the MN should use different HA
>> (i.e. HoA) for the unreachable destination.
>>
>>
>>> But in any case, maybe more inteligence in the CoA selection may be
>>> needed for this case...
>>>
>>
>> If we need to consdider the case where HA lost reachability to a
>> destination,
>>
>
> ok, this is another good point that is that the MN through one of  
> its CoAs can reach the CN but the HA cannot.

Yes. But I am not sure if it is worth to see this problem.

>
>>  we have to consider a nice HoA selection mechanism. But i
>> think it can be achieved by MN receiving ICMP error messages.
>>
>>
>
> First of all, imho having a fault tolernace mechanism (such as a  
> multihoming mechanism) based on ICMP unreachable mechanism seems  
> not a good idea (AFAIK, relying in ICMP has been discarded in MIPv6  
> design and in multi6 design, becuase ISMP are filtered too often to  
> rely on them)

Right, at least MN can have some notification from networks such as  
ICMP error messages, no response from the destination, etc.
If we can assume RO, HoTI will not be delivered to the destination  
due to HA reachability lost. That's another choice.

> So i would not count on ICMPs
> I would use them as hints, but i wouldn't asume that they will be  
> there and base the mechanism on it.

yes, these are hints.

> Second, i guess we need to explore the different scenarios in more  
> detail but at least, i would like to know if we agree that the  
> reachability property is related to an address pair, an not to a  
> given HoA or CoA.

> I mean, it is not good to say, "ok, i will use this CoA because it  
> it reachable", but what would be more appropriate would be to say  
> "this CoA is reachable from this particular CN address" and maybe  
> for a different CN, a different CoA is needed.

This shouldn't be happened in the Internet.

If we consider such scenarios., there are more complicated case.
Ex. CoA-x is reachable for the traffic using port-xxx, but CoA-y is  
not due to port filtering.

> The idea is to talk about working address pairs, rather than a  
> reachable address
>
> Is this good?

You want to use  reachability to the destination as a selection  
parameter?
IMO, from end nodes, the reachability to a destination should be assumed
if the end node has connectivity to the Internet.

ryuji


> regards, marcelo
>
>
>
>> ryuji
>>
>>
>>> Regards, marcelo
>>>
>>>
>>>> regards,
>>>> ryuji
>>>>
>>>>
>>>>
>>>>> (this is site multihoming example adapted to mobile host  
>>>>> multihoming,
>>>>> sorry for that, but there maybe better examples that express this
>>>>> situation in a more relevant fashion for this case)
>>>>>
>>>>> Regards, marcelo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Nicolas
>>>>>>
>>>>>> _______________________________________________
>>>>>> Monami6 mailing list
>>>>>> [e-mail]
>>>>>> https://www1.ietf.org/mailman/listinfo/monami6
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Monami6 mailing list
>>>>> [e-mail]
>>>>> https://www1.ietf.org/mailman/listinfo/monami6
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>


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