Bulk Binding Update Support for Proxy Mobile IPv6
draft-ietf-netext-bulk-re-registration-12

Made an RFC Editor note and responded to IANA's concern. This should be clear now, but waiting for IANA to respond. I also asked ...

Made an RFC Editor note and responded to IANA's concern. This should be clear now, but waiting for IANA to respond.

I also asked Sri if he wants to revise per Pete Resnick's comments. I will also wait for that answer, as well as the possible draft update, before approving the document for good.

[Ballot comment] There are several uses of 2119 language in section 5 and 6 that are inappropriate: 5.1: I have no idea why "The ...

[Ballot comment]
There are several uses of 2119 language in section 5 and 6 that are inappropriate:

5.1: I have no idea why "The following considerations MUST be applied by the mobile access gateway when supporting this specification" is at all useful. The entire sentence should be deleted.

5.1.1: This is worded oddly. It's not that the data structure "MUST be extended", it's that the new fields MUST be included. I think what you probably mean is, "The conceptual Binding Update List entry data structure maintained by the mobile access gateway, described in Section 6.1 of [RFC5213], is extended to include the following REQUIRED additional fields." Of course I assume that they are now "required for interoperation" [2119] or that not having them "has potential for causing harm". [2119] If not, then there shouldn't be 2119 language at all.

5.1.2: As with the opener for 5.1 itself, I don't see what use "MUST apply the following considerations" adds. The requirements are in the paragraphs below. If you don't want to strike the sentence, sufficient would be, "The following are considerations for the mobile access gateway for requesting bulk binding update support for a mobility session."

I think the "MAY" in the first bullet should be "can".

In the last bullet, change "Considerations from section 6.9.1 [RFC5213] MUST be applied" to "The requirements from section 6.9.1 of [RFC5213] apply." Otherwise, what you're saying is "You MUST do everything in section 6.9.1 that says MUST", which seems silly and redundant.

5.1.3: In the first and second bullet, s/MAY/can

Also, the last sentence of the first and second bullets have the same problem as the last bullet in 5.1.2, and I'm not sure I understand what they mean. Perhaps instead, say something like "The requirement of section 5.3.3 of [RFC5213] is amended to allow a Mobile Node Group Identifier in place of the individual session identifiers."


In the third bullet, the MUST seems useless. How could the gateway not "consider the request as a bulk revocation request"?

5.2: Similar to 5.1.

5.2.1: First sentence similar to 5.1.1.

5.2.2: First sentence similar to 5.1.2. But I would simply move the first bullet up into that first sentence so it says:

  5.2.2. Enabling Bulk Binding Update Support for a Mobility Session

      The local mobility anchor will process a received Proxy Binding
      Update message as specified in [RFC5213]. However if the (B)
      flag in the received Proxy Binding Update message is set to a
      value of (1) and if it includes a Mobile Node Group Identifier
      option with sub-type value of (1) (bulk binding update group), the
      following processing takes place:

In sections 6.1 and 6.2, I am concerned about the statements containing "MUST allow the following variables to be configured by the system management" since that seems to go against 2119 where it says that the terms "must not be used to try to impose a particular method on implementors where the method is not required for interoperability." Is there an interoperability reason that these variables MUST be configurable?

Also, the SHOULD and MUSTs in the definition of the variables doesn't seem right. These are not protocol requirements; they are descriptions of the meaning of the variables.

QUESTION: What is the range of possible values for the new registry? Should any values be marked "Reserved" (i.e. unavailable for assignment)? Upon approval ...

QUESTION: What is the range of possible values for the new registry?
Should any values be marked "Reserved" (i.e. unavailable for assignment)?

Upon approval of this document, IANA will complete the following actions:

ACTION 1:

IANA will register the following Binding Update Flag at
http://www.iana.org/assignments/mobility-parameters

B TBD [RFC-to-be]


ACTION 2:

IANA will register the following Binding Acknowledgment Flag at
http://www.iana.org/assignments/mobility-parameters

B TBD [RFC-to-be]


ACTION 3:

IANA will register the following Mobility Option at
http://www.iana.org/assignments/mobility-parameters

TBD Mobile Node Group Identifier [RFC-to-be]


ACTION 4:

IANA will create the following registry at
http://www.iana.org/assignments/mobility-parameters

Registry Name: Mobile Node Group Identifier Type Registry
Registration Procedure: Expert Review
Reference: [RFC-to-be]

Value Description Reference
----- ----------- ---------
0? ?
1 Bulk Binding Update Group [RFC-to-be]
2-? ?


ACTION 5:

IANA will register the following Status Code at
http://www.iana.org/assignments/mobility-parameters

