Hi Stig, Thanks for your deep review, and excuse us for the delay in answering it.
Please, see our comments in-line. Best regards, Luis -----Mensaje original----- De: [email protected] [mailto:[email protected]] En nombre de Stig Venaas Enviado el: viernes, 08 de febrero de 2013 0:45 Para: [email protected] Asunto: [multimob] Review of draft-ietf-multimob-handover-optimization-01 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? [Luis>>] Potentially yes. Even in that case, the expected performance obtained by using this optimization is better than the one experienced with the base solution, as described in Appendix A. However, it could be an option just in case the router where the MAG resides is used only for PMIPv6 mobile customers (i.e., it is not mutualized for both mobile and fixed users in fixed/mobile convergent scenarios, or the router also simultaneously provides other mobile services different from PMIPv6, in which the point-to-point link model is not followed/required), or in case the MLD configuration can be individually applied per interface (thus, per PMIPv6 MAG-to-MN point-to-point interface). Looking at existing state-of-the-art MAGs, this is not possible. For instance, the Cisco 8500 Wireless LAN Controller dos not allow a configuration of the query interval below 15 seconds, and the MLD configuration affects to the whole device. So, in practice, the potential configuration of the query interval to 0 sec. seems to be far from common. What happens if the subscription state doesn't fit in a single PBU/PBA? Can multiple messages be sent? [Luis>>] The solution encapsulates each individual multicast membership context in an independent TLV active multicast subscription mobility option, allowing to transmit a large subscription state in multiple messages if needed. The mechanism for doing that would not be different to whatever mechanism defined in PMIPv6 for any other option or set of options in case a single PBU/PBA message could not transfer all the required content in a single message. 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? [Luis>>] The point is that in case the receiver just check the options and the Subscription Response message does not include any multicast subscription information, the receiver cannot clearly determine if there is not actually any on-going multicast subscription or if there is an error in the message. The flag I assists the receiver in correctly processing the message. In case there is no any on-going multicast subscription (with I=0) the receiver can avoid the processing of the rest of the message; otherwise (with I=1) the receiver realizes there was an error and can trigger some further action to solve it (e.g., raise an alarm). 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? [Luis>>] Despite the extension of PBU messages could have been a design option, in our opinion the use of specific purpose messages represents a more lightweight method for signaling this issue. The PBU/PBA sequence is tightly related to location registration events while the multicast activity indication reflects a change in the (multicast status) state of the point-to-point link at the MAG. The use of PBU/PBA sequence to signal that seems artificial. 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. [Luis>>] The signaling of the multicast activity between MAG and LMA is proposed not per multicast group request from the MN, but for the duration of the multicast activity by the MN, in other words, the time while the MAG maintains a multicast status for the MN on the point-to-point links. The activity is signaled ON once the MN request a subscription to a multicast group, and it is signaled OFF when no more channels are requested (i.e., the last subscribed channel is left). In the meantime the MN can leave or join different multicast groups, but no signaling is triggered because the activity is maintained. So, it can be seen as a couple of messages for the duration of the multicast session. We can assume that the MN customer base simultaneously in active multicast mode is lower than the general MN customer base. 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. [Luis>>] The rationale for including the HNPs is for facilitating the management of the multicast subscription when the MN has different HNPs while attached to different networks (e.g., Internet and Intranet). There could be different criteria per network in terms of which content can be subscribed to or not (e.g., certain multicast groups could not be allowed to be received by the Intranet). Under these circumstances, there could be a handover process for one of that networks, but not for the other. In that case it is needed to track exactly what point of attachment is changing, to trigger or not the multicast handover optimization process (if there is no active subscription on that interface, then there is no need to apply any optimization). 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. [Luis>>] Right. We propose to change it in Figure 3 by MLD Report, and in the text just below by "MLD Report message (with a filter mode change record indicating EXCLUDE mode for the last subscribed multicast group)". 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. [Luis>>] Since the information is kept in the binding cache, what we are proposing in 5.2.1.1 is that the multicast information is removed together with the rest of the binding database for the MN according to standard PMIPv6 procedures. 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? [Luis>>] This proposal is an optimization of the base solution but does not substitute the processes standardized in RFC6224. Then the proposal does not prevent the delivery of the MLD query once the MN attaches a nMAG, which is intrinsically part of the above RFC. We can include some text referring this. 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. [Luis>>] From our point of view, it is required in any case in the proactive case, since the handover optimization applies either if the MAG gets the multicast group from the LMA (remote subscription) of from the local multicast router (local subscription). The multicast context, kept in the binding cache, is a parameter of the communication service not bound to the way the multicast is served. A few Minor issues below. [Luis>>] Noted. We will upgrade next draft version accordingly. 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 ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
