Subject: RE: [mobile-ip] draft 15

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Thu, 22 Nov 2001 17:21:45 +0100

A couple more points to add:

- A BU replaces the existing one. So if the MN
  sends a BU without the H flag it should really
  replace the existing BU. 

- The scenario may need some clarification in the
  draft, because there maybe cases where the 
  MN actually has a connection with the HA (the HA
  is my PC at home). In this case we need to define
  the behaviour of the HA, ie. :
  - Send packets with the router header for traffic 
    initiated from within the HA.
  - intercept and tunnel packets as usual.

Hesham

  > -----Original Message-----
  > From: Francis Dupont [mailto:[email-masked]]
  > Sent: Thursday, November 22, 2001 5:01 PM
  > To: [email-masked]
  > Subject: Re: [mobile-ip] draft 15 
  > 
  > 
  > => initial question:
  > 
  >   >Section 8.3:
  >   >Some HA (also being a CN) receives a BU without H-bit 
  > from a node already
  >   >registered _with_ the H-bit set.
  >   >What would be a sensible reaction?
  >   >1) Stop intercepting packets and just work as a usual CN
  >   >2) Ignore the missing H-bit in the BU
  >   >3) ?
  > 
  >    => Why don't we go for 2) ? 
  >    The effect would be that the HA will continue to intercept
  >    packets and if corresponding with the MN, the applications
  >    will still work. 
  > 
  > => to send back an error won't flush the binding cache entry.
  > 
  >    The issue here is how to avoid the tunnel interface. 
  >    
  > => it seems the MN has to cleanly delete its home registration first
  > (i.e. 1) is hard to implement (according to HA implementers here)
  > and this MN behavior is not natural: something is wrong and this
  > has to be signaled back to the MN).
  > 
  > Regards
  > 
  > [email-masked]
  >

---

From: Francis Dupont <[email-masked]>
Date: Thu, 22 Nov 2001 18:15:06 +0100

=> this the option 1) but here HA implementors said this is hard to
implement and this should never happen.

=> this behavior is already defined if you add the home agent address
(the address the MN knows to be its HA address, the HA may have other
addresses and for them it is a regular CN for the MN, in fact usually
the MN doesn't know the other addresses).
Section 9.4 begins with a statement about section 8.9 applicability,
the only not-very-clear answer is about packets from HA with other
source addresses (routing-header or tunnel) but Peter Grimstrup's
question is about a Home Registration followed by a Binding Update
to the *same* address!
   
Regards

PS: about other addresses of a multi-addressed CN the consensus in
this list is to manage binding cache per address in order to allow
the MN to get a fine control of the care-of address it want to use.
But the current spec has enough flexibility: one can implement what
he wants without to trap by a sequencing bug or all bad things
that can happen with a careless shared binding cache.
I don't believe this has to be changed...

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 22 Nov 2001 16:20:01 -0800

hi,

I would support option 3. send an error status in a binding ack
to the MN. this is easier to implement.

vijay

---

From: "Peter Grimstrup (TED)" <[email-masked]>
Date: Fri, 23 Nov 2001 08:52:23 +0100

> implement and this should never happen.

A second opinion from a HA-implementor: Actually, we have without much
trouble implemented option 1) - before thinking about the problem,
I raised in my mail. Generally, I favour explicit actions/protocols,
thus I tend to favour (a little) the proposed option 3), i.e. return
an error condition, keeping the old BC-entry with the h-bit.

/Peter