Subject: [magma] IGMPv3 for really dumb hosts

From: John Zwiebel <[email-masked]>
Date: Thu, 29 Jun 2006 12:11:58 -0700

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-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: Hitoshi Asaeda <[email-masked]>
Date: Fri, 30 Jun 2006 11:44:01 +0900 (JST)

The -lite of igmpv3/mldv2 would contribute to the SSM deployment on
some level. And I could agree to eliminate an EXCLUDE mode (although
EX(null) is needed).

However, -lite must keep an interoperability with the full versions
without requiring any change on the full versions.
If we define different message types or different usage of the message
types used by the full versions, it may be difficult to fulfill the
condition.

Actually, I did a quick review of Hui's draft, but unfortunately I
could not agree several interpretation, because it seems the draft
proposes different protocol bahaviors and different usage of the
record types, which implies something new protocol and includes
difficulties for the interoperability with the full version.

For your question, igmpv3/mldv2 for dumb hosts; as a host-side
protocol implementer, I'd try to illustrate how -lite version should
be designed on them.
--
Hitoshi Asaeda

---

From: Cao Wei <[email-masked]>
Date: Fri, 30 Jun 2006 18:29:56 +0800

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.

---

From: Cao Wei <[email-masked]>
Date: Fri, 30 Jun 2006 18:32:56 +0800

> difficulties for the interoperability with the full version.

I would like to know details of the compatibilty problem you addressed.
Thanks!

---

From: John Zwiebel <[email-masked]>
Date: Fri, 30 Jun 2006 07:22:03 -0700

> some level. And I could agree to eliminate an EXCLUDE mode (although

Let's be clear.  Its elimination of EXCLUDE-filter-mode on the router.
And the reason for this is that it isn't quite clear how to translate
that state into PIM messages to send up the share-path and shortest-path
without causing disruption in the forwarding trees.

The lite spec is really just formalizing the current behavior.
ie, routers have not implemented the exclude-filter-mode.

As far as using just the ALLOW/BLOCK record types, the routers don't
actually gain much considering that (I believe) most have already
implemented an ad hoc v3-lite.

But, from a router perspective, hosts that used only ALLOW/BLOCK
record types would not impose much of an additional burden.

So, the gain would be mostly from the host side, on hosts that
haven't already implemented the complete IGMPv3.  I do not have
enough information to know if enough hosts might benefit.
I'll defer to your experience.

I'm happy either way.