Subject: Re: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration

From: Hidetoshi Yokota <[email-masked]>
Date: Sun, 15 Aug 2010 20:59:22 +0900

Hello Fuad,

I reviewed the latest draft (-01). Good work, but still needs more
clarifications.

After reading this document, I found that there are four operations that
this spec could cover (hope this is correct):

(1) ADD operation
(2) REMOVE operation
(3) BULK_REREGISTRATION operation
(4) BULK_REVOCATION operation

I recommend listing up all of possible operations like the above and
defining their procedures and necessary mobility options. For example,
in ADD operation, the MAG sends PBU with the MN-ID and the LMA would
respond to it by returning the PBA with the Group ID (and the MN-ID).

MAG               LMA
PBU(MN-ID) ->
         <- PBA(MN-ID, Group ID)

In BULK_REREGISTRATION operation, the following exchange would happen:

MAG               LMA
PBU(Group ID) ->
            <- PBA(Group ID)

No figure is needed like the above, but such descriptions will help
implementers.

My other comments are below in line (prefaced by "HY>"):

=======================================================================

Netext Working Group                                    F. Abinader, Ed.
Internet-Draft                             Instituto Nokia de Tecnologia
Intended status: Standards Track                           S. Gundavelli
Expires: January 11, 2011                                       K. Leung
                                                                   Cisco
                                                             S. Krishnan
                                                                Ericsson
                                                               D. Premec
                                                            Unaffiliated
                                                           July 10, 2010

               Bulk Re-registration for Proxy Mobile IPv6
               draft-ietf-netext-bulk-re-registration-01

Abstract

   Proxy Mobile IPv6 specification requires the Mobile Access Gateway
   (MAG) to send a separate Proxy Binding Update (PBU) message to the
   Local Mobility Agent (LMA) for each mobile node (MN) to renew the
   MN's mobility binding.  This document defines a mechanism by which a
   MAG can update the mobility bindings of multiple MNs attached to it
   with a single PBU message to the serving LMA.  This document also
   specifies a new mobility option that 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.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

Abinader, et al.        Expires January 11, 2011                [Page 1]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   This Internet-Draft will expire on January 11, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Abinader, et al.        Expires January 11, 2011                [Page 2]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Bulk Re-registration Overview  . . . . . . . . . . . . . . . .  5
     3.1.  Motivation for bulk re-registration  . . . . . . . . . . .  5
     3.2.  Bulk re-registration operation . . . . . . . . . . . . . .  6
   4.  Message formats  . . . . . . . . . . . . . . . . . . . . . . .  8
     4.1.  Proxy Binding Update message . . . . . . . . . . . . . . .  8
     4.2.  Proxy Binding Acknowledgment message . . . . . . . . . . .  9
     4.3.  Mobile Node Group Identifier Option  . . . . . . . . . . .  9
   5.  MAG Operation  . . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  LMA operation  . . . . . . . . . . . . . . . . . . . . . . . . 12
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   10. Normative References . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Abinader, et al.        Expires January 11, 2011                [Page 3]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

1.  Introduction

   The Proxy Mobile IPv6 base specification [RFC5213] uses the mobile
   node identifier in the mobility signaling messages for identifying
   the mobile node.  However, the signaling messages lack the capability
   to identify a set of mobile nodes which have a common characteristic.
   A group identifier associated with a mobile node enables the ability
   to perform protocol operation on a set of mobile nodes via a single
   transaction.  The group identifier provides a more optimal mechanism
   for protocol operation which would otherwise require multiple atomic
   transactions on a per mobile node basis.  Following are some of the

HY> s/on a per mobile/on a mobile node/

   use-cases where such identifier can be used.

   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
      single revocation request carrying the group identifier.

   o  For periodic re-registrations, the mobile access gateway may send
      a single re-registration message for each of the mobile nodes'
      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.

   The remainder of this document defines a new mobility option, named
   Mobile Node Group Identifier option, that can be used by a local
   mobility anchor and a mobile access gateway for exchanging the mobile
   node's group identifier as well as its application for bulk periodic
   re-registrations.

2.  Terminology

   General mobility related terminology is defined in [RFC3775].
   Additional PMIPv6 specific terminology can be found in [RFC5213].

