Subject: RE: [mobile-ip] AD question on the "I" bit in draft-ietf-mobileip -reg-revok-04.txt

From: "Kuntal Chowdhury" <[email-masked]>
Date: Tue, 24 Dec 2002 11:20:52 -0600

> Steven M. Glass wrote:
> 'I' bit at revoke time would then be a lot simpler:
> 
>          FA revoking:
>              'I' bit set to '0', HA has no options
>              'I' bit set to '1', HA's ACK means:
>              HA ack:
>                  'I' bit set to '0', don't inform the MN
>                  'I' bit set to '1', do inform the MN
> 
>          HA revoking:
>              'I' bit set to '0', FA shouldn't inform the MN *
>              'I' bit set to '1', FA should inform the MN
>              FA ack:
>                  'I' bit set to '0', I didn't inform the MN
>                  'I' bit set to '1', I did inform the MN
> 
>          * note this case is the "MN no longer at your location"
> 
>      Does this make more sense to everyone?
> 
>                                Cheers,
>                                    Steve
> 
I agree with the text proposed above. The following is my attempt to clarify
the scenarios:

FA revoking:
	I-bit set to '0' : MN cannot be notified. (possible reasons: local
policy, link already disconnected etc.).
	I-bit set to '1' : MN can be notified. Wait for confirmation from
HA.
	HA Ack:
		I-bit set to '0' : FA should not notify MN (possible reason:
local policy).
		I-bit set to '1' : FA should notify the MN.

HA revoking:
	I-bit set to '0' : FA should not notify MN (possible reasons: local
policy, movement detected etc.).
	I-bit set to '1' : FA should notify the MN.
	FA Ack:
		I-bit set to '0' : MN not notified (possible reasons: local
policy, link disconnected, MN did not respond etc.)
		I-bit set to '1' : MN was notified.

If we have more than one bit, then it will be easy for a mobility agent to
specify the exact reason for not notifying an MN to the other mobility agent
(e.g. local policy, link already disconnected, movement detected etc.).
Otherwise, one of the mobility agent will not know why the MN was not
notified.
 
-Kuntal

---

From: "Steven M. Glass" <[email-masked]>
Date: Tue, 24 Dec 2002 13:43:33 -0500

<gratuitous>
     Comments in-line...
     </gratuitous>

On Tuesday, December 24, 2002, at 12:20  PM, Kuntal Chowdhury wrote:

> I agree with the text proposed above. The following is my attempt to 
> clarify the scenarios:
>
> FA revoking:
>         I-bit set to '0' : MN cannot be notified. (possible reasons: 
> local policy, link already disconnected etc.).
>         I-bit set to '1' : MN can be notified. Wait for confirmation 
> from HA.
>         HA Ack:
>                 I-bit set to '0' : FA should not notify MN (possible 
> reason: local policy).
>         I-bit set to '0' : FA should not notify MN (possible reasons: 
> local policy, movement detected etc.).
>                 I-bit set to '0' : MN not notified (possible reasons: 
> local policy, link disconnected, MN did not respond etc.)
>

     We had rejected the 'I' bit set to '0' in the FA's revocation 
message to indicate "I won't notify the mobile node".  What if the FA's 
local policy is to always inform the MN, how would it convey that to 
the HA using the above table (you'd need either two-bits, or worse an 
ack-ack)!

> If we have more than one bit, then it will be easy for a mobility 
> agent to specify the exact reason for not notifying an MN to the other 
> mobility agent (e.g. local policy, link already disconnected, movement 
> detected etc.). Otherwise, one of the mobility agent will not know why 
> the MN was not notified.

     Yes, we'd have to add an 'information' field (note, it's NOT an 
error).  We thought through this at one point, too.  My take on this, 
though, is the reason for this is beyond the scope of mobile ip, 
because this is the end of the mobile ip session.  Returning errors are 
good for re-synchronizing, whatever, but in the case of revocation the 
binding is over, so the reason for dropping is beyond the control of 
the agent receiving the revocation notice.  The reason for such a 
revocation could be obtained from e.g. AAA, as it would be part of 
accounting, etc, records, and an agent should likely use that mechanism 
to obtain this information (that is from AAA's perspective Mobile IP is 
another service; when your telnet session drops, you don't get notified 
to the specifics, it's just reset).  My first thought was it would be 
useful, too, but thinking about it longer I developed this opinion.  
There are few parallels between why the FA revokes, and why the HA 
revokes, so the 'information' space is almost entirely disjoint, and 
where it isn't such reasons supersede the agents. e.g. AAA related 
(something else telling the agents to revoke).

                               Cheers,
                                   Steve