TBD (>128) INVALID_MOBILE_NODE_GROUP_IDENTIFIER [RFC-to-be]

[Ballot comment] Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request ...

[Ballot comment]
Consider making it even more clear that if _any_ circumstance arises in which a group operation might partially fail, the entire group request is rejected. One place to do this is 5.2.3 bullet 4, where you could say "for any reason (including administrative)" instead of "for any administrative reason".

I have reviewed this draft. The draft is almost ready to move forward. Please make a quick revision based on the comments below: > For an ...

I have reviewed this draft.

The draft is almost ready to move forward. Please make a quick revision based on the comments below:

> For an hypothetical scenario, with 500,000 mobility sessions and with
> binding lifetime of 30 minutes, it results in: 500,000 / 1,800 sec =
> 277 transactions/sec
>
> For the above hypothetical scenario, based on the computation, it is
> apparent that the base Proxy Mobile IPv6 re-registration process
> where the mobile access gateway sends a unique binding refresh
> message for each mobility session is inefficient or sub-optimal.
> These re-registration messages consume significant amount of network
> resources, both in terms of processing power and in terms of network
> bandwidth at both the peers.  Therefore it is the intent of this
> specification to optimize the signaling procedures.  These
> optimizations allow the local mobility anchor and the mobile access
> gateway to perform bulk binding update and revocation operations.

This seems a little bit overselling the idea. A 500,000 node gateway will also have some traffic, e.g., if one node out of 100 is doing a 50 packets per second (a voip call), then the entire box does 250,000 packets per second. The network traffic impact part of the signaling is not that big.

Anyway, this is just a comment and not critical in anyway to progressing the draft. But I would add a sentence that the actual impacts depend on capacity required to deal with other issues, such as worst-case movement signalling or payload traffic load.

> The mobile access gateway can also assign a local group identifier
> for the mobility session and include that in the initial request.
> This group identifier may be different from the group identifier that
> the local mobility assigns.  Subsequently, both the peers can perform
> bulk operations on those groups.
> The mobile
> access gateway MAY also choose to request the group identifier
> based on its own grouping consideration, by sending the Mobile
> Node Group Identifier option with the proposed group identifier.
> Upon receiving the Proxy Binding Acknowledgment message with
> status code value set to (0) (Proxy Binding Update accepted), the
> bulk binding update flag (B) in the reply is set to a value of (1)
> and if there is a mobile node group identifier option present, the
> message serves as a hint that the local mobility anchor has
> enabled bulk binding update support for the mobility session and
> that the mobile access gateway MAY use the group identifier when
> requesting binding update or binding revocation operation with
> group specific scope.  The group identifier value in Binding
> Update List entry MUST also be updated to include the assigned
> group identifier.
> o  For enabling the bulk binding update support for the mobility
>    session, the local mobility anchor MAY choose to associate the
>    mobility session to a specific group.  The specific details on how
>    the local mobility anchor associates the given mobility session to
>    a specific bulk binding update group is outside the scope of this
>    document.  The local mobility anchor MAY choose to assign a
>    default group identifier value of (255), indicating that all the
>    mobility sessions from that mobile access gateway are part of that
>    group.  If there is a request from the mobile access gateway to
>    assign a specific group identifier, the local mobility anchor may
>    choose to honor that request.  The assigned group identifier field
>    in the Binding Cache entry is updated with the identifier of the
>    group to which the mobility session is associated.

The first quoted paragraph seems to claim that both sides can group devices per their own desires. This does not seem to be supported by the rest of the specification, as the LMA will override whatever suggestion was made by the MAG. This may be fine, but I would change the first paragraph as follows:

OLD:
The mobile access gateway can also assign a local group identifier
for the mobility session and include that in the initial request.
This group identifier may be different from the group identifier that
the local mobility assigns.  Subsequently, both the peers can perform
bulk operations on those groups.
NEW:
The mobile access gateway can also suggest a local group identifier
for the mobility session and include that in the initial request.
This group identifier may be different from the group identifier that
the local mobility anchor assigns. Subsequently, both the peers can perform
bulk operations on the group identifier confirmed by the local mobility anchor.

> the
> bulk binding update flag (B) in the reply is set to a value of (1)
> and if there is a mobile node group identifier option present, the
> message serves as a hint that the local mobility anchor has
> enabled bulk binding update support for the mobility session and
> that the mobile access gateway MAY use the group identifier when
> requesting binding update or binding revocation operation with
> group specific scope.

AFAICT, this is not a "hint" -- it is a fact. Whether you use it for something is up to you, but the LMA *has* enabled the support. Or am I missing something?

Suggested edit: s/serves as hint/informs the receiver/

