Mobility Header Home Agent Switch Message
draft-ietf-mip6-ha-switch-06

[Ballot discuss]
>      o The packet MUST be authenticated, either by the home agent to
>        mobile node IPsec ESP authentication SA for integrity
>        protection, or a home agent to mobile node authentication
>        option.

What other than RFC 4285 does the second half of that clause refer to?

[Ballot comment]
Dan holds the combined DISCUSS now.

Section 2.3, paragraph 0:
>    2.3 Maintenance

  I do believe that using this message for occasional, manually
  initiated maintenance purposes may be useful. My DISCUSS is on using
  this message in an automated fashion for load balancing or overload
  handling, without specifying how this is supposed to occur.

[Ballot discuss]
Section 2 - changing the home agent can be a pretty
  disruptive event for a mobile host and its ongoing transport
  connections, especially if this causes its home address to change. I
  hence question the usefulness of this message for load balancing or
  overload handling. Yes, it will allow the home agents to reshuffle
  which mobile nodes they serve, but at great disturbance to the mobile
  nodes' connectivity. The mechanism around using this message for load 
  balancing or  overload handling arid underspecified.


Section 6 - Operational Considerations

  > This document does not specify how an operator might use the Home
  Agent Switch message in its network.  However, it might be the case
  that a home agent provides service for many thousands of mobile
  nodes.  Care should be taken to reduce the signaling overhead
  required for handing off many mobile nodes to an alternate home
  agent.

This section seems to me vague and underspecified. Actually Section 2 provides a number of scenarios about what how the HA switch message may be used. What is missing are some more specific recommendations about where each of the scenarios apply and what possible algorithms would be used for scenarios like load balancing.

Also the recommendation about reducing signaling overload is too general and not clear, is this overload on the HA, network or on the alternate home agent?

[Ballot discuss]
6. Operational Considerations

  This document does not specify how an operator might use the Home
  Agent Switch message in its network.  However, it might be the case
  that a home agent provides service for many thousands of mobile
  nodes.  Care should be taken to reduce the signaling overhead
  required for handing off many mobile nodes to an alternate home
  agent.

This section seems to me vague and underspecified. Actually Section 2 provides a number of scenarios about what how the HA switch message may be used. What is missing are some more specific recommendations about where each of the scenarios apply and what possible algorithms would be used for scenarios like load balancing. Also the recommendation about reducing signalling overload is too general and not clear, is this overload on the network or on the alternate home agent?

[Ballot comment]
Section 2.3, paragraph 0:
>    2.3 Maintenance

  I do believe that using this message for occasional, manually
  initiated maintenance purposes may be useful. My DISCUSS is on using
  this message in an automated fashion for load balancing or overload
  handling, without specifying how this is supposed to occur.

[Ballot discuss]
Section 2., paragraph 0:
>  2. Scenarios

  DISCUSS: As I understand it, changing the home agent can be a pretty
  disruptive event for a mobile host and its ongoing transport
  connections, especially if this causes its home address to change. I
  hence question the usefulness of this message for load balancing or
  overload handling. Yes, it will allow the home agents to reshuffle
  which mobile nodes they serve, but at great disturbance to the mobile
  nodes' connectivity. (I also agree with David that the mechanisms
  around using this message for load balancing or overload handling are
  underspecified.)

[Ballot discuss]
> 2.5 Home Agent Renumbering

Reference to RFC4192 in order somewhere in here?

>      Section 6.2 of [2].  The receiver MUST ignore and skip any options
>      with it does not understand.

s/with/which

>    If no home agent addresses and no options are present in this
>    message, no padding is necessary and the Header Len field in the
>    Mobility Header will be set to 0.

Which padding, exactly, is this referring to? Please be normative here about when Reserved fields are present, and when they are not. Refer to the field as described in the document, not indirectly as "padding."

>  In most cases, the home agent addresses in the Home Agent Switch
>    message will be of other home agents on the home link of the mobile
>    node.  In this case, the mobile node SHOULD select a new home agent
>    from the addresses as they are ordered in the list.  If the first
>    address in the list is unable to provide service, then the subsequent
>    addresses in the list should be tried in-order.