Abinader, et al.        Expires January 11, 2011                [Page 4]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   PMIPv6 domain
      Network providing the network based IP mobility service as defined
      in [RFC5213].

   PMIPv6
      Proxy Mobile IPv6 protocol specified in [RFC5213].

   Bulk re-registration
      PBU/PBAck message exchange where the bulk re-registration flag (B)
      is set to 1

   Bulk re-registration set
      a set of MNs identified by the Mobile Node Group ID option to
      which the bulk re-registration operation applies.

HY> I recommend defining "Group identifier" here.

3.  Bulk Re-registration Overview

3.1.  Motivation for bulk re-registration

   In a PMIPv6 domain a single LMA serves multiple MAGs and the capacity
   of the LMA in terms of the number of attached MNs can be quite large.
   It can be expected that LMA capacity in managed networks may easily
   exceed hundreds of thousands or more attached MNs.

   The following simple formula gives an estimate of the average number
   of re-registration transactions per second as a function of the
   number of registered MNs and the binding lifetime period:

   transactions/sec = (number of registered MNs) / (binding lifetime*4)

   For 50.000 MNs and the binding lifetime of half an hour this gives:
   50000 MNs / 1800 sec = 27,7 transactions/sec

   Based on the above formula it is apparent that the default re-
   registration process where the MAG sends a separate message for each
   MN is inefficient or suboptimal.  These re-registration messages
   consume significant network resources both in terms of processing
   power at the LMA and MAG and network bandwidth.

   This document proposes an optimization of the re-registration process
   by which the signaling load for re-registration can be reduced to a
   single transaction per MAG, irrespective of the number of attached
   MNs.

   According to this proposal a MAG adds a MN to a set of MNs re-
   registered in a bulk mode by setting the bulk re-registration bit (B)
   in the PBU message.  The PBAck message sent in response contains the

Abinader, et al.        Expires January 11, 2011                [Page 5]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   Mobile Node Group Identifier mobility option which is defined later
   in this document.  In the context of bulk re-registrations the Mobile
   Node Group Identifier is an opaque identifier that is allocated by

HY> "Opaque to who? This ID should not be opaque to either the LMA or
MAG supporting this spec.

   the LMA and which uniquely identifies the bulk set to which the MN
   was added.

   A MAG requests a bulk re-registration for a set of MNs by sending a
   single PBU message which includes a Mobile Node Group Identifier
   mobility option and the LMA extends the binding lifetime of MNs that
   are members of that group.  By using this method, the MAG and LMA
   accomplish the re-registration of MNs attached to a MAG in a single
   transaction.  The number of re-registration transactions at the LMA
   becomes independent of the number of attached MNs; instead it is
   dependent only on the number of MAGs (i.e. bulk re-registration
   sets).

   In addition to minimizing the signaling overhead associated with the
   lifetime extension of the mobility bindings, the MAG and LMA may use
   a single timer per bulk re-registration set to monitor the binding
   lifetime of all the member MNs instead of an individual timer per MN.

3.2.  Bulk re-registration operation

   The bulk re-registration mechanism allows the MAG and the LMA to
   extend the binding lifetime for a number of MNs with a single
   transaction.  The MAG and LMA maintain a set of MNs that can be re-
   registered in bulk mode.  Such set is called a bulk re-registration
   set and is a subset of the MNs attached to a MAG.  There can be
   multiple bulk re-registration sets for a given MAG-LMA pair; however,
   there can be only one MAG and one LMA associated with a given bulk
   re-registration set.

   Initially the bulk re-registration set is empty.  MAG requests to add
   individual MNs to the bulk set by sending a regular PBU message that
   identifies an individual MN and additionally the bulk registration
   flag in the message is set to 1.  Based on the received bulk re-
   registration bit the LMA adds the MN to the bulk re-registration set
   and responds with the PBAck message with the bulk registration flag
   (B) set to 1.  The LMA identifies the bulk re-registration set to
   which the MN was added by including the Mobile Node Group ID option
   in the PBAck message.

   Once there is a non-empty bulk re-registration set, MAG can request
   to extend the binding lifetime for all MNs that are part of the bulk

HY> This "part of" means a subset of this bulk re-registration set? If
this means "all members of the set", then I recommend rephrasing as
follows:

s/are part of/belong to/

   re-registration set by sending a PBU message with the bulk (B) bit
   set and by including the Mobile Node Group ID identify the bulk re-
   registration set.  Such PBU message lacks any options that identify
   an individual MN.  In particular, the MAG omits both the MN ID

