Re: [nemo] About BA status 141

Koshiro MITSUYA <mitsuya@sfc.wide.ad.jp> Thu, 23 October 2003 07:27 UTC

Date: Thu, 23 Oct 2003 16:26:05 +0900
Message-ID: <s3vllrce7oy.wl@wanwan.sfc.wide.ad.jp>
From: Koshiro MITSUYA <mitsuya@sfc.wide.ad.jp>
To: Alexandru Petrescu <petrescu@nal.motlabs.com>
Cc: Noriaki Takamiya <takamiya@po.ntts.co.jp>, nemo@ietf.org
Subject: Re: [nemo] About BA status 141
In-Reply-To: <3F96B65E.4040006@nal.motlabs.com>
References: <20031022.185854.846933446.takamiya@po.ntts.co.jp> <3F96A4AA.5000105@nal.motlabs.com> <20031023.014612.607960534.takamiya@po.ntts.co.jp> <3F96B65E.4040006@nal.motlabs.com>
User-Agent: Wanderlust/2.8.1 (Something) EMIKO/1.14.1 (Choanoflagellata) LIMIT/1.14.7 (Fujiidera) APEL/10.3 Emacs/20.7 (sparc-sun-solaris2.8) MULE/4.0 (HANANOEN)
Organization: Keio University
MIME-Version: 1.0 (generated by EMIKO 1.14.1 - "Choanoflagellata")
Content-Type: text/plain; charset="US-ASCII"
Sender: nemo-admin@ietf.org
Errors-To: nemo-admin@ietf.org
Precedence: bulk

Hi all, 

In my implementation, HA has a table which includes "capable" mobile
network prefixes which is statically configured by manager. I mean
"capable" that the prefix can be routed and managed by this HA.

If HA receive invalid prefix, "invalid" means not-capable-mobile
network prefixes, HA return 141.  Then MR may try another HA on the HA
list. (I haven't implemented this re-try part yet.)

If a similar entry already exists in the table, MR overwrite the entry
by new BU. Otherwise Alexandru said he guesses that HA return BA with
status 141. I don't know which is good behavior..

thanks,
Koshiro


At Wed, 22 Oct 2003 18:54:54 +0200,
Alexandru Petrescu wrote:
> 
> Noriaki Takamiya wrote:
> >   IMHO, I thought that HA must check if it can forward to the mobile
> >   network prefix or not(e.g. using ICMP echoreplay) after
> >   configuration for forwarding.
> > 
> >   I recognize that the check using ICMP is not realistic.
> 
> Of course it depends.  The idea of checking connectivity with echo 
> request/reply comes to mind immediately when thinking about 
> reachability.  For example RR tests of Mobile IPv6 are a sort of just 
> that: check routability between CN, MN and HA.
> 
> On another hand, a very early version of draft-kniveton-mobrtr had a 
> sort of check echo req/rep too from HA to MR, IIRC.  Then it was no 
> longer proposed, probably because being an ICMP message does not give 
> real reliable indication ("reply" can be lost now and not 10s later).
> 
> With failing Mobile IPv6 RR tests, there's a backup: use bidir tunnel 
> instead of using RO.  With failing req/rep from HA to MR there is no 
> backup, HA simply informs the MR 141.
> 
> Or something like that...
> 
> Alex
> GBU
> 

---
Koshiro Mitsuya
  Jun Murai lab. Graduate School of Media and Governance,
  Keio University.
  5322 Endo, Fujisawa-shi, Kanagawa 252-8520, Japan.
  Phone : +81-466-49-1100  Fax   : +81-466-49-1395
  E-mail: mitsuya@sfc.wide.ad.jp
  HP    : http://www.sfc.wide.ad.jp/~mitsuya/
  key fingerprint = 3487 88C9 B9AA 3BFC B5CF  D479 5466 0680 98C0 9202

[nemo] About BA status 141 Noriaki Takamiya
Re: [nemo] About BA status 141 Alexandru Petrescu
Re: [nemo] About BA status 141 Noriaki Takamiya
Re: [nemo] About BA status 141 Alexandru Petrescu
RE: [nemo] About BA status 141 Soliman Hesham
Re: [nemo] About BA status 141 Koshiro MITSUYA
Re: [nemo] About BA status 141 Vijay Devarapalli
RE: [nemo] About BA status 141 Soliman Hesham
Re: [nemo] About BA status 141 Vijay Devarapalli