RE: suggestion for simplifying IGMPV3/MLDV2 to discard EXCLUDEmode

Hi,
       I have a small suggestion.
       Even though it contradicts with RFC, I guess, host should send IS_EXCL,
       or IS_INCL, if the host needs a new group, rather than sending TO_INCL,
       ALLOW or TO_EXCL. This can be implemented by adding a simple check
       whether it is a new group or not on host.
             I am telling this because, if we send an TO_EXCL, or TO_INCL, the
       upstream router will think that the host is changing its current state and 
       will result in sending unnecessary queries ( group-specific / group and 
       source-specific).
       ""the "non-existent" state is considered  to have a filter mode of 
       INCLUDE and an empty source list."" this should not be used for 
       sending maessage. But it will be useful at other places for e.g. calculating
       list on router interface, if a TO_EXCL or ALLOW comes first
     
   
       The above suggestion is in contradiction to RFC, which says IS_INCL and 
       IS_EXCL should be only send in response to queries
   
       Somebody please correct if I am wrong.
   
       Also in IGMPv3 lite, the host part should also be simplified, because, it is 
       much difficult in merging the reports .(section 5.1/ 5.2) Instead of having 
       robustness variable and all, it would have been nice if we have some
       acnowledgement mechanisam or something like that.
   
  Regards
  Ravi
   
  > > An initial interface state of each host is (m, INCLUDE, NULL).
> > When the host changes the state (m, INCLUDE, s1) (due to (m,s1) join),
> > it sends ALLOW(m,s1), not TO_IN(m,s1), because the host's initial
> > filter mode has been INCLUDE.
> 
> Well, one could believe that there is no initial state.
> or there is "NULL" state.
> 
> I don't find anything in the RFC that claims there is any initial state.

Does the sentence in section 5.1 correspond to my thought?

   If no interface
   state existed for that multicast address before the change (i.e., the
   change consisted of creating a new per-interface record), or if no
   state exists after the change (i.e., the change consisted of deleting
   a per-interface record), then the "non-existent" state is considered
   to have a filter mode of INCLUDE and an empty source list.
--
Hitoshi Asaeda


 __________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

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