Subject: mboned: report messages IGMPv3/MLDv2-lite host sends

From: Hitoshi Asaeda <[email-masked]>
Date: Sat, 09 Sep 2006 22:03:56 +0900 (JST)

I'm sorry. It should be discussed in mboned ML. Please follow the
related discussion in mboned ML, not in magma ML. Sorry.
--
Hitoshi Asaeda

Subject: [magma] report messages IGMPv3/MLDv2-lite host sends
From: Hitoshi Asaeda <[email-masked]>
To: [email-masked]
Date: Sat, 09 Sep 2006 21:50:14 +0900 (JST)
List-Id: Multicast and Anycast Group Membership <magma.ietf.org>

Hi all,

I've been thinking about the host-side spec of IGMPv3/MLDv2-lite.
(Note that the word of "lite" has been tentatively used here.
Discussion about its official wording will be given later.)

As we discussed in the magma ML and the last IETF MBONED, designing
the igmpv3/mldv2 lite which eliminates an exclude filter mode from the
full version would be beneficial to the SSM deployment.

Now I clarify which states are kept and which states can be eliminated
from the lite version host. The following table shows possible report
messages an igmpv3/mldv2-lite version host transmits.

 IGMPv3-full     IGMPv3-lite      meaning
 ------------    ------------     --------------------------------
 IS_EX(NULL)     IS_EX(NULL)      query response for (*,G) join
 IS_EX(S,G)      N/A              query response for EX (S,G) join
 IS_IN(S,G)      IS_IN(S,G)       query response for IN (S,G) join
 ALLOW(S,G)      ALLOW(S,G)       IN (S,G) join
 BLOCK(S,G)      BLOCK(S,G)       IN (S,G) leave
 TO_IN(S,G)      TO_IN(S,G)       change to IN (S,G)
 TO_IN(NULL)     TO_IN(NULL)      (*,G) leave
 TO_EX(S,G)      N/A              change to EX (S,G)
 TO_EX(NULL)     TO_EX(NULL)      (*,G) join

According to my thought, above two "N/A" states can be eliminated from
lite version host. And other states would be same of the full version.
Regarding IS_EX(S,G), if a lite version host receives a query message
asking EX (S,G) join, it silently discards (i.e. ignores) the message.
A lite version host never sends TO_EX(S,G).

Any comments?
--
Hitoshi Asaeda

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

---

From: John Zwiebel <[email-masked]>
Date: Mon, 11 Sep 2006 17:59:58 -0700

FWIW:
I think the need for a "lite" version has more to do with what the  
router
does with certain v3 reports than changing the host implementation.
Elimination of only two message types isn't compelling for the host.

It is true that PIM-SM could translate a TO_EX(S,G) to a (*,G) join  
toward
the RP with (S,G,RP-bit prunes).  It is also true that if an (S,G)  
mroute
existed on the last-hop that the TO_EX(S,G) could cause an (S,G) prune
to be sent toward the source.   Basically the last-hop could have
(S,G,R) state that would keep the RP-tree pruned.

But, that would mean having to implement the EXCLUDE filtering mode
on the router when it isn't clear there is any benefit to be gained.

Let me diverge from the router focus to  consider what IGMPv3 means  
for SSM
and Bidir and what that might mean for a 'lite' IGMPv3 on a host.

Bidir is not going to send an (S,G,R) prune toward the RP because the
      main reason for using bidir is to avoid creation of additional  
state.
      So only TO_IN{}, IS_IN{}, and TO_EX{} would be required

SSM need not react to a TO_EX(S,G) because only ALLOW and BLOCK
     messages should be required to set up and take down state.   
IS_IN to
     maintain state.

In table form  [ where ASM == PIM-SM], we can think of each v3 message
type as being used (but not exclusively) to support a given PIM  
forwarding mode.

  IGMPv3-message    PIM-mode
  ------------    ------------
  IS_IN(S,G)      SSM refresh channel
  ALLOW(S,G)      SSM join channel
  BLOCK(S,G)      SSM leave channel
  IS_EX(S,G)      N/A [ASM]
  TO_IN(S,G)      N/A [ASM]
  TO_EX(S,G)      N/A [ASM]
  IS_EX(NULL)     Bidir refresh group
  TO_IN(NULL)     Bidir leave group
  TO_EX(NULL)     Bidir join group