Abinader, et al.        Expires January 11, 2011                [Page 6]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   (Mobile Node Identifier) and the HNP (Home Network Prefix) options.
   From that, dual operations that try to operate (either adding or
   removing MNs) over the current bulk re-registration set while at the
   same time performing the bulk re-registration operation itself are
   not possible, and must be done with the use of two separate PBU
   messages.

   There may be different triggers that cause the MAG to request a bulk
   re-registration.  Typically the trigger is the binding lifetime
   expiry of a MN that is a member of a bulk re-registration set.  There
   could be other triggers as well, but they may be implementation or
   domain specific and outside the scope of this specification.

   When the MAG requests the MN to be added to the bulk re-registration
   set, the LMA includes the Mobile Node Group Identifier mobility
   option in the PBAck message.  The Mobile Node Group Identifier is an
   opaque identifier allocated by the LMA that uniquely identifies the
   bulk set at the LMA to which the MN was added.  The MAG associates
   the MN with the Mobile Node Group Identifier received in the PBAck.

   The MAG includes the Mobile Node Group Identifier mobility option set
   to the value previously received from the LMA to request the bulk re-
   registration for the MNs that are part of this particular bulk re-

HY> The same question here. Why "part of"? How and why does the MAG
specify such a subset?

   registration set.  The MAG may include multiple instances of the
   Mobile Node Group Identifier option in the PBU message to request
   lifetime refreshment for several bulk sets in a single message.

   The LMA extends the mobility binding of all MNs that are members of
   indicated bulk re-registration sets and responds with PBAck message
   echoing the received Mobile Node Group Identifier mobility options.

   A MAG may remove a MN from a bulk re-registration set by sending a
   regular PBU message identifying the MN to be removed and with the
   bulk re-registration flag set to 0.

   When requested to add a MN to the bulk re-registration set, the LMA
   may reject the request.  In this case the LMA processes the PBU
   message as if the bulk re-registration flag was not set and responds
   with PBAck message where the bulk re-registration flag is set to 0.

   Dual operations that try to extend binding time to some bulk re-
   registration sets while at the same time terminating bindings with
   other bulk re-registration sets (e.g. by setting zero lifetime) in
   the same PBU message are not possible; as a consequence, these must
   be performed with two separate PBU messages.

HY> This paragraph is the same as the one at the top of this page. They
could be consolidated.

Abinader, et al.        Expires January 11, 2011                [Page 7]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

4.  Message formats

   This section introduces extensions to PBU and PBAck messages used in
   this specification.

4.1.  Proxy Binding Update message
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |            Sequence #         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |A|H|L|K|M|R|P|B|   Reserved    |            Lifetime           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 1

   A Proxy Binding Update message is defined in the [RFC5213].  A new
   flag (B) is defined for the Binding Update message, as seen on
   Figure 1.

   Bulk Registration Flag (B)

   If the bulk registration flag (B) is set to 1, then the PBU message
   is a request to add the MN to the bulk re-registration set.  If the
   bulk registration flag (B) is set to 0 and if the MN is found to be a
   member of the bulk re-registration set, then the MN is removed from
   the bulk re-registration set.

HY> What value should be inserted in the Lifetime field?

   Mobility Options

   For descriptions of the mobility options, refer to [RFC5213].  When
   the PBU message is sent to refresh bindings in a bulk mode, the
   message MUST contain at least one Mobile Node Group Identifier
   mobility option and does not contain the MN-ID and the HNP mobility
   options.

Abinader, et al.        Expires January 11, 2011                [Page 8]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

4.2.  Proxy Binding Acknowledgment message
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                   |   Status      |K|R|P|B|  Res. |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Sequence #            |           Lifetime            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                        Mobility options                       .
   .                                                               .
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2: Proxy Binding Acknowledgment message

   A Proxy Binding Acknowledgment message is defined in the [RFC5213].
   A new flag (B) is defined for the Binding Acknowledgment message, as
   seen on Figure 2.

   Bulk Registration Flag (B)

   A new flag (B) is included in the Binding Acknowledgment message to
   indicate to the MAG that the MN was successfully added to the bulk
   re-registration set.  The flag MUST NOT be set to the value of 1 if
   it was not set to 1 in the corresponding PBU message.

   Mobility Options

   For descriptions of these options, refer to [RFC5213].  When the bulk
   registration flag is set to 1 in the PBU message, then the PBAck
   message MUST also contain the Mobile Node Group Identifier mobility

