Subject: [netlmm] Mobile Node Group Identifier option

From: Sri Gundavelli <[email-masked]>
Date: Thu, 19 Mar 2009 19:59:14 -0700 (PDT)

We have posted this draft on Mobile Node Group Identifier.

http://tools.ietf.org/html/draft-gundavelli-netext-mn-groupid-option-00

Abstract

    This document specifies a new mobility option for use in Proxy
    Binding Update and Proxy Binding Acknowledgement messages.  This
    option can be used by the mobility entities in a Proxy Mobile IPv6
    domain for carrying the group affiliation of a mobile node in any of
    the mobility signaling messages

Along the lines of RFC-4283, which provides a user specific identifier,
this provides the semantics for a binding an identifier to a mobile node's
session, a identifier which has group affiliation.

This extensions can be used in many other applications, such as bulk
re-registration from a given MAG or ability to perform an operation on a
large set of mobile node's, but within a single transaction.

Again, Which ever WG will eventually have charter for this, ignoring that
aspect, please comment on the technicals.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 20 Mar 2009 10:16:43 -0500

Hello Sri, et. Al.,

I read this draft and although, it sounds a simple one but looking at
the use cases captured below, I believe some of them probably is not
applicable; or may be I should say, these use cases are either
addressing implementation specific issue, already addressed in other
documents, or it is quite NOT possible to support all of them at the
same time. For example:

1. The first use case seems to make sense and a straight forward one.
Although, we are trying to solve an implementation specific issue. For
example, other systems may have a well defined mechanism to move these
sessions to another card. (full redundancy) NO?

2. Use case 2 reference bulk re-registration, but it seems that this
draft is proposing an option that is parallel to what is proposed in
bulk re-registration. No?

3. Usecase 3 does not make a lot of sense to me in the context of this
draft, for the following reasons:

3.1. It is already addressed in the Binding Revocation draft.
3.2. Why the LMA would assign a *@realm as a MN Group Identifier for a
mobile node that its MN-ID already explicitly reflect that. In other
words, why not using MN-ID for the same purpose?
3.3. Let us assume for the sake of argument that this work is supported,
how an LMA will be able to support usecase 1 and 3 simultaneously?

Best Regards,
Ahmad Muhanna

   o  In a blade architecture system running the local mobility anchor
      service, all the mobile node sessions anchored on a given card can
      be part of one single group.  When there is a failure on a
      specific card, the local mobility anchor can initiate the
      revocation signaling to the mobile access gateway by sending a
      sending a single revocation request carrying the group identifier.

   o  For periodic re-registrations
      [draft-premec-netlmm-bulk-re-registration], the mobile access
      gateway may send a single re-registration message for each of the
      mobile node's groups and perform re-registrations for all the
      mobile node's that are part of that group.

   o  The mobile access gateway or the local mobility anchor in a proxy
      mobile IPv6 domain may choose to revoke the registration of mobile
      node associated with a specific realm.  In such cases the mobile
      access gateway or the local mobility anchor can perform the
      binding revocation signaling using the group ID associated with a
      specific set of mobile nodes.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: Thursday, March 19, 2009 9:59 PM
> To: [email-masked]
> Subject: [netlmm] Mobile Node Group Identifier option
> 
> 
> Along the lines of RFC-4283, which provides a user specific 
> identifier, this provides the semantics for a binding an 
> identifier to a mobile node's session, a identifier which has 
> group affiliation.
> 
> This extensions can be used in many other applications, such 
> as bulk re-registration from a given MAG or ability to 
> perform an operation on a large set of mobile node's, but 
> within a single transaction.
> 
> Again, Which ever WG will eventually have charter for this, 
> ignoring that aspect, please comment on the technicals.
> 
> 
> Thanks
> Sri
> 
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netlmm
>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Mar 2009 08:33:42 -0700 (PDT)

Hi Ahmad,

Thanks for the review. Please see inline.

> documents, or it is quite NOT possible to support all of them at the

