On Sun, Feb 05, 2006 at 08:29:12AM -0500, Dave Diller wrote:
> > Step one would probably be a PIM-DM, later on it can be expanded to support
> > PIM-SM.
>
> Hmm - is there still a userbase for DM that would warrant supporting it first
> from a practical standpoint, or is it simply that it is much easier to code
> and
> lays the groundwork for SM without diverting resources from SM too much?
>
Those who designed SM had serious mental problems. The protocol is insanly
complex. Doing DM first is the only way to go.
> My only frame of reference is the advanced higher-ed community, where only the
> "opt-in" explicit-join paradigm of SM is in use. Flood-and-prune ("opt-out")
> is explicitly NOT recommended for use in a production environment at this
> point.
>
Depends on your multicast need. In some situations doing a flood-and-prune
setup is far better than the added complexity of SM. If bandwith does not
matter I would go for simple and robust but inefficent instead of hype
super-duper complex but more efficent.
> RFC2362 has been obsoleted by draft-ietf-pim-sm-v2-new-11.txt, FWIW. Since
> it's
> an expired draft and could well evolve further, I don't know if you would want
> to use it - but its the current thinking by the WG:
>
> PIM-SM version 2 was originally specified in RFC 2117, and revised in
> RFC 2362. This document is intended to obsolete RFC 2362, and to
> correct a number of deficiencies that have been identified with the way
> PIM-SM was previously specified. As far as possible, this document
> specifies the same protocol as RFC 2362, and only diverges from the
> behavior intended by RFC 2362 when the previously specified behavior
> was clearly incorrect. Routers implemented according to the
> specification in this document will be able to successfully
> interoperate with routers implemented according to RFC 2362.
>
Where does it stand that RFC2362 has been obsoleted.
The draft does not matter because well it's a draft.
--
:wq Claudio