HY> I think this explains ADD operation. What if the LMA rejects this
operation? Still Group ID should be attached?

   option.  When the Mobile Node Group Identifier mobility option(s)
   were included in the PBU message, the PBAck message echoes back the
   Mobile Node Group Identifier options from the PBU message.

4.3.  Mobile Node Group Identifier Option

   A new option, Mobile Node Group Identifier option is defined for
   using it in Proxy Binding Update and Proxy Binding Acknowledgement
   messages exchanged between a local mobility anchor and mobile access
   gateway.  This option is used for carrying the mobile node's group
   identifier.

   The alignment requirement for this option is 4n.

Abinader, et al.        Expires January 11, 2011                [Page 9]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Type     |   Length      |           Sub-type            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Mobile Node Group Identifier                  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 3: Mobile Node Group Identifier Option

   Type
      <IANA>

   Length
      8-bit unsigned integer indicating the length in octets of the
      option, excluding the type and length fields.  The value for this
      field MUST be set to 6 in the case where the PBU message is
      requesting the binding refresh for a single bulk re-registration
      set, and 0 in the case where the MAG is requesting a lifetime

HY> If the length is 0, this option has only the Type and Length fields,
whose length is 2 octets and would violate the alignment requirement of
4n...

This is a kind of wild card and one possible way is to use ALL ONE (1)
rather than omitting the whole field. It's up to the author's decision,
though.

      refreshment of all the MN attached to the MAG that are members of

HY> s/MN/MNs/

      any bulk set.

   Sub-type
      Identifies the specific group type.  This number space will be
      managed by the IANA.

   Mobile Node Group Identifier   A 32-bit field containing the mobile
      node's group identifier.

   The Mobile Node's Group Identifier option reflects the group
   affiliation that is local to the specific LMA-MAG pair.  The specific
   value for the Mobile Node group Identifier is always determined by
   the LMA on the PBAck message, and must be used by the MAG on all
   future bulk re-registration procedures for that bulk re-registration
   set.

5.  MAG Operation

   The conceptual Binding Update List entry data structure maintained by
   the MAG, described in Section 6.1 of [RFC5213], MUST be extended to
   store the mobile node's group identifier.

   Bulk re-registration operations are optional to PMIPv6 [RFC5213], so
   the Mobile Node Group Identifier option MAY be used in the PBU
   message sent by the MAG to the LMA only when a bulk re-registration
   operation (refresh/termination) is intended.  When this option is

HY> What is "termination"? Removal from the bulk re-registration set or
de-registration? Please define it.

Abinader, et al.        Expires January 11, 2011               [Page 10]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   included, the identifier value in the option MUST be set to the
   mobile node's group identifier that was assigned previously by the
   LMA.

   When a new MN attaches to a MAG, the MAG registers the MN with the
   LMA by sending the PBU message formatted as described in [RFC5213].
   Additionally, the MAG MAY set the bulk registration flag (B) in the
   PBU message to 1 to request the LMA to add the MN to the bulk
   registration set.  The decision to request the bulk re-registration
   mode for a MN is a matter of local policy at the MAG and is outside
   the scope of this specification.

   The MAG SHALL maintain a separate bulk re-registration sets for each
   LMA.

   The MAG SHALL add the MN to its bulk re-registration set when it
   receives a PBAck message with the bulk registration bit set to 1 and
   if the corresponding PBU message was requesting the LMA to add the MN
   to the bulk re-registration set.  The MAG SHALL associate the MN
   being registered with the Mobile Node Group Identifier received in
   the PBAck message.

   The binding lifetime of MNs which are part of a given bulk re-

HY> Same question here. Why "part of"? Not all MNs in the set?

   registration set becomes the binding lifetime of the bulk re-
   registration set itself.  Therefore, both the MAG AND the LMA MNs MAY

