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 14:20 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQI8-00030W-Ob; Tue, 26 Jul 2005 10:20:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxQI6-00030M-M9 for monami6@megatron.ietf.org; Tue, 26 Jul 2005 10:20:18 -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 KAA21992 for <monami6@ietf.org>; Tue, 26 Jul 2005 10:20: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 1DxQn8-0005rt-Jv for monami6@ietf.org; Tue, 26 Jul 2005 10:52:25 -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 j6QEK264010976; Tue, 26 Jul 2005 23:20:04 +0900
Date: Tue, 26 Jul 2005 23:19:55 +0900
Message-ID: <m2mzo9myyc.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: <18685b1c18ef785603a019264b44428d@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> <m2oe8pn04k.wl%ryuji@sfc.wide.ad.jp> <18685b1c18ef785603a019264b44428d@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="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21be852dc93f0971708678c18d38c096
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

Hello Marcelo

At Tue, 26 Jul 2005 16:11:49 +0200,
marcelo bagnulo braun wrote:
> 
> 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.

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, we have to consider a nice HoA selection mechanism. But i
think it can be achieved by MN receiving ICMP error messages.

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