Subject: [magma] IGMPv3 Action on reception of records(rfc 3376 section 6.4.1)

From: ravikumar vj <[email-masked]>
Date: Mon, 22 May 2006 07:33:32 -0700 (PDT)

Hi all,
           I have got a small doubt.
           If the current Router state is EXCLUDE (X,Y), and when a report 
           IS_EX (A) is received, it is said in RFC 3376, section 6.4.1 to change
           the state to EXCLUDE (A -Y, Y * A).
           My question is what is the need of keeping (A - Y), we could as well
           keep NULL. What will be the impact if I keep NULL there?
  Thanks in advance
  Ravikumar V J

---------------------------------
Yahoo! Messenger with Voice. PC-to-Phone calls for ridiculously low rates.

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: "Rolland Vida" <[email-masked]>
Date: Sun, 28 May 2006 23:24:41 +0200

Hi Ravikumar,
 
Please have a look at section 2.3 of RFC 3810 on the MLDv2 protocol. The
text is a bit more explicit on the reasons why the so-called "Requested
List" should be kept. The reasons presented there are of course valid
for IGMPv3 as well. 
 
Cheers,
Rolland
 
-----Original Message-----
From: ravikumar vj [mailto:[email-masked]] 
Sent: Monday, May 22, 2006 4:34 PM
To: [email-masked]
Subject: [magma] IGMPv3 Action on reception of records(rfc 3376
section6.4.1)
 
Hi all,

         IS_EX (A) is received, it is said in RFC 3376, section 6.4.1 to
change
         the state to EXCLUDE (A -Y, Y * A).
         My question is what is the need of keeping (A - Y), we could as
well
         keep NULL. What will be the impact if I keep NULL there?
Thanks in advance
Ravikumar V J
  _____  

Yahoo!
<http://us.rd.yahoo.com/mail_us/taglines/postman3/*http:/us.rd.yahoo.com
/evt=39666/*http:/messenger.yahoo.com>  Messenger with Voice.
PC-to-Phone calls for ridiculously low rates.
_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Hui Liu <[email-masked]>
Date: Mon, 29 May 2006 16:23:24 +0800

Hi  Rolland, 

I also had some confusion while I first read this part of the draft. 

The definition of EXCLUDE mode on host and router is elaborate in describing
the group member's behavior. But IMHO, and also from the engineers involved
in implementation, the realization of the EXCLUDE mode is relatively
complicated, especially when implementing L2/L3 LAN Switch with snooping.
And in practice, it seems there is little requirement for excluding some
specific sources.

On the other hand, EXCLUDE can not guarantee host do not receive unexpected
traffic. So is it possible that IGMPV3 redefined to eliminate the EXCLUDE
operation? Then the implementation and process of router and host will be
greatly simplified.

Regards,

Hui Liu

  _____  

发件人: Rolland Vida [mailto:[email-masked]] 
发送时间: 2006年5月29日 5:25
收件人: 'ravikumar vj'; [email-masked]
主题: RE: [magma] IGMPv3 Action on reception of records(rfc
3376section6.4.1)

Hi Ravikumar,

Please have a look at section 2.3 of RFC 3810 on the MLDv2 protocol. The
text is a bit more explicit on the reasons why the so-called “Requested
List” should be kept. The reasons presented there are of course valid for
IGMPv3 as well. 

Cheers,

Rolland

-----Original Message-----
From: ravikumar vj [mailto:[email-masked]] 
Sent: Monday, May 22, 2006 4:34 PM
To: [email-masked]
Subject: [magma] IGMPv3 Action on reception of records(rfc 3376
section6.4.1)

Hi all,

Thanks in advance

Ravikumar V J

  _____  

Yahoo! <http://us.rd.yahoo.com/mail_us/taglines/postman3/*http:/us.rd.yahoo.
com/evt=39666/*http:/messenger.yahoo.com>  Messenger with Voice. PC-to-Phone
calls for ridiculously low rates.

---

From: ravikumar vj <[email-masked]>
Date: Mon, 29 May 2006 02:34:36 -0700 (PDT)

Hello Rolland,
                       Thanks for the reply. I have read what u mentioned.
                       But still I have the same doubt.
                       I will try to elaborate on the same.
                      
                       In RFC 3810, section 2.3 two reasons are mentioned for keeping 
              forward list. One is to transition from EXCLUDE to INCLUDE and 
            second is to to allow the fast blocking of previously unblocked sources .
                             In case, if the current Router state is EXCLUDE (X,Y), and 
            when a report TO_EX (A) is received, a query will be send for (A-Y) 
            ( Q(G,A-Y)). And it will be helpful for transitioning, (A-Y) to exclude/ 
            non-forward list, in case there are no intrested receivers.
                       But in my case the incoming report is IS_EX(A) and not TO_EX(A).
           In this case there will be no query send for (A-Y). So will it be easier if 
           we make the final state EXCLUDE (NULL, Y * A) instead of 
           EXCLUDE (A -Y, Y * A).
           ( If any TO_IN(A) / ALLOW(A) / IS_IN (A) reports comes, 
           it will be used to update the forwarding list, which inturn 
           will be helpful in transitioning from EXCLUDE to INCLUDE on group 
           timer expiry).
                               In simple words, keeping final state as EXCLUDE (A-Y,Y*A)
           will be useful, if the incoming report is TO_EX, and will be useless, if the 
           incoming report is IS_EX. Is that true?
   
    Thanks in advance

    Ravikumar V J

Rolland Vida <[email-masked]> wrote:

    v\:* {behavior:url(#default#VML);}  o\:* {behavior:url(#default#VML);}  w\:* {behavior:url(#default#VML);}  .shape {behavior:url(#default#VML);}        st1\:*{behavior:url(#default#ieooui) }                Hi Ravikumar,
   
  Please have a look at section 2.3 of RFC 3810 on the MLDv2 protocol. The text is a bit more explicit on the reasons why the so-called “Requested List” should be kept. The reasons presented there are of course valid for IGMPv3 as well. 
   
  Cheers,
  Rolland
   
    -----Original Message-----
From: ravikumar vj [mailto:[email-masked]] 
Sent: Monday, May 22, 2006 4:34 PM
To: [email-masked]
Subject: [magma] IGMPv3 Action on reception of records(rfc 3376 section6.4.1)
   
    Hi all,

    Thanks in advance

    Ravikumar V J

			
---------------------------------
Sneak preview the  all-new Yahoo.com. It's not radically different. Just radically better.