SSM and bidir are always "INCLUDE" filter-mode, they can't be EXCLUDE.
Applications that I'm aware of all use "INCLUDE" filtering mode.

Now consider that some router implementations do not support maintaining
a (*,G) only branch for Sparse-mode.  [ie the 'ip pim spt-threshold  
infinity command.]
These implementations always immediately switch to the SPT using the  
shared-tree
only for source discovery.   Even implementations that do support an  
spt-threshold of
infinity, the majority of their deployments switch immediately to the  
SPT.
Those that don't are better served by the bidir forwarding mode.

Point being, PIM-SM is widely deployed and one must continue to  
support it
but IMHO the bidir and SSM alternatives are much better choices, so  
one might
consider throwing out those IGMPv3 message types required by PIM-SM

So if you believe that a lite host version of IGMPv3 is required (I'm  
not sure it is)
then I believe you should consider the host and what kind of  
multicast services it
will require.  Will the receiver connect only to Specific sources or  
will it join
to specific groups.  Then you can really reduce the number of message  
types
required by the host for specific kinds of deployments.

On the other hand, if you want all the hosts on a given LAN to have  
the same
capabilities to report for channels and groups and to do it all, then  
I think all those
hosts should implement everything in IGMPv3.

On Sep 9, 2006, at 6:03 AM, Hitoshi Asaeda wrote:

> Date: September 9, 2006 5:50:14 AM PDT
> To: [email-masked]

---

From: Hitoshi Asaeda <[email-masked]>
Date: Tue, 12 Sep 2006 12:02:24 +0900 (JST)

Thanks, John.

> does with certain v3 reports than changing the host implementation.

I think it would be beneficial to define lite spec for dumb nodes.
A lite version router/switch exists; as well a lite version host
exists. That's all. We don't need complex implementation (and an
exclude mode operation) on our cell phone, PDA, and maybe Internet
appliances. For these equipments, a simple and essential
implementation *is* the most important for the SSM deployment.

