Subject: [magma] draft-liu-magma-igmpv3-mldv2-lite-00.txt

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Jun 2006 12:49:17 -0700

I am not on this list and sorry if I will be repeating what others may
    have stated (because I haven't seen any of them) but here is my brief 
    comment on this draft.

    I think this is a good effort. This has been confusing for many years
    and we don't need more obstacles from getting more multicast deployed.

    Specific comments:

    1) Don't use the term ASM in the draft. Refer to "Exclude(NULL)" as  
       joining a (*,G) entry rather than a specific (Si,G) entry. Same
       for the "Include(All)" case.

    2) I think IGMPv3-Lite can be made much simpler and still serve a useful
       purpose. It's good that Change-to-* record types are not recommended,
       but I believe Allow-new-sources and Block-old-sources are not needed
       either. Why not just have:

      o  Current-State-Include, where when the source count is non-zero, it
         is the host joining the various (Si,G), where each Si is in the source
         list. When the source count is zero, the host is joining (*,G).

      o  Current-State-Exclude, where when the source count is non-zero, it
         is the host leaving the various (Si,G), where each Si is in the source
         list. When the source count is zero, the host is leaving (*,G).

    This would make the protocol machinery and implementations work more like
    IGMPv2/MLDv1 and think it would be compatible with popular application
    uses.

    Comments?

Dino

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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 28 Jun 2006 16:03:44 -0400

I have a couple of comments only to this:

-------Original Message-----
> From: Dino Farinacci [mailto:[email-masked]] 
>     Specific comments:
> 

I would prefer to see, at least once in the beginning, that joining
(*,G) is equivalent to ASM. This makes it clear that IGMPv3/MLDv2 are
also usable for ASM, to potentially replace all previous versions of
IGMP and MLD.

Also, maybe I've missed something obvious, but clearly EXCLUDE(null)

>          list. When the source count is zero, the host is 

implies it means the same thing as EXCLUDE(null). But logically, I don't
see that.

Bert

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 28 Jun 2006 13:10:53 -0700

>> also usable for ASM, to potentially replace all previous versions of

    It depends how you use the term ASM. We want an IGMPv3 host to join
    a (*,G) entry where the network has that group configured to run in 
    Bidir-PIM mode. And in many circles the term ASM is different mode than
    Bidir-PIM mode.

    But I agree with your point in principle. It's just jargon I'm raising.

>> means joining (*,G) like ASM. What does INCLUDE(null) mean? Below:

    Prune (*,G). But again for clarity why use the double-negative when
    Include-All and Exclude-All can do the same thing.

>> implies it means the same thing as EXCLUDE(null). But logically, I don't

    Right, but at the same time I fixed the double-negative situation and
    having two ways to join (*,G) and leave (*,G). Less options are good
    for implementors and encourage interoperability sooner.     ;-)

Dino

---

From: John Zwiebel <[email-masked]>
Date: Wed, 28 Jun 2006 15:10:53 -0700

I don't think this would be compatible with the current RFC.
Certainly the Exclude(NULL) is inverse of the current implementation.
If we were to start from scratch, I'd support the simpler approach.

FWIW: I believe that most host operating systems (or is it the
OS with a majority of users?) have already implemented the current RFC.
Its in windows XP, Linux 2.6 and BSD flavors of Unix.

Therefore, IMHO the effort to make IGMPv3-lite is too late.

OTOH, if some one wanted to write an 'interpretation' of the igmpv3
RFC in 'plain english' that would be greatly appreciated.  :^)

And if someone wanted to write a BCP that said "routers don't know how
to exclude specific sources" and what that means, that would be a
"good thing".  (Perhaps it would be better to say current multicast
routing protocols don't know how to -easily-, in a scalable manner
exclude specific sources from the shared-tree.)

So, when a router receives an EXCLUDE with a list, perhaps it should
-always- interpret that as an EXCLUDE(NULL).  {FWIW: the implemenations
I've seen use BLOCK to remove specific sources.}

It "would be nice" if Stig could outline the problem he has seen with
a partial implementation.  I'd like to understand it.

Needless to say, the router has to protect itself.  And although
the IGMPv3 RFC states that IS_ reports are only sent in response to
queries, customers aren't going to be happy with router vendors who
don't process the IS_INC/IS_EX reports.

Routers are suppose to TRIGGER queries on the CHANGE_TO reports
which, IMHO, should have been left up to the router.  If his IGMP
cache doesn't change, why trigger a report?

WRT to "small" devices (like a phone), perhaps they need send only
"BLOCK" and "ALLOW" reports.  And perhaps on such networks there
would be no need for IS_ reports because there would be no query needed.
The link such a device is on would emulate a p2p link, and IGMP state
can be aggregated by whatever upstream device is there.

So with all this divergent BS... I guess the point I want to make
is:
   -- IGMPv3 is mostly available already on hosts
   -- The problem seems to be on the router with what to do with all the
	EXCLUDE type reports and timers.  (eliminating the need
	for an interface-filter-mode which someone suggested was a
	requirement of this new spec.)  Couldn't this best be handled
	by a BCP?

ONE LAST POINT:  (hmmm... I'll put this into a separate email, please
   don't respond on this thread.)
The v3-lite spec discusses ASM and SSM.  Like Dino, I think SSM is well
defined, but ASM is not.  But reading the spec, I need to ask how an
SSM group range is allocated.  We know that currently it defaults to
232/8, but that routers can configure locally it for any range.  Routers
specifically reject (*,G) IGMP host reports for groups in the SSM range.
AND routers -reject- (S,G) IGMP host reports for ASM groups.

The spec combines ASM and SSM in a way that suggests to me that at  
least some
of you would be "surprised" to see this.