Hi, please find below my comments on this draft.
Stig
In the draft it says
receiving the corresponding MLD Report message. This delay is caused
by the time needed for the detection of the attachment in the new
link and the re-establishment of the data plane after the handover,
the radio transfer delays associated with the signaling to the mobile
node, and the MLD query response interval time required by this
procedure (whose default value is 10 seconds as defined in [RFC2710],
or between 5 and 10 seconds as considered in the best case wireless
link scenario in [RFC6636]).
Assuming there is a point-to-point link MAG-MN, can't this be set to a
minimal value, maybe even 0?
What happens if the subscription state doesn't fit in a single PBU/PBA?
Can multiple messages be sent?
In 4.3.1.2.2. Message format
Do you need the I flag? Can't the receiver just check all the options
to see if there are any Active Multicast Subscription options?
Is it really worth having the optimization with the A flag if new
message types are required? May it be possible to make use of the PBU
message instead?
Note that there may be less signaling by needlessly querying the pMAG
on handover, instead of signaling the LMA each time a MN starts joining
or leaving multicast groups.
Do you need to allow Home Network Prefix in various messages? Don't
you just need the MNI option? E.g. in the MAI/MAIA messages.
In 5.1.2 figure 3. You need to write something other than MLD Done to
take care of MLDv2 that only has reports. I know what you are trying
to say though.
There should be some limit for how long the LMA keeps the information
in the proactive case, or rather, if there is not a new nMAG within
a reasonable time.
It should be made clear that the nMAG should still ASAP send MLD
a query to check the hosts subscription state. Maybe it is already
stated somewhere?
In section 7 about co-existence. I think the MAG should only tell
the LMA about the subscription information for the (S,G)s or Gs
where it decided to send IGMP reports/joins on the LMA tunnel.
A few Minor issues below.
Comments for section 1. Introduction
The base solution describing how continuous multicast service
delivery can be provided in Proxy Mobile IPv6 domains is described in
RFC 6224 [RFC6224]. This solution specifies the basic functionality
^^^^^^
It's a bit unclear whether "This" refers to 6224 or this document.
Suggest writing "the base solution specifies", or maybe just "it
specifies".
mobile node), there is no a generic standard solution for the
^^^
remove "a".
IGMP/MLD protocols. Both protocols send multicast membership
interrogation messages when a new link is up. The response to such a
^^^^^^^^^^^^^
"query". Consider using "query" instead of "interrogation" other places too.
o The solution should not impact on existing multicast protocols.
^^^^^^^^^^^
just "impact" or "have impact on".
Present specification addresses all these requirements, as described
in the following sections.
Start with "The present" I think.
_______________________________________________
multimob mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/multimob
