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

From: <[email-masked]>
Date: Mon, 25 Oct 2010 14:54:49 -0300

Hi Hidetoshi and Xiangsong,

	I've just uploaded a new version of the I-D which tries to
accommodate your suggestions. Please feel free to comment back.

Regards,

Fuad Abinader

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext Xiangsong Cui
>Sent: segunda-feira, 16 de agosto de 2010 03:20
>To: Hidetoshi Yokota
>Cc: [email-masked]
>Subject: Re: [netext]Review/feedback on 
>draft-ietf-netext-bulk-re-registration
>
>Hi Hidetoshi,
>
>My suggestion is also to expand the status code.
>
>Thanks and regards,
>Xiangsong
>
>----- Original Message -----
>From: "Hidetoshi Yokota" <[email-masked]>
>To: "Xiangsong Cui" <[email-masked]>
>Cc: <[email-masked]>
>Sent: Monday, August 16, 2010 2:38 PM
>Subject: Re: [netext] Review/feedback on 
>draft-ietf-netext-bulk-re-registration
>
>
>> Hi Xiangsong and Fuad,
>> 
>> (2010/08/16 10:12), Xiangsong Cui wrote:
>>> 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
>>> 
>>> 
>>>> 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 just want to make sure, how many operations are there in 
>the document,
>> 
>> 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
>>> the MN's registration separately and doesn't add this MN to 
>any group. 
>>> (Accepting the individual registration request and 
>rejecting the adding 
>>> request)
>> 
>> I think this could happen.
>> 
>>> 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)?
>> 
>> 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...
>> 
>>> 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
>> 
>> In this case, the LMA returns PBA(B=0, lifetime >0)
>> 
>>> (1) Add (PBU with B flag, lifetime > 0) 1.2 accept individual 
>>> 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 
>>> accept/reject
>> 
>> 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 
>>> accept/reject
>> 
>> I think the MAG has to set B to 0 for requesting removal, so 
>my take is
>> to send PBU (B=0, lifetime =0).
>> 
>>> PS: I believe we needn't the operation of MN individual 
>de-redistration 
>>> 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
>> 
>>> (3) and (4), I agree.
>>> 
>>> Regards,
>>> Xiangsong
>>> 
>>> 
>>> 
>> 
>> 
>> _______________________________________________
>> netext mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/netext
>_______________________________________________
>netext mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netext
>

---

From: Xiangsong Cui <[email-masked]>
Date: Tue, 26 Oct 2010 10:47:29 +0800

Hi Fuad,

Thank you for the update, I have some other comments.

Section 1,
   In such cases the MAG or the LMA can perform the binding
   revocation signaling using the group ID associated with a specific
   set of mobile nodes.

This draft mentions binding revocation, but it is different with the binding
revocation mechanism defined in RFC5846. Additionally, in section 3.2.2,
this draft uses 0-lifetime PBAck message to MN from group, and in section
3.2.4, this draft uses 0-lifetime PBAck to de-register the group binding. I
don't understand these operations, if the PBAck is lost (I think it is very
possible in IP layer), how do we guarantee the same status between LMA and
MAG? (for example, if a MN is removed from the group in the LMA side, but
the PBAck message is lost, and the MAG takes the MN inside the group, so the
MAG doesn't separately register the MN again, and the MN would lost
service.) There is no further acknowledgement to the PBAck, and the draft
doesn't introduce any timer or retransmission in LMA side. Why not utilize
the mechanism defined in RFC5846 here?

Section 4.3,
   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, both for the situation where the
      Mobile Node Group Identifier specifies a single bulk registration
      set and for the situation where this field specifies all the MNs
      attached to the MAG that are members of any bulk set.

The length value "MUST be set to 6 in case ...", does this imply that there
is other possible length value?

The mandatory options in PBU/PBA message, or maybe this is related to the
group policy.
RFC5213 specifies,
              Mobility Options
               - Mobile Node Identifier option            (mandatory)
               - Home Network Prefix option(s)            (mandatory)
               - Handoff Indicator option                 (mandatory)
               - Access Technology Type option            (mandatory)

In this draft, MN ID MAY be optional, this is OK, but how about other
options?
Handoff indicator is simple, we can use "Handoff state not changed" (or
ignore it),
If home network prefix option and access technology type option are still
mandatory, this means we (or LMA) can not assign MNs with different prefix
or access type to one group, and multiple group IDs may not be included in
one PBU message. I don't mean we should keep these options mandatory, I just
want to say we should claim these options more clear, to me, all of these
options MAY be changed to optional.

Regards,
Xiangsong

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 26, 2010 1:55 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [netext]Review/feedback on