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

Ryuji Wakikawa <ryuji@sfc.wide.ad.jp> Tue, 26 July 2005 13:55 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPtv-0004Nc-TD; Tue, 26 Jul 2005 09:55:19 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxPtt-0004N3-Lr for monami6@megatron.ietf.org; Tue, 26 Jul 2005 09:55:17 -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 JAA19443 for <monami6@ietf.org>; Tue, 26 Jul 2005 09:55:16 -0400 (EDT)
Received: from yui.nc.u-tokyo.ac.jp ([130.69.251.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxQOu-00052T-Vl for monami6@ietf.org; Tue, 26 Jul 2005 10:27:24 -0400
Received: from ryuji-no-powerbook-g4-15.local.sfc.wide.ad.jp (sphinx.lix.polytechnique.fr [129.104.11.1]) (authenticated bits=0) by yui.nc.u-tokyo.ac.jp (8.12.10/8.12.3/Debian-6.4) with ESMTP id j6QDsg64008451; Tue, 26 Jul 2005 22:54:44 +0900
Date: Tue, 26 Jul 2005 22:54:35 +0900
Message-ID: <m2oe8pn04k.wl%ryuji@sfc.wide.ad.jp>
From: Ryuji Wakikawa <ryuji@sfc.wide.ad.jp>
To: marcelo bagnulo braun <marcelo@it.uc3m.es>
Subject: Re: Terminology and scenario (wasRe: [Monami6] about draft-montavont-mobileip-multihoming-pb-statement-05current)
In-Reply-To: <850d5b952f4fb41a55716b18fecdae42@it.uc3m.es>
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>
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/22.0.50 (powerpc-apple-darwin8.1.0) MULE/5.0 (SAKAKI)
Organization: Keio University/WIDE
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
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 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).

> 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..
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?

So is there any possible issue here?

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