HY> s/AND/and/ Also, "LMA MNs" means just LMA?

   not keep separate binding lifetimes for all MNs in a given bulk re-
   registration set, and instead SHALL keep a common binding lifetime
   for the whole bulk re-registration set.  If later on a given MN
   leaves the bulk re-registration set, then both the MAG and the LMA
   SHALL keep separate binding lifetimes for this MN.

   When the binding lifetime of a bulk re-registration set is about to
   expire, the MAG SHALL request the bulk re-registration by sending the
   PBU message containing the Mobile Node Group Identifier mobility
   option.  The length of the Mobile Node Group Identifier option may be
   0 in which case the MAG is requesting a refreshment of the binding
   lifetime for all MN attached to that MAG that were registered with
   the B flag set.  Alternatively, the MAG MAY include one or more
   Mobile Node Group Identifier options containing the values that were
   indicated by the LMA in the PBAck messages when the MN was added to
   the bulk set.  In this case the MAG asks for refreshment of specific
   bulk sets indicated by the Mobile Node Group Identifier options.  The
   MAG SHALL NOT include the MN ID and the HNP options in the PBU
   message requesting bulk refreshment.

   The MAG MAY trigger a bulk re-registration at any time.  The policy
   and exact conditions for these additional triggers are outside of
   scope of this specification.

Abinader, et al.        Expires January 11, 2011               [Page 11]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   When the MAG receives a PBAck message indicating success and which
   echoes the Mobile Node Group Identifier options that were included in
   the corresponding PBU message, the MAG SHALL update the binding
   lifetime of all MNs belonging to the indicated groups to the lifetime
   value contained in the PBAck message.  If in the case of bulk re-
   registration the PBAck message repeatedly indicates an error, the MAG

HY> What kind of error message is expected here?

   SHALL fall back to individual re-registration mode.

   If the MAG sets the bulk re-registration bit to 1 in a PBU message
   but the bulk registration bit (B) is set to 0 in a PBAck message, the
   MAG SHALL process the PBAck message as per [RFC5213].  In addition,
   the MAG SHALL infer that the LMA does not support bulk re-

HY> Is this inference always correct? SHALL sounds too strong.

   registration procedure.  The MAG SHALL switch to regular, per-MN re-
   registration mode as described in [RFC5213], and SHOULD NOT retry
   bulk re-registration set additions to that LMA unless an
   administrative action is taken.

6.  LMA operation

   The conceptual Binding Cache entry data structure maintained by the
   LMA, described in Section 5.1 of [RFC5213], MUST be extended to store
   the mobile node's group identifier.

   The Mobile Node Group Identifier option MAY be used in the PBAck
   message sent by the LMA to the MAG.  When this option is included,
   the identifier value in the option MUST be set to the mobile node's
   group identifier, local to the local mobility anchor.

   When the LMA receives a PBU message with a bulk registration bit (B)
   set to 1, the LMA SHALL first process the PBU message as per
   [RFC5213].  Upon successful processing of the message, the LMA SHALL
   perform additional processing of the PBU message as described further
   below for bulk mode re-registrations.

   If the bulk re-registration flag in the PBU message is set to 1, the
   LMA MAY add the MN(s) indicated in the PBU to the set of MNs re-
   registered in a bulk mode, subject to the local policy.  The decision
   whether to enable bulk re-registration mode is a matter of local
   policy at the LMA and is outside the scope of this specification.

   If the LMA decides to accept the bulk re-registration mode for the
   MN, it SHALL add the MN to a bulk re-registration set.  The LMA SHALL
   maintain distinct bulk re-registrations set for each MAG and there
   could be several such sets per single MAG.

   Upon adding the MN to the bulk re-registration set, the LMA SHALL
   respond with the PBAck message containing the bulk registration bit

Abinader, et al.        Expires January 11, 2011               [Page 12]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   set to 1.  The LMA SHALL include the Mobile Node Group Identifier
   option in the PBAck message.  The Mobile Node Group Identifier is
   allocated by the LMA and identifies the particular bulk set to which
   the MN is assigned.

   The PBU message without the MN ID and HNP options but including the
   Mobile Node Group Identifier mobility option is a valid message and
   indicates a request for bulk mode re-registration of all MNs that are
   members of the indicated bulk re-registration set.  There MAY be
   several Mobile Node Group Identifier options in the PBU message, in
   which case the MAG requests the bulk refreshment of all MNs that are
   members of the indicated bulk sets.  If the length of the Mobile Node
   Group Identifier option is zero, the MAG is requesting a lifetime
   refreshment of all the MN attached to the MAG that are members of any
   bulk set.  The LMA SHALL extend the binding lifetime of all affected
   MNs attached to the MAG that sent the bulk PBU.

   The LMA SHALL set the binding lifetime of all MNs re-registered in a
   bulk mode to expire at the same point in time.

   Upon successful processing of bulk mode re-registration request, the
   LMA MUST respond with a PBAck message indicating success and echoing
   the mobility options received from the PBU.  The lifetime in the
   PBAck message indicates the time when binding cache entries of
   affected MNs will expire.

   The LMA MAY reject the request for bulk re-registration.  In this
   case the LMA MUST NOT update binding cache entries of any MNs and
   SHALL respond with PBAck indicating the reason for the rejection in
   the status code.