If you are going to strongly suggest choosing addresses in order, perhaps you should populate the values with some bit of randomness. Otherwise, you are not going to get a good balancing of sessions, and potentially end up in a case where clients walk through a number of HAs before they reach one that is "able to provide service"

I don't see a good description of how to indicate whether an HA is available or not. Is there some "temporarily unavailable due to lack of resources" message that is expected but not specified? Is there a timeout based on dropped packets?

>  Choosing a home agent not on the home link might
>    require a change of the home address for the mobile node, which could
>    cause a loss of connectivity for any connections using the current
>    home address.

This would seem to be counter to the whole premise of Mobile IP. Is this really allowed?

[Ballot discuss]
I don't understand how overload messages work and how if a HA is overloaded, it would have the ability to wait to retrans vs potentially just drop.

Given the spec doesn't cover (and states that it won't) how this message is to be used, it seems underspecified with respect to the semantics of the messages covered in the scenarios section.

[Ballot discuss]
The reference to RFC 4285 is exactly the sort of reference that is
inappropriate under that document's IESG note.

The MIP6 working group needs to stop referring to alternate security
mechanisms in its spec, or (preferably if people are going to continue
to want them) actually do the work described in the RFC 4285 IESG
note.

Please remove all reference to RFC 4285 and any implications that MIP6
supports security mechanisms other than IPsec.

Again, I have no particular attachment to IPsec, but I do have a
strong attachment to actually designing MIP6 to have multiple security
mechanisms if you are going to do so.

[Ballot comment]
From Gen-ART review by Gonzalo Camarillo.

  The terminology section is typically a different section after the
  Introduction. In this draft, it is an unnumbered section after the
  Abstract.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Mobile IPv6 parameters - per [RFC3775]" registry
located at
http://www.iana.org/assignments/mobility-parameters
sub-registry "Mobility Header Types - per [RFC3775]"

Value Description Reference
----- --------------------------- ---------
TDB Home Agent Switch Message [RFC-mip6-ha-switch-03]

We understand the above to be the only IANA Action for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Document shepherd: Basavaraj Patil
I have reviewed this I-D and believe it is ready for IESG review and
publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed as part of the WG last call. It has
also been discussed previously and been presented to the WG in several
meetings. I do not have any concerns about the depth or breadth of the
reviews that have been performed.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

I believe that the document has been reviewed sufficiently and there
is no need for further reviews or to broaden the scope of the
reviews. The complexity of the I-D and enhancement to base MIP6 being
proposed in this I-D is fairly small and hence the current level of
reviews is sufficient.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

No issues or concerns exist with this I-D.


(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

There is strong WG consensus on this I-D. I believe the WG (majority)
understands this I-D and the need for the extension being proposed.


(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

No discontent has been expressed about this I-D in the WG. There has
been no issue about appeals against the I-D being made.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

I have verified the I-D via the ID-nits checker and it has reported no
errors.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

References have been split into normative and informative
sections. There are no normative references which are not ready for
advancement at this time.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG
Evaluation?

The IANA considerations section exists and is satisfactory. The
document does not propose any new registries.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

This question is not applicable to the current I-D. There are no MIB
definitions, BNF rules or XML code in this I-D.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document specifies a new Mobility Header message type that can
be used between a home agent and mobile node to signal a mobile node
that it should acquire a new home agent.

Working Group Summary

This I-D has been presented to the WG and discussed in WG meetings
several times. There is strong consensus on the need for the message
extension being specified in this I-D.

Document Quality


No known implementations of this protocol extension exist at the
present time. However there is interest by several vendors in
implementing this extenstion. All the relevant reviewers have been
acknowledged. The I-D has not been reviewed by MIB doctors since it
does not specify a MIB.

Personnel

Document Shepherd: Basavaraj Patil
Responsible AD: Jari Arkko