Subject: [pim] RE: Why Dense?

From: "Nicholas, Jonathan" <[email-masked]>
Date: Thu, 4 Sep 2003 19:56:22 +0100

I cannot speak for others, but PIM-DM is a good solution for several
military applications.  The properties of these multicast groups are a high
density of members (in some cases everyone) and a large number of sources.
Bandwidth is also at a premium while processing power is cheap.

The military also tends to view an RP as a single point of failure, which is
an unacceptable risk.

In addition, regardless of whether you believe PIM-DM is the correct
solution for the applications involved, it is the solution they have adopted
and are using.  

Finally, I believe PIM-DM has seen too much work and use for it to not get
into the permanent record (i.e. an RFC).  I would like to see it get
Proposed Standard status, but I expect Experimental.  In either case, a well
archived reference would exist, which is my main purpose.

Regarding the TTL problem, we (the authors) debated the issue briefly before
deciding that applications depending on particular behaviour with such
situations were a bit too esoteric to address within the new spec.  If you
have good reasons and specific text you would like to recommend, we would be
pleased to consider it.

Jonathan Nicholas

> -----Original Message-----
> From: John Zwiebel [mailto:[email-masked]]
> Sent: Thursday, September 04, 2003 2:05 PM
> To: Bandi Sarveshwar-G19441
> Cc: Nicholas, Jonathan; kishore kishore; [email-masked]
> Subject: Why Dense?
> 
> 
> 
> Since the dense-assert question went by...
> 
> I'd like to get some feedback on what is driving continued
> dense-mode development.  I'm not judging it one way or the other,
> but rather am interested in determining the applications
> that may be expected to use this service, and why dense --
> vs. ssm or bidir -- is more appropriate.
> 
> I'd like to point out problems with ttl=1 packets where
> routers which might be expected to assert won't because they
> first decrement the ttl, discover it is 0, recognize the
> packet isn't for one of the assigned IP addresses and then
> throw it away.  (I don't recall if this is addressed in the
> new spec.)
> 
> So, this ttl problem kind of limits the usefulness of certain
> types of expanding ring searches.
> 
> Again, I'm not saying that this shouldn't be "fixed" by the
> vendors, I bring it up for interoperability and because its
> something that can be easily overlooked making an expected
> service rather useless.
> 
> So, who is using dense and why is it "better".
> 
> Thanks
> 
> 

************************************
If this email is not intended for you, or you are not responsible for
the delivery of this message to the addressee, please note that this
message may contain ITT Privileged/Proprietary Information.  In such
a case, you may not copy or deliver this message to anyone.  You should
destroy this message and kindly notify the sender by reply email.
Information contained in this message that does not relate to the
business of ITT is neither endorsed by nor attributable to ITT.
************************************

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

---

From: John Zwiebel <[email-masked]>
Date: Thu, 4 Sep 2003 12:23:20 -0700

On Thursday, September 4, 2003, at 11:56 AM, Nicholas, Jonathan wrote:

> military applications.

FWIW: I was present at some of the initial discussions for the military
deployment.  I'm sure its changed -a-lot- since then.  (At least I
hope so. :-)  Also after many years in the AF, I understand how 
difficult
it is to get the military to change to new technology.

> into the permanent record (i.e. an RFC).

I agree.  I "used to" be in the camp that supported continued dense-mode
development thinking that someone would come up with a good idea.  Now
I'm not so sure.  I think SSM or bidir might be a better solution.

WRT the RP being a single point of failure, in bidir the RP is virtual
any failure is no worse than dense-mode.  Of course, the fact that
there are no SPTs is definitely a "down-side".

Which then brings up SSM and its problem of "how do you know which
source to join".  I would think that getting something from intel
(or some other group) would be extremely easy since you allocate
an IP address with the specific call sign before you deploy into
the field.

But at the same time, I can also see that a "source" at the front
might need to dense-mode his information to lots of other organizations.
(but then -- perhaps -- bidir works.)

I'm not against (or for) dense-mode.  I'm only pro-multicast and
want to be sure that we are all speaking the same language.

> Regarding the TTL problem,

Nothing specific.  But a note in the RFC that says, "watch out" or 
something
like that would be nice.  I agree that an RFC is kind of a hokey place 
to
address this issue, but I also know lots of folks who deployed 
Symantec's
Ghost (I know it was Symantec, I'm not sure of the name) were 
blind-sided
and I'd rather be hokey than not be open.  OTOH, its your document so it
you don't want to mention it, I can understand.

Thanks for the reply.  I'd love to hear from others.