Subject: [pim] Overriding an (S,G,R) prune

From: John Zwiebel <[email-masked]>
Date: Thu, 30 May 2002 19:18:53 -0700

The March 2002 draft says that when you see an (S,G,R) prune
and you have (S,G) state that it is necessary to send a
join override to be interoperable with 2362 implementations.

FWIW: It was recognized a long time ago that overriding
an (S,G,R) prune added an enormous amount of control traffic
since it would have to override every minute.  And then it
was recognized that -not- overriding such a prune would
lead to cutting off downstream receivers.  If this item is
incorporated into your implementation and you have merely
"hundreds" of mroutes, PIM will end up taking up way too much
of the CPU and users will be disenchanted with multicast (what
else is new).

I believe most PIMv2 implementations ignore (S,G,R) prunes
when received on a (S,G) mroute.  (certainly the routers
from the "LRV" do)

The new March 2002 spec discusses this in 4.5.7, but "it would be
nice" if the spec suggested that this step (and overriding
(*,G) prunes if you have (S,G) state) be a "MAY" or at least a
"SHOULD" but certainly not "MUST" or "REQUIRED".

Failing that, I hope implementers out there will remember:
   -- the goal should be to disentangle the control traffic
	for the shared-tree from the control traffic for the
	shortest-path tree.  (ie, if you have (S,G) state and
	see a (*,G) or (S,G,R) message, you should ignore it
	if it is a prune, and react to it if it is a join)
   -- if SSM were deployed we wouldn't have to worry about this.

2cents

I am starting a fund for IGMPv3.  I'd like to get donations
that I can apply to some willing consultant/student (whoever)
able to get IGMPv3 into Linux and FreeBSD so we can get on
with the transition to SSM and not have to worry about
interdomain ASM.

Anyone willing to donate?

z

_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 31 May 2002 02:09:10 -0700

>> Anyone willing to donate?

    Where can I send money?

Dino

---

From: "Marshall Eubanks" <[email-masked]>
Date: Fri, 31 May 2002 08:56:39 -0400

On Fri, 31 May 2002 02:09:10 -0700
> >> Anyone willing to donate?

Dino, John;

   We would glad to send you a proposal to hire a couple of interns and push
this through ;)

   My experience is that no open-source project really advances fast without at
least a little money. I have fought this with Vorbis, which I view as cool but
unnecessary (and probably not truly patent free, BTW). I have tried to convince
the people that code Vorbis that multicast is essential to a cost-effective
streaming solution for the open source community, but without the slightest
effect.

   IMHO, unless someone is willing to fund this at a serious level, SSM progress
will continue to be halting and slow. The frustrating thing is that I know a lot
more is being spent in implementing the RFC's in switches and routers.  

Regards
Marshall

---

From: John Zwiebel <[email-masked]>
Date: Fri, 31 May 2002 09:51:44 -0700

On Friday, May 31, 2002, at 04:25 AM, Mark Fullmer wrote:
> http://home.hetnet.nl/~wilbertdg/igmpv3.html
>
> This worked at one time.  It's what I used when adding SSM support to 
> VIC and
> VAT.
>
>

Sorry if anyone thinks I was saying anything bad about Wilbert's
implementation or the tremendous effort he has already put into
getting this protocol into FreeBSD.  I've used, and continue to use
Wilbert's patch and I have found it reliable.

However, FreeBSD is now at version 4.5 and the last patch available
is for 4.2 so you have to have a lot of patience to get the patch into
the right files so you can rebuild the kernel.

But more importantly, at least to me, MacOS is built on Darwin which
I like to think of as a Mach kernel with FreeBSD wrapped around it.
When FreeBSD has IGMPv3 in the kernel as part of the standard release,
it will 'automagically' move to MacOS.

Then we would have two "user friendly" operating systems with IGMPv3
and the ability to do SSM.  Apple is part of the ISMA, a group that is 
trying
to put together a "standard" MPEG4 player that won't depend on 
proprietary
code from Microsoft or Real.  (But this is a orthogonal to my point).

The point is, you still have to apply a kernel patch to get IGMPv3.  
There
are a lot of folks out there that don't know how, or don't want to do 
this.
(And some of us that have been successful, have no idea what it is we're
really doing. ;-)

It's been stated in several forums that the IGMPv3 available for Linux
is incomplete so my communication with a few folks on linux.org
suggests its going to be impossible to incorporate it into something that
(RedHat, whoever) might resell.

Its my understanding that before it can be part of the 4.x release, there
has to be an implementation available for 5.0, and that 5.0 has changed
considerably so that getting IGMPv3 in, won't be easy.

Then there is the IPv6 question.  Where does MLD stand WRT SSM.
I don't think it does....

So, Wilbert has done a great job, but he has a real job or other demands
outside of this.  And Bill has spent a lot of time on this as well, 
without
a lot of benefit accrued back to him (other than greatly enhancing his
reputation for being a really nice guy.  And as he told me when I first 
met
him, "we're all nice guys".)

