Re: [magma] Question about IGMPv3 state change

Hi  kunal,

I think Indranil's understanding is correct.

Appendix A.3 gives the reason. For 'exclude' mode, the router basically needs to keep the sources to be blocked, but  it still needs to keep source lists for 'include' report for seamless  mode transition. That's where the conflict exists.

The state machine of 3376 is somewhat hard to understand. And the complexity generally comes from the processing of exclude mode report. But in reality there is  generally no application case for excluding source report.  I suggest you have a look at RFC5790. It is a simplified version of IGMPv3 with more simple state machine.

Thanks
Liu Hui

From: magma-bounces@ietf.org [mailto:magma-bounces@ietf.org] On Behalf Of Kunal Shah
Sent: Wednesday, March 09, 2011 8:24 PM
To: Indranil Bhattacharya
Cc: magma@ietf.org
Subject: Re: [magma] Question about IGMPv3 state change

Hi Indranil,

Thanks for your thoughts.

Can someone else on the mailing list confirm this understanding??

Kunal

________________________________
From: Indranil Bhattacharya [mailto:myselfindranil@gmail.com]
Sent: Tuesday, March 08, 2011 1:03 PM
To: Kunal Shah
Cc: magma@ietf.org
Subject: Re: [magma] Question about IGMPv3 state change
Hi Kunal,

             The interpretation of the statement is different. It means router filter mode is exclude but you are receiving include mode reports. That's what is meant as conflict in desired reception state.

Thanks,
Indranil
On Mon, Mar 7, 2011 at 6:40 PM, Kunal Shah <kunal.shah@ericsson.com<mailto:kunal.shah@ericsson.com>> wrote:
Hi Indranil,

>From the RFC "

When a router filter-mode for a group is EXCLUDE, the source record

   list contains two types of sources.  The first type is the set which

   represents conflicts in the desired reception state; this set must be

   forwarded by some router on the network.
"
This means that a source can be in X only if it is being requested for being blocked as well as for being forwarded. In my example below s5 is not being requested to be blocked by any host. So what is the reason for keeping it in X??

Kunal

________________________________
From: Indranil Bhattacharya [mailto:myselfindranil@gmail.com<mailto:myselfindranil@gmail.com>]
Sent: Monday, March 07, 2011 6:33 PM

To: Kunal Shah
Cc: magma@ietf.org<mailto:magma@ietf.org>
Subject: Re: [magma] Question about IGMPv3 state change

Hi Kunal,
             X is for all INCLUDE mode sources. A is TO_IN report. So, s5 should be there in X. Why should s5 be blocked? Somebody wants data from this source.

Thanks,
Indranil
On Mon, Mar 7, 2011 at 5:52 PM, Kunal Shah <kunal.shah@ericsson.com<mailto:kunal.shah@ericsson.com>> wrote:
Hi Indranil,

Consider this,

X= s1,s2
Y= s3,s4

A=s4,s5

Then X+A= s1,s2,s4,s5
Y-A=s3

s5 is in X even when it is not being blocked ??

Kunal

________________________________
From: Indranil Bhattacharya [mailto:myselfindranil@gmail.com<mailto:myselfindranil@gmail.com>]
Sent: Monday, February 28, 2011 6:57 PM
To: Kunal Shah
Cc: magma@ietf.org<mailto:magma@ietf.org>
Subject: Re: [magma] Question about IGMPv3 state change
Hi Kunal,

x = s1,s2
y= s3,s4
a=s2,s3

x+a = s1,s2,s3
y-a = s4
Does it answer your question?

Thanks,
Indranil

On Tue, Feb 15, 2011 at 1:28 AM, Kunal Shah <kunal.shah@ericsson.com<mailto:kunal.shah@ericsson.com>> wrote:
Hi all,

I have a question about IGMPv3 state machine. If a group is in EX(X,Y) and a TO_IN(A) is received, the new state according to the RFC is EX (X+A, Y-A). I think this mean remove all the elements of A from Y and add all elements of A to X. This also implies that sources not removed from Y will still end up being added to X. My question is why cant we add only those elemets of A to X which are removed from Y as opposed to adding all the elements of A to X ??

If only the elements that are removed from Y are added to X, the new state would look like EX (X+(Y*A), Y-A).

Am I missing something here??

Kunal

_______________________________________________
magma mailing list
magma@ietf.org<mailto:magma@ietf.org>
https://www.ietf.org/mailman/listinfo/magma