Re: IGMPv3 for really dumb hosts

I agree that EXCLUDE mode for host side will be less useful if router side does not support EXCLUDE source filter.
But what is my concern is the  compatibility. Should we make a big change to host side operation?  We have to be careful 
on this.

And about explicit-host-tracking, it might be useful in some envrioment, but on the other side, it will increase the 
router burden. E.G., lots of hosts access the network through BRAS. And explict-host-tracking may introduce another
problem: how router keeps accurate state for all hosts? If there is no additional operation, I think it is difficult for router to do
this. For example, if the last one failed to tell the router that it is leaving, the router may stay in the wrong state for relative
long time.

----- Original Message ----- 
From: "John Zwiebel" <[email protected]>
To: "magma wg" <[email protected]>
Sent: Friday, June 30, 2006 3:11 AM
Subject: [magma] IGMPv3 for really dumb hosts


> The discussion up to this point has been the elimination of the
> EXCLUDE filter mode on the router.
> 
> Still the sending exchange is rather complicated since only
> one type has been eliminated.  TO_EX and IS_EX with a source list.
> And the EXCLUDE filter mode still exists on the host.
> 
> I would like to propose reconsideration of what an EXCLUDE filter
> mode means on the host.
> 
> I would also like to consider simplifying the message requirements
> for hosts.  The purpose being specification that is very simple to
> implement and simple to understand.
> 
> If the router no longer supports the EXCLUDE filter mode, there is
> no need for hosts to send reports for sources they are not interested
> in.  (which is what Hui Liu's draft is all about)
> 
> But these hosts must still send IS_IN (with a source-list) and IS_EX
> (without a source list) TO_IN, ALLOW, and BLOCK messages.  Saving only
> the TO_EX message.
> 
> If we consider host filter state to specify only those sources and/or
> groups that the host is interested in then the required messages can
> be further simplified.  If such a host wants to explicitly filter
> certain hosts out of a group, while receiving from all the other hosts
> in the group, it is immaterial to the network how this is accomplished.
> So for the purposes of this discussion, the host has only an
> INCLUDE filter mode.   The host ether listens to the source or it
> does not.  So there is no need to advertise to the router IS_EX,
> the router doesn't know anything about EXCLUDE filter mode.
> 
> If the host uses only ALLOW and BLOCK records to indicate sources it
> is interested in, it can still specify (*,G) and (S,G) records to the
> router.
> 
> The current spec says that an empty ALLOW or BLOCK should not be  
> transmitted.
> However, if ALLOW() were to mean all sources, it would be equivalent to
> an IGMPv2 join.  If BLOCK() meant all sources, it would be equivalent to
> an IGMPV2 leave.
> 
> ALLOW(A) and BLOCK(A) would still cause the same actions on the router
> as specified in the v3 RFC and Liu's draft.
> 
> Dumb hosts could respond to router queries with ALLOW reports.
> 
> This is the similar to Dino's proposal except that rather than using IS_
> record types it uses ALLOW/BLOCK which keeps it compatible with other  
> hosts
> that might be on the same subnet but have a more complete implementation
> of IGMPv3, and it doesn't change the actions that are required by the
> router when it receives an IS_ record type.
> 
> Additionally, A router that had enabled explicit-host-tracking might  
> use some
> means other than periodic queries to determine the presence of a host  
> and that
> host's interest in receiving specific source and/or groups.
> 
> 
> If the desired goal is to simplify IGMPv3 why not go "all the way"?
> 
> 
> _______________________________________________
> magma mailing list
> [email protected]
> https://www1.ietf.org/mailman/listinfo/magma
>