But we shouldn't be forcing them to do everything.  (Although I imagine
they'd think I'm being pretty pushy)

So, I'm looking for some other resources to get this to move forward.

Bottom line, if this group wants multicast to be something other than an
interesting side show, we have to get away from MSDP deployment.
Flooding the internet with lots of control messages and encapsulated
data packets works now, but it isn't going to continue to work.  
(Besides,
no one really understands MSDP, RPFing to a BGP speaker?  What's
that all about?  Is is inside the AS or outside?  Jeeze ... <just 
expressing
the confusion I've heard from customers>)

SSM offers a way of reducing dependence on MSDP while preserving
the best benefits of multicast WRT how it is currently used: ie 
one-to-many.
SSM won't go anywhere without IGMPv3.

If I knew anything about kernel coding (or anything about doing anything)
I'd do it myself.  But, I know my limitations and the result would be a 
substandard
product 3 years from now.  That isn't going to be good enough.

I want my MTV

z

---

From: Mark Fullmer <[email-masked]>
Date: Fri, 31 May 2002 07:25:33 -0400

This worked at one time.  It's what I used when adding SSM support to VIC and
VAT.

mark

---

From: Liming Wei <[email-masked]>
Date: Fri, 31 May 2002 10:14:29 -0700 (PDT)

Very interesting Z-atagram :-).

All this OS-incurred-hardship will be "greatly-removed" if IGMPv3 does
not have to go into the kernel(s).

If the current IGMPv3 reports can be encapsulated inside UDP and MUST
be addressed to the standard IGMP v3 report address (224.0.0.22).
You would have no need to worry about Linux or FreeBSD or MacOS or
WindowsXP/2K/98/...

I remember Hugh Holbrook started his work on SSM on this path but
dropped it later for some reason.

-Liming
-------------
> From: John Zwiebel <[email-masked]>
>

---

From: Dino Farinacci <[email-masked]>
Date: Fri, 31 May 2002 12:52:57 -0700

>> dropped it later for some reason.

    Has anyone finished this work?

Dino

---

From: Liming Wei <[email-masked]>
Date: Fri, 31 May 2002 13:31:32 -0700 (PDT)

> From: Dino Farinacci <[email-masked]>
> 

Obviously not, or we would not have seen this thread.

How much interest is there to re-start the work on this seemingly
simple thing ?

Let me know if I am oversimplifying things, but an addition of
a couple of short paragraphs in the IGMP v3 draft would do, such as,

-----------

"The IGMP v3 reports and queries can use an alternative UDP encapsulation,
 with a recommended port number of XXX. The only difference between
 this encapsulation and the native encapsulation is the extra UDP header
 in between the IP header and the IGMP v3 message. The v3 reports
 under the alternative UDP encapsulation must be addressed to
 224.0.0.22."

"All IGMP v3 implementations SHOULD support the UDP encapsulation.
 An IGMPv3 querier will rely on administrative configurations to
 decide which type of encapsulations to use for the IGMP queries.
 An IGMPv3 router SHOULD accept v3 messages in both encapsulations
 irrespective of the local encapsulation configuration."
------------

This is easy to understand/implement/deploy (at least to me :-)).

I don't think it needs to be too fancy to to accommodate all
combinations of different routers/hosts supporting a subset of the
encapsulations.

 Comments ?

-Liming

---

From: Brian Haberman <[email-masked]>
Date: Fri, 31 May 2002 20:49:51 -0400

John,

> I don't think it does....

I wouldn't make such a statement.  Consider the following:

     1. MLDv2 (aka IGMPv3 for IPv6) is a MAGMA WG document
        (draft-vida-mld-v2-02.txt)

     2. The SSM overview draft (draft-ietf-ssm-overview-03.txt)
        contains the requisite discussion of IPv6 support

     3. The SSM architecture draft (draft-ietf-ssm-arch-00.txt)
        has included IPv6 features

     4. An IPv6 multicast address range has been allocated for
        SSM (draft-ietf-ipngwg-uni-based-mcast-03.txt)

     5. The revised PIM-SM spec contains some modified text for
        IPv6 (draft-ietf-pim-sm-v2-new-05.txt)

So it seems that IPv6 has all the necessary pieces incorporated
to support IPv6.

Regards,
Brian

---

From: John Zwiebel <[email-masked]>
Date: Fri, 31 May 2002 17:59:10 -0700

> So it seems that IPv6 has all the necessary pieces incorporated

yep, everything but code in my PC.

---

From: Greg Shepherd <[email-masked]>
Date: Fri, 31 May 2002 19:44:20 -0700 (PDT)

Except a stack in the kernel of all the relevent OSs and applications that
support it.. Should I hole my breath? ;-)

Greg