Remember, I don't propose any protocol modification for existing full
version hosts at all. (And I don't want.:)

> Elimination of only two message types isn't compelling for the host.

Actually not only them. Later I'll send another mail that discusses
the possible MSF implementation for the lite version host.
Eliminating an exclude mode with keeping an interoperability between
full and lite is the most important thing. And another challenge is to
clarify the several complex specifications the full version host has
and to simplify them (if possible). I believe these discussions would
be advantageous for the SSM deployment for any kind of node.

Don't you think we need the spec of the igmpv3/mldv2 lite version
hosts?
Thanks.
--
Hitoshi Asaeda
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Cao Wei <[email-masked]>
Date: Tue, 12 Sep 2006 17:21:37 +0800

Hi John,
   
   I am interested in your topic about SSM and Bidir. IMHO, it is not convinced that BIDIR will replace PIM-SM. BIDIR has some advantage in some special senario, but not all.

   And for lite version, compatibility is very important. Radical changes may cause some problems for current implementations. 

   Other comments please see inline.

Thanks.

>>type as being used (but not exclusively) to support a given PIM forwarding mode.
>>
>> IGMPv3-message    PIM-mode 

Yes, according to full version,  TO_EX(NULL)  will be used as the first join, and for refresh state, IS_EX(NULL) will be used. And it will not introcude problem if IS_IN(NULL) message is used for these two situation. Router will full version or lite version can process it correctly.

>>Applications that I'm aware of all use "INCLUDE" filtering mode. 

Is bidir always "INCLUDE" filter mode? I am confused here. It is contradictory to the the table above.

>>a (*,G) only branch for Sparse-mode.  [ie the 'ip pim spt-threshold infinity command.] 
>>These implementations always immediately switch to the SPT using the shared-tree 
>>only for source discovery.   Even implementations that do support an spt-threshold of 
>>infinity, the majority of their deployments switch immediately to the SPT. 
>>Point being, PIM-SM is widely deployed and one must continue to support it 
>>but IMHO the bidir and SSM alternatives are much better choices, so one might  

If PIM-SM is dominant, it is risky to throw out message types requied by PIM-SM.

---

From: John Zwiebel <[email-masked]>
Date: Tue, 12 Sep 2006 10:09:39 -0700

> Don't you think we need the spec of the igmpv3/mldv2 lite version

FWIW: I don't think the lite version you are proposing is lite enough.

You have a much better understanding of the status of the host  
implementations
than I do.  My experience is more from the perspective of what the  
router
does with the reports it receives.

To also answer Cao Wei's questions at the same time...

> Cao: And for lite version, compatibility is very important. Radical  
> changes may cause some problems for current implementations

I agree.  The question is what do you want to support in your end host.
If you want that host to do bidir, ssm and PIM-SM, then I don't believe
you can implement a lite version of IGMPv3.  (Well, not one that  
would be useful)

Let me emphasize that from the router perspective, it is difficult  
(for me) to imagine
an application that would actually want to listen to all except a few  
sources transmitting
to a group.  I'm not saying it can't be done, I'm questioning the  
practicality of it.
Being fully compliant with the EXCLUDE filter mode is difficult and  
there are "more
important" things to work on (such as AMT).  So to carry on down this  
path,
convince me of the need to support the EXCLUDE filter mode.

Another way of looking at this is that there is already a complete  
IGMPv3 spec,
what is the advantage of making it more complicated by issuing a lite  
version that
isn't lite enough?   (So there are two points I hope I've made.)

> Cao: If PIM-SM is dominant, it is risky to throw out message types  
> requied by PIM-SM.

I wasn't suggesting they be thrown out of the IGMPv3 spec.  I was  
pointing out
which message types are required to support a PIM forwarding model.

I am a huge proponent of doing as much as possible to kill PIM-SM  
deployments.  IMHO
the practical limitations of mixing shared-trees and shortest-path  
trees has
reduced PIM register messages to nothing more than a source discovery  
mechanism.
It works, but its a less-than-optimal way of doing it.  (Sometimes it  
takes years to
recognize these shortcomings.  I bought into the theory as much as  
anyone else.
I wish I'd been smarter.  But I see no reason to try to pretend that  
SM is
the only way to do multicast.)  The added complexities in PIM-SM lead to
assert messages and many data-driven events that make the protocol  
difficult
to implement in a router.  Non-RPF traffic is especially painful.   
Yes, most
vendors have figured out ways of dealing with these problems.  But  
they could
save a ton of CPU and memory in their routers if they didn't have to.

> Hitoshi: I think it would be beneficial to define lite spec for  
> dumb nodes.

I agree.  I sincerely hope and pray that such dumb nodes won't be trying
to use PIM-SM.

> Hitoshi: For these equipments, a simple and essential

Again I agree.  If these dumb hosts are going to do only SSM,
then make their IGMPv3 requirements even 'lighter'.

True of False, any query an ssm-only hosts receives will be responded
to with an IS_IN(S,G).  Why should they need to be able to deal
with all the other types of messages?

And will these systems be on the same type of network that a
fully IGMPv3 compliant host will be on?  Even if they are, what
difference does it make?

I may be naive, but an ssm-only receiver is only concerned with
adding a channel, turning off the channel and keeping the channel
alive.  3 message types.  But this discussion isn't going that direction
so I don't want to waste time proposing something that doesn't
dramatically reduce message requirements.  (ie, once the full
IGMPv3 is done, how hard will it be to put it on other devices?)

> version hosts at all. (And I don't want.:)

Neither do I.  I don't think anyone has suggested that.

> Don't you think we need the spec of the igmpv3/mldv2 lite version

yes and no.  Vendors are doing to come to the same conclusions I have
about what messages are going to be required to support a given PIM  
forwarding
model.  I can't imagine a cell phone requiring anything more than
ALLOW, BLOCK and IS_IN reports since I can't imagine anything other
than an SSM channel being required for -basic- service.  (ie, if
the phone is going to be more complicated and do more stuff then
of course it needs a better reporting capability, which argues
-against- the need for v3 lite.)

> Cao: Is bidir always "INCLUDE" filter mode? I am confused here. It  
> is contradictory to the the table above.

There is a problem with overloading of terms in the spec.  There is  
the filter mode
on the host itself and then the messages that the host sends to  
communicate the
mode that it is in.  A host can be in EXCLUDE or INCLUDE filter  
mode.  It defaults
to INCLUDE (according to the v3 spec).  You send an TO_EX{NULL}  
report to indicate
that you are in the INCLUDE {all} state.

Basically in the PIM-bidir model there is no way to prevent a  
specific source from
being forwarded down the shared tree.  You get all of the sources in  
a given group.
Therefore a router implementation is never going to prevent a given  
source from
being forwarded onto a LAN even though a host may be reporting IS_EX 
(S,G).  (It
could, but why?  The router would have to create (S,G) state for that  
source
to filter it which is contrary to the PIM bidir model.)

> Yes, according to full version,  TO_EX(NULL)  will be used as the  
> first join, and for refresh state, IS_EX(NULL) will be used. And it  
> will not introcude problem if IS_IN(NULL) message is used for these  
> two situation. Router will full version or lite version can process  
> it correctly.

FWIW: the IS_IN(NULL) message is kind of worthless.  This is the  
default state
of an interface "include nothing".  I was not suggesting that it be  
redefined for anything else.

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 13 Sep 2006 14:59:08 +0900 (JST)

Thanks, John.

> FWIW: I don't think the lite version you are proposing is lite enough.

Ok, let me try to reply for your suggestions.

> convince me of the need to support the EXCLUDE filter mode.

In our proposal, the exclude filter mode is eliminated from the
spec. We won't try to support the exclude mode by any means (e.g. by
filter mode translation).
Do you think it is impossible to just eliminate an exclude filter mode
from igmpv3/mldv2? Or I'm not understanding your point here?

> then make their IGMPv3 requirements even 'lighter'.

Yes, I'd like to try to make it as light as possible.

> with all the other types of messages?

I describe the table and meaning of each message type below.

> IGMPv3 is done, how hard will it be to put it on other devices?)

