Subject: [nemo] About BA status 141

From: Noriaki Takamiya <[email-masked]>
Date: Wed, 22 Oct 2003 18:58:54 +0900 (JST)

Hi,

  I'm sorry, but I have a simple question.

  In draft-ietf-nemo-basic-support-01.txt, BA status code 141 is defined.

  I wonder how HA decides to send BA with status 141.

  For example, when MR sends BU with explicit or Explicit Prefix
  Length mode, HA process this BU as following(section 6.2):

  1)check H bit in BU
  2)check the contents of BU
  3)verify the mobile network prefixes using Prefix Table
    ->If failed, HA returns BA with status 142.
  4)try to setup forwarding to all prefixes listed in BU.
    ->If failed, HA returns BA with status 141.

  In 4), what does HA verify?

  Does 'fail' mean that HA couldn't just configure the
  forwarding(e.g. reverse tunneling or setup routing table)?

  IMO, almost misconfigured prefix in BU will result in status 142.

  What is the situation that HA could return 141?

  If I misunderstand, correct me.

  regards,

--
Noriaki Takamiya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2003 17:39:22 +0200

>   forwarding(e.g. reverse tunneling or setup routing table)?

I guess so. For example if a similar entry already exists in the table,
or if the prefix is larger than 128.  No?

(prefix len can be larger than 128 by error because encoded on 8bit 
instead of 7 because easier to program).

Alex
GBU

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2003 17:39:22 +0200

Alex
GBU

---

From: Noriaki Takamiya <[email-masked]>
Date: Thu, 23 Oct 2003 01:46:12 +0900 (JST)

Hi,

>> Wed, 22 Oct 2003 17:39:22 +0200
>> [Subject: Re: [nemo] About BA status 141]
>> Alexandru Petrescu <[email-masked]> wrote...

petrescu> I guess so. For example if a similar entry already exists in the table,
petrescu> or if the prefix is larger than 128.  No?
petrescu> (prefix len can be larger than 128 by error because encoded on 8bit 
petrescu> instead of 7 because easier to program).

  I see. Thank you for your advice.

  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.

  Regards,

--
Noriaki Takamiya

---

From: Noriaki Takamiya <[email-masked]>
Date: Thu, 23 Oct 2003 01:46:12 +0900 (JST)

Hi,

  Regards,

--
Noriaki Takamiya

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2003 18:54:54 +0200

>   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

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 22 Oct 2003 18:54:54 +0200

Alex
GBU

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 23 Oct 2003 16:26:05 +0900

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,
> Or something like that...

---
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: [email-masked]
  HP    : http://www.sfc.wide.ad.jp/~mitsuya/
  key fingerprint = 3487 88C9 B9AA 3BFC B5CF  D479 5466 0680 98C0 9202

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 23 Oct 2003 16:26:05 +0900

Hi all, 

thanks,
Koshiro

---
Koshiro Mitsuya