Subject: [multimob] draft-contreras-multimob-rams-01.txt - resending

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 Sep 2011 20:23:05 -0500

Hi Luis, Carlos,
>   Here are some comments on your draft:
> Section 3: It seems like you are defining a new option to pass the
> multicast state from MAG to LMA.
> It seems that that's all you need.
> Why do you have Sec. 3.2 and 3.3 then? Why not define  single option with
> some flags and simplify this section?
>
> 3.5 active multicast subscription indication messages you defined, why do
> we need them? I am not convinced. Maybe there are ways of achieving the same
> without two new messages.
>
> Section 5: This section should be TBD because we don't know which solution
> will be selected.
> You say:
> the solution  is  applicable to the base solution. Can you clarify this by
> referring to the state MLD Proxy keeps at the MAG?
>
> Regards,
>
> Behcet
>

---

From: "Luis M. Contreras" <[email-masked]>
Date: Mon, 26 Sep 2011 22:22:49 +0200

Hi Behcet,

thank yoo very much for your comments. My apologies for answering so late.

Please, find the answer below, within your text.

2011/9/23 Behcet Sarikaya <[email-masked]>

>> some flags and simplify this section?
-----
Luis>> The flags you mention, the one in the PBU/PBA messages (the one
described in sec. 3.2), and the one in the LMA cache (defined in sec. 3.3),
are used for different things. The former is used to interexchange
multicast-support capability information between MAG and LMA. In case the
MAG does not support multicast, the LMA will not interrogate the pMAG about
any subscription, even if the MN maintains an active multicast session
(thus, saving resources).

The later flag, the one in the LMA cache, is useful to trigger the
interrogation towards the pMAG. According to the state of the flag, the LMA
takes the action of interrogating or not the pMAG (always talking about the
reactive case).

In the new version we propose also to mark the multicast activity in the
MN's profile as an option. The idea behind of having the flag also in the
MN's profile is to advice in advance the MAG about the existence of an
active multicast subscription by the MN entering the MAG coverage area.
Then, the MAG becomes aware of an existing subscription before registering
the MN. We see this possibility like an option, being the flag on the LMA
the mandatory implementation.
----

> ----
Luis>> These two messages are the ones that set to 1 or 0 the multicast
activity flag in the LMA cache. These messages are indications about the
multicast status establishment in the MAG.

Such change in the status of the MN can not be signaled by any other
existing message, so we belive it is necessary to define these two new
messages to handle the multicast activity flag.
-----

>> Section 5: This section should be TBD because we don't know which solution
-----
Luis>> well, it only tries to highlight the fact that the RAMS mechanism is
compatible with all the existing proposals for multicast support evolution.
It is only informative. If formally it is more correct to maintain it as TBD
we can consider it for the next version, but I think that we should maintain
it for completeness
-----

> -----
Luis>> In our opinion is compatible because it does not modify the base
solution behavior. The MAG continues sending the MLD queries of the
corresponding MLD proxy instance as specified in RFC 6224. The information
retrieved from the MLD Report should be coherent with that obtained via the
LMA. The MLD proxy instance will be updated with the information obtained
via the LMA. The MAG will set up the multicast status of the MN during the
registration process, and will handle the subscription to the desired group
in case it is not yet arriving to the MAG.

In our opinion, RAMS helps to accelerate the acquisition of such
subscription info by the MAG. You can see this as a kind of redundancy, but
also it can be seen as a resilient way of getting the multicast context of
the active multicast session at the MN.
____

> Thanks, best regards,

Luis