HY> What is the reason code here?

   After successfully processing the bulk PBU message, the LMA SHOULD
   start a single timer to oversee the binding lifetime of all MNs
   affected by this bulk re-registration transaction.

HY> If this means a common lifetime for all MNs in the set, then SHALL,
instead SHOULD, is the right word. On the other hand, if this only
refers to a way of implementation, SHOULD sounds too strong. It's
totally up to the implementer.

   The LMA not supporting this specification ignores the bulk re-
   registration bit (B) and the Mobile Node Group Identifier option in a
   PBU message and processes the message as per the baseline

HY> If the LMA does not support this spec, then the Group identifier is
not assigned to the MAG in the first place, so the MAG cannot send a PBU
with this option; that is, this situation will not happen.

   specification [RFC5213].  In this case the PBAck message sent in
   response contains the bulk re-registration bit (B) set to 0.

   If the LMA that does not support this specification receives a bulk
   PBU message that does not contain any options identifying a
   particular MN then the LMA responds with the PBAck message where the
   status field contains one of the following error codes:

      MISSING_HOME_NETWORK_PREFIX_OPTION

Abinader, et al.        Expires January 11, 2011               [Page 13]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

      MISSING_MN_IDENTIFIER_OPTION

   These error codes are defined in the baseline specification
   [RFC5213].

7.  IANA Considerations

   This specification specifies a new flag (B) in the Proxy Binding
   Update (PBU) and Proxy Binding Acknowledgement (PBAck) messages of
   PMIPv6 [RFC5213].  This flag is defined in sections Section 4.1 and

HY> s/sections Section 4.1/Section 4.1/

   Section 4.2.  IANA is requested to allocate the new flag (B) in the
   Proxy Binding Update and Proxy Binging Acknowledgement messages from
   the [RFC5213] Proxy Binding Update Flags and the [RFC5213] proxy
   Binding Acknowledgment Flags registries.

   This specification defines a new Mobility Header option, the Mobile
   Node Group Identifier option.  This option is described in section
   Figure 3.  The Type value for this option needs to be assigned from

HY> s/section Figure 3/Section 4.3/

   the same numbering space as allocated for the other mobility options
   (as defined in [RFC3775]).  Also, the Sub-type field of the Mobile
   Node Group Identifier option (as defined in Section 4.3) must have
   its own brand-new, unique number pace allocated and managed by IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.

HY> This editor note should be resolved before WGLC.

8.  Security Considerations

   As per [RFC5213], the mobile node's identifier is always present in
   the Proxy Mobile IPv6 signaling messages, which exposes the
   identification of the user and may result in compromising the privacy
   of the user.  By additionally carrying the group identity of the
   mobile node on the PBU messages that perform bulk re-registration set
   addition operations, similar vulnerabilities are introduced.
   Specifically, it exposes the group affiliation of the user and may
   result in compromising the privacy of the user or the location
   information.

   The Mobile Node Group Identifier option defined in this specification
   is for use in Proxy Binding Update and Proxy Binding Acknowledgement
   messages.  This option is carried like any other mobility header
   option as specified in [RFC3775] and does not require any special
   security considerations.

   The bulk re-registration mechanism does not introduce any new
   security threat or vulnerability to the PMIPv6 specification.

Abinader, et al.        Expires January 11, 2011               [Page 14]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

9.  Acknowledgements

   Thanks to Jouni Korhonen and Basavaraj Patil for their review and
   input.

   The authors would like to acknowledge the prior discussions on this
   topic in netlmm mailing list.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.

Authors' Addresses

   Fuad Abinader (editor)
   Instituto Nokia de Tecnologia
   Av. Torquato Tapajos, 7200 - Km. 12 - Col Terra Nova
   Manaus, AM  69048-660
   BRAZIL

   Email: [email-masked]

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: [email-masked]
   URI:

Abinader, et al.        Expires January 11, 2011               [Page 15]

Internet-Draft         PMIPv6 Bulk Re-registration             July 2010

   Kent Leung
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Phone:
   Fax:
   Email: [email-masked]
   URI:

   Suresh Krishnan
   Ericsson
   8400 Decarie Blvd.
   Town of Mount Royal, QC
   Canada

   Phone: +1 514 345 7900 x42871
   Fax:
   Email: [email-masked]
   URI:

   Domagoj Premec
   Unaffiliated

   Email: [email-masked]

