[netext] AD review of draft-ietf-netext-bulk-re-registration

[Jari Arkko <[e-mail]>]

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