The draft introduces the concept of group identifier to a mobility
binding. The usecases listed here are potential examples and is not
a complete list, they are presented here to merely to explain the
concept of usage.

> sessions to another card. (full redundancy) NO?

Its a practical deployment problem in systems where the sessions are
handled by different modules in the box. Mechanisms of redundancy is
surely one solution. But, the use of the group id, can be used in
many ways, the tag can be used for routing the request within the
box to a specific blade.

> bulk re-registration. No?

Bulk reg draft is referenced here. That can be achieved very well
by using this group identifier.

> how an LMA will be able to support usecase 1 and 3 simultaneously?

Fine, if the usecase has a overlap here. But, @realm is a specific fixed
group, it is sufficient if the operation performed is on the whole group.
When the affiliation of the group is based on other considerations, such
as the blade handling a session, or class of user service, then the
identifier in the MN-Id is not sufficient.

Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 20 Mar 2009 10:56:36 -0500

Hi Sri,
Please see some comments inline.

Regards,
Ahmad

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Friday, March 20, 2009 10:34 AM
> To: Muhanna, Ahmad (RICH1:2H10)
> Cc: [email-masked]; Patil Basavaraj (Nokia-D/Dallas); 
> [email-masked]
> Subject: RE: [netlmm] Mobile Node Group Identifier option
> 
> Hi Ahmad,
> 
> The draft introduces the concept of group identifier to a 
> mobility binding. The usecases listed here are potential 
> examples and is not a complete list, they are presented here 
> to merely to explain the concept of usage.
> 
> Its a practical deployment problem in systems where the 
> sessions are handled by different modules in the box. 
> Mechanisms of redundancy is surely one solution. But, the use 
> of the group id, can be used in many ways, the tag can be 
> used for routing the request within the box to a specific blade.

[Ahmad]
Hmmm... It is a good idea to use a tag to route the PBU locally within
the box (An implementation issue too) IMHO, we should not overload a
signaling protocol to solve a specific implementation issue. Because,
this issue can also be solved locally without the need for new signaling
overhead.

> Bulk reg draft is referenced here. That can be achieved very 
> well by using this group identifier.
> 
> 
> > 3.3. Let us assume for the sake of argument that this work is 
> > supported, how an LMA will be able to support usecase 1 and 
> 3 simultaneously?
> >
> 
> Fine, if the usecase has a overlap here. But, @realm is a 
> specific fixed group, it is sufficient if the operation 
> performed is on the whole group.

[Ahmad]
Why NOT using MN-ID?

> When the affiliation of the group is based on other 
> considerations, such as the blade handling a session, or 
> class of user service, then the identifier in the MN-Id is 
> not sufficient.

[Ahmad]
True, however, these other cases are implementation specific as pointed
out above.

> >>     domain for carrying the group affiliation of a mobile 
> node in any 
> >> of
> identifier 
> >> to a mobile node's session, a identifier which has group 
> affiliation.
> >>
> >> re-registration from a given MAG or ability to perform an 
> operation 
> >> on a large set of mobile node's, but within a single transaction.
> >>
> >> Again, Which ever WG will eventually have charter for 
> this, ignoring 
> >> that aspect, please comment on the technicals.
> >>
> >>
> >> Thanks
> >> Sri
> >>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Mar 2009 09:23:09 -0700 (PDT)

Hi Ahmad,

Please see inline ..

> this issue can also be solved locally without the need for new signaling

If such overload of carrying a tag in load balancer or blade
systems helps, removing other implementation complexities. As
you know even GTP has the Connexion Set Identifier, with the
similar semantics. It has some value as we see it.

>> performed is on the whole group.

Some identifier with group semantics, multiplicity of option
presence and other details of how it can be used in various
cases, as an serving module id tag, bulk rereg, or for other
purpose ..

> True, however, these other cases are implementation specific as pointed

It certainly helps in some aspects of deployment.

Thanks for your comments.

Regards
Sri