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

From: <[email-masked]>
Date: Mon, 28 Jun 2010 07:01:53 -0400

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

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 29 Jun 2010 11:06:46 +0800

Hello,

I have read this draft and have some comments,

In general, does this draft UPDATE RFC5213? 
I think it does, because PBU message may carry no MN ID (while that
is required MUST in RFC 5213), but I don't see this information in the
head of the draft.

Section 3.1,

   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 PBU message sent in response contains the
   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
   the LMA and which uniquely identifies the bulk set to which the MN
   was added.

In the third line, "The PBU message sent in response....", Should it be
"The PBA message sent in response...." ?

section 3.2,

   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.

I think the request message has two purposes, MN binding and joining the
group, otherwise, I mean if there was only joining meaning, the MN is not 
attached after the PBAck message with group id option. right?
In this case, if the LMA rejects the joining request, it processes as if
the bulk flag was not set. But at this time, the binding request is processed, 
so that is not really a *reject* (I prefer that was partial acceptance), 
the PBAck status should be success value, just without bulk flag. 
The text in the draft looks like the PBAck status was a rejected value?

section 4.1,

   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. 

Again, if the PBU is just adding request without binding purpose,
why does the LMA, in section 3.2, processes the PBU as if the bulk flag
was not set? ignoring the bulk flag, means the PBU has other meaning,
right? If that was true, I prefer this text as:
   If the bulk registration flag (B) is set to 1, then the PBU message
   is additionally loaded a request of adding the MN to a bulk 
   re-registration set. 

section 5,

   When the binding lifetime of any MN contained in the bulk re-
   registration set is about to expire, the MAG SHALL request the bulk
   re-registration by sending the PBU message.....

About the binding timer, if the individual timer is running,
when MN1 is about to expire, MN2 is also about to expire,
so I am worrying, do multiple MNs trigger multiple PBU?
At least, IMHO, *binding lifetime of any MN* is inappropriate,
first expiration triggers PBU is better but still need explanation what is *first*,
maybe we can say if there is a pending bulk PBU/PBA transaction between
the LMA/MAG pair, then no other bulk PBU for the same group is sent, 
except the PBU expires....
anyway, I think this arithmetic should be clarified.
(I would like there is only one timer for the group binding.)

section 5,

   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-
   registration procedure.  The MAG SHALL switch to regular, per-MN re-
   registration mode as described in [RFC5213].  The MAG MAY retry the
   bulk re-registration procedure after sufficient time has elapsed from
   the previous unsuccessful bulk re-registration.  This amount of time
   SHOULD be configurable at the MAG.

if the LMA doesn't support bulk re-registration, why does the MAG retry
bulk re-registration? why does the situation change? why the delay time
*SHOULD* be configurable?
I suggest to extend PBA status value, to represent temporary reject, 
not support bulk re-registration, and other reject reasons.

section 8,

   The mobile node's identifier is always present in the Proxy Mobile
   IPv6 signaling messages and additionally carrying the group identity
   of the mobile node introduces similar vulnerabilities. 

As this draft specifies, MN ID is not present in bulk PBU/PBA messages,
*is always present* is inappropriate?

Regards,
Xiangsong

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 28, 2010 7:01 PM
Subject: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration

Hi all,

Regards,

Fuad Abinader

--------------------------------------------------------------------------------

> _______________________________________________
> netext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netext
>

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 29 Jun 2010 14:54:44 +0800

Hello Fuad,

Another comment,

in section 4.3 Mobile Node Group Identifier option 

   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.

while in section 6,

   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 length, MUST be 6 or may be zero?

Regards
Xiangsong

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 28, 2010 7:01 PM
Subject: [netext] Review/feedback on draft-ietf-netext-bulk-re-registration

Hi all,

Regards,

Fuad Abinader