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

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Nov 2011 05:52:53 -0800

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

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Nov 2011 09:27:39 -0800

Hi Jari:

Thanks for the review. Please see inline.

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

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

> bulk operations on the group identifier confirmed by the local mobility

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.

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

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

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

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Nov 2011 11:00:17 -0800

Sri,

> identifier. Probably it needs corrections in couple of places and in the

You say you allowed, but I don't actually see the functionality. You can have the MAG set it, you can have LMA set it, but it is not possible for *both* to set it. If the LMA wants to dictate group IDs, then the IDs that the MAG used no longer can be used. Or am I missing something?

Jari

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 22 Nov 2011 11:57:37 -0800

Hi Jari:

On 11/22/11 11:00 AM, "Jari Arkko" <[email-masked]> wrote:

> You say you allowed, but I don't actually see the functionality. You can have
> the MAG set it, you can have LMA set it, but it is not possible for *both* to
> set it. If the LMA wants to dictate group IDs, then the IDs that the MAG used
> no longer can be used. Or am I missing something?
> 

My intention was to support the scenario to perform binding operations on
nodes that are hosted on the same application blade/module of the MAG, or on
the LMA. For example, when the MAG creates sessions for two mobile nodes
(Ex: MN-1 and MN-2), both these nodes may be hosted on a given blade of the
MAG, while those sessions on LMA may be hosted on two different blades. So,
the group ID's for these nodes will be MN-1 (Mag-Id1, Lma-Id1), MN-2
(Mag-Id1, LMA-Id2). The binding operations can be now performed on Mag-Id1,
Lma-Id1, or Lma-Id2.  I agree, this part of the text is not clear and should
be updated. But, the option can be carried on both the directions, the
BCE/BUL entries needs to store both the id's, binding operation's scope is
always a single Id present in the identifier, protocol negotiation related
text is where there is some ambiguity. So, might need to update in just
couple of places, that's all. But, I agree, the current text is bit unclear
on this aspect. I can quickly address this comment and there is a long
weekend not too far :)

Regards
Sri

---

From: Jari Arkko <[email-masked]>
Date: Tue, 22 Nov 2011 16:41:52 -0800

Ok.  You have clearly understood the issue, and I'll wait until you've updated the draft. Thanks.

jari