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

marcelo bagnulo braun <marcelo@it.uc3m.es> Tue, 26 July 2005 14:11 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQA2-0007xF-Hs; Tue, 26 Jul 2005 10:11:58 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQA0-0007x3-Rh for monami6@megatron.ietf.org; Tue, 26 Jul 2005 10:11:56 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21017 for <monami6@ietf.org>; Tue, 26 Jul 2005 10:11:53 -0400 (EDT)
Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQf1-0005Zg-LN for monami6@ietf.org; Tue, 26 Jul 2005 10:44:01 -0400
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 09FDA49FD2; Tue, 26 Jul 2005 16:11:37 +0200 (CEST)
Received: from [163.117.139.55] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.55]) by smtp03.uc3m.es (Postfix) with ESMTP id 731CD4A209; Tue, 26 Jul 2005 16:11:36 +0200 (CEST)
In-Reply-To: <m2oe8pn04k.wl%ryuji@sfc.wide.ad.jp>
References: <9e17e93da6b53232f0cd5b57c1ebfaf8@it.uc3m.es> <42DFC8B2.50807@nist.gov> <591f88572dde333f5b46a020483002f2@it.uc3m.es> <42E050C2.6040704@nist.gov> <ebc039fcc4767cc2350f3fe3236cb1af@it.uc3m.es> <42E0FEDE.4040505@nist.gov> <850d5b952f4fb41a55716b18fecdae42@it.uc3m.es> <m2oe8pn04k.wl%ryuji@sfc.wide.ad.jp>
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Message-Id: <18685b1c18ef785603a019264b44428d@it.uc3m.es>
Content-Transfer-Encoding: quoted-printable
From: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: Terminology and scenario (wasRe: [Monami6] about draft-montavont-mobileip-multihoming-pb-statement-05current)
Date: Tue, 26 Jul 2005 16:11:49 +0200
To: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 789c141a303c09204b537a4078e2a63f
Content-Transfer-Encoding: quoted-printable
Cc: Monami6 BOF proposal <monami6@ietf.org>
X-BeenThere: monami6@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: Monami6 BOF proposal <monami6@lists.ietf.org>
List-Id: Monami6 BOF proposal <monami6.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/monami6>
List-Post: <mailto:monami6@lists.ietf.org>
List-Help: <mailto:monami6-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/monami6>, <mailto:monami6-request@lists.ietf.org?subject=subscribe>
Sender: monami6-bounces@lists.ietf.org
Errors-To: monami6-bounces@lists.ietf.org

Hi Ryuiji,

very good points, some comments below

El 26/07/2005, a las 15:54, Ryuji Wakikawa escribió:

>
> Hi Marcelo
>
> At Fri, 22 Jul 2005 16:41:19 +0200,
> marcelo bagnulo braun wrote:
>>
>>> This is a very intersting distinction that we should take into
>>> account. I am thinking to multiple coas registration / flows 
>>> filtering
>>> here, where only one address pair becomes unreachable  (let say CoA1
>>> <-> CN1) and not other pairs using CoA1. We need a mechanism to 
>>> change
>>> the registered CoA1 with CN1, without modifying other bindings 
>>> related
>>> to CoA1. This is one more reason why it would be useful to be able to
>>> independantly manage CN/flows.
>>>
>>
>> since you find it interesting, i will move to ascii art to put a 
>> simple
>> example of a situation where this could happen
>>
>> 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.

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?
I guess that only one CoA will be reachable from the HA, depending 
whether the HA is in ISPB or somewhere else.
But in any case, maybe more inteligence in the CoA selection may be 
needed for this case...

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
>>> Monami6@lists.ietf.org
>>> https://www1.ietf.org/mailman/listinfo/monami6
>>>
>>
>>
>> _______________________________________________
>> Monami6 mailing list
>> Monami6@lists.ietf.org
>> https://www1.ietf.org/mailman/listinfo/monami6
>>
>


_______________________________________________
Monami6 mailing list
Monami6@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/monami6