A (*,G) join/leave is needed in any host. Especially for MLD, various
service discovery protocols use (*,G) join. It is dangerous to
eliminate a (*,G) join/leave state on any host. If we keep it, we need
to support corresponding messages.

> than an SSM channel being required for -basic- service.  (ie, if

Please see the following table and descriptions;

This is needed for notifying (*,G) join. It'd be impossible to
eliminate this state even on a dumb host.

Eliminated.

You also agree they are needed.

This message is needed only when the following situation happens;
Application-1 (AP1) firstly joins IN(S,G) and the host sends
ALLOW(S,G). Then another AP2 joins (*,G) and the host sends
TO_EX(NULL). After that, if AP2 leaves (while AP1 keeps his (S,G) join
state), then the host sends TO_IN(S,G).
We cannot eliminate this message because of such situation.

Eliminated.

Needed.

> -against- the need for v3 lite.)

I'm sure above proposal does not increase implementation cost. It
should reduce the cost.
On the other hand, since it supports the required (minimum) condition,
keeping an interoperability with full version would be easy.

(In fact, although this is a different discussion, an implenmentation
of MSF Advanced APIs was costly and the most tough stuff in my
experience. That's why I also sent another mail which proposed the
possibile implementation condition in the MSF APIs a dumb host has.)

Thanks.

---

From: John Zwiebel <[email-masked]>
Date: Wed, 13 Sep 2006 10:42:56 -0700

> from igmpv3/mldv2? Or I'm not understanding your point here?

It certainly is possible.  My point is "why bother"?

But you have much more host experience than I.
I was looking at it from the router side.
I defer to you.
_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/