Re: [Mip4] Request to consider "faerr" specification as a working group document
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] Request to consider "faerr" specification as a working group document




Hello Kent,

Thanks for your suggestions in this e-mail from March 16.
I have created a new Internet Draft with the following
changes according to your comments.


Kent Leung wrote:

> 1) In section 4, should the allowable code be just generically in
>      the range of  64-127 (Error Codes from the Foreign Agent)?
>      This avoids having to selectively choose which defined error
>      code is admissible in this extension?  Does it make sense
>      for any code that exists today or will be added in the future
>      to not be carried in the extension?   What happens when
>      event happens with error code that is not allowed, should FA
>      not add the extension or map to some allowable code?


My proposed text comes in two parts.  First, in section 4
just before the list of allowable status codes:

   Status codes allowable for use within the FA Error Extension are
   within the range 64-127.  The currently specified codes are as
   follows:

And, in the IANA considerations:

   The status codes which are allowable in the FA error extension are a
   subset of the status codes defined in the specification for Mobile
   IPv4 [2].  If, in the future, additional status codes are defined for
   Mobile IPv4, the definition for each new status code must indicate
   whether or not the new status code is allowable for use in the FA
   Error extension.

The implication of these sentences is that the specified codes
are the only ones valid today, and that new codes in the
future that are added need to be intentionally made available
for use in the new FA Error extension.


> 2) Should there be a MN Considerations section to specify that
>      MN should deregister an accepted registration (status code
>      0 or 1 from HA) which contains this FA error extension?  This
>      would clean up such condition when HA thinks everything
>      is OK but FA disagree.  Silence by MN provides implicit
>      acknowledgement to HA that FA and MN are OK with the
>      accepted registration reply.  Else MN would notify the HA
>      that FA had problem with the reply.

Here is some proposed text for the new section:

5. Mobile Node Considerations
   
   If a mobile node receives a successful Registration Reply (status
   code 0 or 1), with a FA Error extension indicating that the foreign
   agent is not honoring Registration Reply, the mobile node SHOULD
   then send a deregistration message to the home agent.  In this way,  
   the home agent will not maintain a registration status that is
   inconsistent with the status maintained by the foreign agent.

>      Should the specifics of the
>      FA error code be conveyed to HA by MN? This would allow MN,
>      FA, and HA to log the same error condition.

This might be overkill.  The information is available,
and probably would be transferred out of band somehow.
I didn't think it was worth defining yet another
extension to the Registration Request to carry the
foreign agent's status code, but it could certainly
be done.

I believe these were the only open issues relevant to the
FA Error Extension Internet Draft.  If there are any others,
please let me know right away.  Or, if I need to write some
text to specify the abovementioned extension to the
Registration Request, I can give it a try.

Regards,
Charlie P.

-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.