Abinader, et al.        Expires January 11, 2011               [Page 16]
=======================================================================

Regards,
-- 
Hidetoshi

(2010/06/28 20:01), [email-masked] wrote:
> Hi all,
> 
> As the IETF 78 meeting is approaching, I'd like to request you to some 
> additional comments on the "Bulk Re-registration for Proxy Mobile IPv6" 
> (_http://tools.ietf.org/html/draft-ietf-netext-bulk-re-registration-00_) 
> I-D, which was requested by the chairs to proceed with its revision 
> process. I believe is quite mature, but it would be really nice if some 
> of you could provide feedback. There is no newer version, it's the same 
> version presented on IETF #77 meeting, but as I haven't receive any 
> feedback also there, I'd like to request that again.
> 
> Regards,
> 
> Fuad Abinader
> 
> 
> 
> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 16 Aug 2010 09:12:14 +0800

Hi Hidetoshi,

----- Original Message ----- 
From: "Hidetoshi Yokota" <[email-masked]>
To: <[email-masked]>
Sent: Sunday, August 15, 2010 7:59 PM
Subject: Re: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration

> (4) BULK_REVOCATION operation

I just want to make sure, how many operations are there in the document,
As I said in my earlier review/feedback on this draft, I think a PBU message 
with B flag is set, not only represents the adding-to-group request, but also 
represents the individual registration request. This means the LMA may take
the MN's registration separately and doesn't add this MN to any group. 
(Accepting the individual registration request and rejecting the adding request)

On the other hand, shall we allow the MAG remove one MN from the group
registration to individual registration (keep the MN registered without interrupt)?

In my impression, the operations in this document may contain:

         MAG                                                                              LMA
(1) Add (PBU with B flag, lifetiem > 0)                 1.1 accept individual registration, but reject group
(1) Add (PBU with B flag, lifetime > 0)                 1.2 accept individual registration and add to group
(2.1) remove from the group (PBU without B flag,  lifetime > 0)     2.1 accept/reject
(2.2) remove and de-registration (PBU with B flag, lifetime = 0)     2.2 accept/reject

PS: I believe we needn't the operation of MN individual de-redistration without removing it out of group

(3) and (4), I agree.

Regards,
Xiangsong

---

From: Hidetoshi Yokota <[email-masked]>
Date: Mon, 16 Aug 2010 15:38:57 +0900

Hi Xiangsong and Fuad,

(2010/08/16 10:12), Xiangsong Cui wrote:
> Hi Hidetoshi,
> 
> ----- Original Message ----- From: "Hidetoshi Yokota" <[email-masked]>
> To: <[email-masked]>

As far as I read the draft, I think there are four operations like the
above.

> As I said in my earlier review/feedback on this draft, I think a PBU 
> message with B flag is set, not only represents the adding-to-group 
> request, but also represents the individual registration request. This 
> means the LMA may take

I think this could happen.

> registration to individual registration (keep the MN registered without 

At least, the MAG can request to remove by setting B=0 in the PBU. But I
don't know how the LMA can decline it because if B flag in the PBU is
set to 0, that flag in the PBA cannot be set to 1 according to Section
4.2. I think a new status code should be defined for this case. Or, the
LMA blindly accepts this request...

> registration, but reject group

In this case, the LMA returns PBA(B=0, lifetime >0)

> registration and add to group

In this case, the LMA returns PBA(B=1, lifetime >0)

> (2.1) remove from the group (PBU without B flag, lifetime > 0) 2.1 

For the accept case, the LMA returns PBA(B=0, lifetime >0), but I don't
know how to reject it...

> (2.2) remove and de-registration (PBU with B flag, lifetime = 0) 2.2 

I think the MAG has to set B to 0 for requesting removal, so my take is
to send PBU (B=0, lifetime =0).

> without removing it out of group

Agree.

I think there is still some ambiguity in the draft. A bit more
clarification could resolve this kind of confusions.

Regards,
-- 
Hidetoshi

---

From: Xiangsong Cui <[email-masked]>
Date: Mon, 16 Aug 2010 15:20:10 +0800

Hi Hidetoshi,

My suggestion is also to expand the status code.

Thanks and regards,
Xiangsong