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

[Sri Gundavelli <[e-mail]>]

Hi Jari:

Thanks for the review. Please see inline.



On 11/22/11 5:52 AM, "Jari Arkko" <[e-mail]> wrote:

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

I agree, :) it is not entirely accurate. Will fix it.

 
>> 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:
> 

We allowed both the nodes to perform group operations. A given session may
be assigned a MAG-specific group identifier and also an LMA-specific group
identifier. Probably it needs corrections in couple of places and in the
illustration. 



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

I think its a very small change needed to support two group identifiers for
a given session, I can go over the spec and fix it. If you agree.


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

Yes. It is a fact that the LMA can support bulk binding operations and that
this session is part of that list. Will reword it.



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

OK.

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

I agree, this needs to be fixed. Between the Flag and the option, we need to
tighten the text on the usage.


> 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:
> 

Agree, its not clear. We will fix it.



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

Sure. 


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

Sure.

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

We can add a condition that this is relevant only if the (P) flag is set.


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

If the new flag/option is not present, we will be updating 5213/5844. I'll
check and see if we are updating the base procedures.

Regards
Sri


> Jari
> 
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext