Re: [multimob] Volunteers to review draft-ietf-multimob-fast-handover-01

["Rahman, Akbar" <[e-mail]>]

Hi,

 

 

As per my action, I have reviewed draft-ietf-multimob-fast-handover-01
and have the following feedback to the authors:

 

 

1.  In general, the I-D is well written and in pretty good technical
shape.  However, I had the following comments that I suggest be
incorporated into an update before the WGLC.

 

Detailed Comments:

2.  Section 1 (Introduction)

o    I find the last paragraph in this section ("The solution described
in this document ...") to be ambiguous and hard to "prove".  How can you
really demonstrate that the approach can be applied to "possible
architectural evolutions"?  I would suggest removing this type of claim
unless you can be more specific.

o    The above comment also applies to the similar statement in the
abstract, and section 6.

o    In paragraph 3, should it be "active multicast content delivery"
instead of "active multicast subscription"?

o    In paragraph 4, I was not really sure if the base [RFC5949] can
perform the mechanism or not?  (I.E. Does it necessarily require
modifications to [RFC5949] to perform the mechanism?)

 

3.  Section 2 (Terminology)

o    The description of "Proactive handover" is confusing ("... the MN
de-registration from the pMAG previously to receive the MN registration
from the nMAG").

 

4.  Section 3 (Overview)

o    It would help a lot for readability (and understandability) to have
a high level architecture picture in this section.  Something along the
lines of Figure 1 of RFC 6224 would be an obvious starting point.

o    The 2nd paragraph stresses that subscription info for an MN to the
LMA is only updated after a handover event.  This may be true, but later
sections (e.g. Fig. 1) do specify other new info being exchanged without
a handover event.  So this should also be mentioned for balance.

5.  Section 4.2.1.1.2 (De-registration process)

o    In the S=1 description, it refers to the "IP addresses of the
subscribed group and the source providing it".  I interpret the "source"
to be referring to the Source-Specific Multicast (SSM) of [RFC4604].
But I understand that an MN can also do a non SSM Join (i.e. indicate
only the subscribed group IP address and no source).  Is this supported
in the draft?  (This comment applies to many places in the document).

 

6.  Section 5.1.1 (Multicast Activity set to ON)

o    In Figure 1 and the corresponding text it indicates that the "Act
Ind(start)" for the particular MN is sent by the MAG to the LMA as soon
as the MLD Report is sent.  I understand that this message will be sent
for each similar MN that attaches to the MAG (along with a corresponding
ACK).  What are the signaling load implications for this between the MAG
and the LMA? 

o    (My understanding is that in Fig. 1 the flag "A=1" is sent in a PBU
which normally would not have been sent at this point for unicast.
Please correct me if I am wrong).

 

7.  Section 7 (Benefits of layer-2 triggers for fast handover)

o    It was unclear what the main point of this section is (i.e. what is
the standards text)?  I especially found the last sentence confusing
("... and that not all the multicast applications could take benefit of
it, that functionality could be seen as optional for multicast handover
optimization.")

 

8.  Section 8 (Security Considerations)

o    You obviously need to complete this section before WGLC.

 

9.  Section 10 (Contributors)

o    Somehow the phrase ".. has largely contributed.." does not read
well (perhaps just change "largely" to "extensively").

 

10.General: I recall that the authors mentioned that they would do some
simulations to prove the benefit of this approach vs the baseline
[RFC6224] approach.  I think that will be very useful so that the WG can
trade the complexity vs. performance benefits of this approach.  I did
in general find the complexity of even understanding all the different
options (reactive vs. proactive, Flag setting, prevention of unicast
traffic delays, etc.) to be a bit daunting.  I had to go back to your
PPT presentations from the IETF meetings to piece everything together
(as those slides nicely captured the high level flow).  If we had the
simulations then we could justify all the complexity.  Or even better
perhaps support fewer options that give the majority of the benefits?
This to me is a key open issue.

 

 

That's all.

 

 

/Akbar

 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Behcet Sarikaya
Sent: Tuesday, September 25, 2012 4:38 PM
To: [e-mail]
Subject: [multimob] Volunteers to review
draft-ietf-multimob-fast-handover-01

 

Hi all,

 

In IETF84, three people volunteered to review

draft-ietf-multimob-fast-handover-01,

 

Thomas, Akbar and Costas.

 

The volunteers, thanks for volunteering and please post your reviews

on the list soon.

 

Regards,

 

Behcet

_______________________________________________

multimob mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/multimob