Subject: RE: draft-ietf-pim-dm-new-v2-04.txt

From: "Nicholas, Jonathan" <[email-masked]>
Date: Mon, 23 Jul 2001 07:09:36 -0500

Thanks.  We should probably arrange some sort of sidebar in London to
discuss solutions to this.

Allow me to take a moment and suggest that state refresh might be done from
the receiving end.  If Assert Winners reassert when the assert timer expires
and routers sending Prunes resending Prunes when their Prune Hold Time
expires, wouldn't that prevent periodic reflooding?

I expect that there would have to be some limit to this refresh to allow
stale sources to age out, freeing memory, etc.

If we add to this requirements to immediately Graft or Prune when things
change, it seems to me that the problems of wasted resources, instability in
states and slow response are resolved.

Of course, many details will need to be resolved.

> Let me restate the "problem" so we're all on the same page.
> 
> PIM-DM without state-refresh requires periodic flooding
> of data to maintain state for a given (S,G).  This results
> in several problems because for networks with few (sparsely 
> populated) members data if flooded to the boundaries of the 
> network resulting in:
>   -- wasting bandwidth.
>   -- reprocessing of asserts
> 	o waste of router CPU
> 	o waste of host CPU (MAC level filtering doesn't
> 		always work or isn't turned on)
> 	o asserts are complicated enough and prone to error.
> 		Should be avoided.  
> 		Many network problems I've seen have been related
> 		to asserts.  Granted many of these are because of
> 		implementation problems, but if you do the assert 
> 		1 time and then keep that information alive with
> 		state-refresh, it may be "wrong" (from a RFC
> 		perspective) but at least it won't keep breaking
> 		everything.
>   -- extremely difficult to debug.  Sparse-Mode olists are
> 	"correct" as long as there are receivers.  Dense-mode
> 	can come and go and still be "correct".  One time you'll
> 	look at the mroute table and the interface will be there,
> 	seconds later it will be pruned.  You can't trust the 
> 	information.  To recreate many problems, I found it
> 	necessary to think of what "might" be happening and then
> 	see if I could design a test that had very elaborate 
> 	steps that could be duplicated precisely.  It was impossible.
>   -- state doesn't time out along a very long path "nicely".
> 	If you have (for example) 10 hops leading to a receiver
> 	who hasn't joined the group, each hop can delay processing
> 	the prune received from the downstream PIM neighbor for
> 	up to 10 seconds to correctly process JOIN overrides.  That's
> 	100 seconds that the source-first hop router may have been
> 	forwarding data before it receives a prune.  If your receiver
> 	decides to join the multicast group 1 second after the
> 	(S,G) times out on its last-hop router, it will have to
> 	wait as long as 99 seconds for the first-hop router to
> 	time out that (S,G) and reflood data to the edge of the 
> 	network.  This is avoided if you have a member on every 
> 	subnet in your network.  For something like the auto-RP
> 	mapping agent, since the messages to 224.0.1.39 are sent
> 	1/minute and the information is "the same", this generally
> 	isn't a problem.  For other applications though, its
> 	a guarantee that data will be lost.
> 
> FWIW, state-refresh advertises a source to the boundaries of 
> the network forever.  This is a "good thing" if you are thinking
> of using dense-mode instead of sparse-mode (maybe OK) or SSM (not
> a good idea).  It isn't clear to me how it can or should be 
> effectively used for something like an expanding ring search.
> 
> There are now 4 modes in PIM.  SSM is the _obvious_ choice for
> interdomain multicast which (appears) will be the dominent
> use of multicast because it will be one to many.  SSM is also
> useful for many-to-many -- if the application figures out a way
> of doing RP functionality (meaning the receiver has to know
> the specific source address, not so different from unicast
> where the source has to know the receiver address.  It's very
> important to note that DNS is _NOT_ part of a routing protocol
> (like ospf) so one questions why multicast ever went down the
> "RP" path and why, once SSM was proposed, it was received so
> negatively (mea culpa).
> 
> Bi-dir PIM is an obvious choice for many-to-many within an
> enterprise.  How many applications can you think of _really_ are
> many-to-many?  What I mean hear is so_many-to-so_many.  TIBCO
> is, but that is hundreds of computers sharing information with
> one another.  Any application that includes "people" that goes
> beyond 10 participants will have to require a "master of 
> cerimonies" to arbitrate who's going to talk when.  In those
> apps, a 1-to-many SSM session with unicast from the receivers to
> the SSM source relayed down the SSM distribution tree is the
> answer.  (RTCP "failed" because it created so much state in
> the routers the multicast session -- and the entire network --
> died.  "reflecting" RTCP packets from the "master" source
> has a much brighter future.)
> 
> Sparse-mode is "dead".  My comments on the RP being inside of
> the routing protocol I think support its "death".  (Although
> it may be long and painful and I'm certainly not saying
> to abandon it today since it does work.)  
> 
> That leaves dense-mode.  I believe that with state-refresh it
> offers a necessary capability.  The "rp-functionality" (where
> receivers discover sources) is extremely simple.  As long as
> a source is sending, receivers know it.  But it isn't clear that
> this is all that much better than putting the source
> information into a web-page (ala SSM).  
> 
> So, the fabled "expanding ring search" is all that's left for
> dense-mode.  Now the question is, does such a search require
> continued communication via multicast once the "service" is
> found?  IMHO, no.  But there may be some charaturistics I'm 
> missing.
> 
> Hope you find this helpful.

Jonathan Nicholas
Network Systems Engineer
ITT Aerospace/Communications Division

---

From: John Zwiebel <[email-masked]>
Date: Mon, 23 Jul 2001 11:30:09 -0700

> discuss solutions to this.

...

> Of course, many details will need to be resolved.

Actually, I do not believe there are.  Cisco implemented the
state-refresh draft and I was unable to find any holes in it.
Of course, there haven't been any large-scale deployments of 
it so perhaps there are some hidden "gottcha's", but, IMHO,
state-refresh is much more stable than vanilla dense-mode PIM.

> stale sources to age out, freeing memory, etc.

Of course, this already exists in the state-refresh draft.  If the
source isn't sending the first-hop routers don't originate state-refresh
messages and the state times-out just fine.

This expired draft still is available on the IETF site:
	draft-ietf-pim-refresh-02.txt

> expires, wouldn't that prevent periodic reflooding?

If you want to propose a different scheme than the one already
implemented,
that's fine with me, but you'll probably come up against some strong
resistance that, in the end, will result in no dense-mode.  As I've 
already stated, there are a significant number of vendors who believe
dense-mode is not useful.  I am not in this group, but I do believe that
SSM and Bi-dir may be "good enough" and that dense-mode is really just
a "niche" player.  (Note: I said "may be" meaning I'm not taking a
stand for or against, just pointing out what I view the realities to
be.)

But, to try to not confuse anyone, PIM dense-mode without state-refresh
of some variety, absolutely should _NOT_ be deployed in a medium to 
large-scale network.