> o  If the (B) flag in the received Proxy Binding Update message is
>    set to a value of (1) and if the Mobile Node Group Identifier
>    option is not present in the request, the message serves as a
>    request to the local mobility anchor to include the mobile node's
>    session to the bulk binding update group.

... to *the* bulk binding update group. I think you mean "... to *a* bulk binding update group." In This case there is ID specified, so the LMA has to find a suitable group based on its own preferences.

Similarly, in the next paragraph I would change:

OLD:
  o  If the (B) flag in the received Proxy Binding Update message is
      set to a value of (1) and if the Mobile Node Group Identifier
      option is present in the request, the message serves as a request
      to the local mobility anchor to include the mobile node's session
      to the bulk binding update group, with the proposed group
      identifier present in the Mobile Node Group Identifier option.
NEW:
  o  If the (B) flag in the received Proxy Binding Update message is
      set to a value of (1) and if the Mobile Node Group Identifier
      option is present in the request, the message serves as a request
      to the local mobility anchor to include the mobile node's session
      to a bulk binding update group, with the proposed group
      identifier present in the Mobile Node Group Identifier option.

> Mobile Node Group Identifier  A 32-bit field containing the mobile
> node's group identifier.  The group identifier value of (255) is
> reserved for the group, all the mobility sessions for a given
> mobile access gateway hosted on a given local mobility anchor,
> this is a preassigned group.

Some strange wording. I would also suggest that the value 255 needs to be discussed in the IANA considerations. Also, the value zero seems to be used:

>  The value of the group
>      identifier in the Binding Cache entry must be set to the value of
>      (0).

Please talk about this in the IANA considerations, too. Perhaps you could leave values 1-254 as Reserved for IETF, and then values 256-(2^32-1) as freely usable by implementations. Or something... the current situation is confusing because I don't know how to generate group IDs that do not collide with the ones needed for some special purpose. E.g, on some implementation I might want to use line card ID as the group ID. But then I have to worry about 0.

Missing things:

1) You should specify what to do if the LMA returns a group identifier and sets the B bit without the MAG requesting it to do so. The right action is to ignore this, I think, but you should specify it.

2) You should specify what to do if client MIP operations set the B bit. Some kind of error should be returned, or the flag and option ignored, I think.

3) I think you should add "Updates: RFC 5213, 5846" to the header of the draft. You are changing the procedures for identifying nodes.

Jari

(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 ...

(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?

I (Basavaraj Patil) will be the document shepherd for this I-D.
I have reviewed the I-D and believe it is ready to be forwarded to the
IESG for 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 sufficiently by key WG members. I have
no concerns regarding the depth or breadth of the reviews.

(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 have no concerns with the current set of reviews and do not believe
any further broader reviews are needed. Reviews by the various
directorates during the IETF last call process will anyway help.
The I-D does not have any XML code or internationalization aspects and
hence does not need reviews from experts in that quarter.


(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.

There are no concerns or issues with this document.

(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 sufficient WG consensus behind this document. It has been
discussed within the working group for over 2 years now. The norm has
been that a few WG members are active while most are passive. The
active WG members understand and agree with this I-D.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise 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. There have been no threats of appeals or otherwise w.r.t this I-D.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See the Internet-Drafts Checklist
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?

Yes. I have run the I-D through the ID nits tool and no issues exist.

(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].

Yes, the document has split the references into normative and
informative ones. All references are to published RFCs. There are no
pending dependencies.

(1.i) Has the Document Shepherd verified that the document IANA
consideration 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 [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

The document contains an IANA considerations section with clear
instructions of the actions required by IANA. The specification does
not require a new registry but uses the existing registry and adds new
attributes to that registry.


(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?

The document does not contain any XML code or BNF rules. It does not
contain any MIB definitions either.

(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

For extending the lifetime of a mobility session, the Proxy Mobile
IPv6 specification requires the mobile access gateway to send a Proxy
Binding Update message to the local mobility agent on a per-session
basis. In the absence of signaling semantics for performing
operations with group specific scope, it results in significant
amount of signaling traffic on a periodic basis between a given
mobile access gateway and a local mobility anchor. This document
defines an optimization to the binding update and revocation
operations in Proxy Mobile IPv6 for performing operations with group
specific scope using of a group identifier.


Working Group Summary
There is WG consensus regarding this proposal. The I-D has been
presented and discussed at several WG meetings. It has also been
sufficiently reviewed and the document quality improved over
multiple revisions.

Document Quality
There are no known implementations of this protocol at the present
time. WG members who helped with the reviews have been acknowledged
in the I-D.
The document quality is good and can serve as the basis for an
implementation. Clear guidelines for processing by the Mobile
Access Gateway and the Local Mobility Agent have been specified.