Subject: Re: Re: [pim] Differentiating PIM-SM from PIM-DM

From: "P.Jhingran" <[email-masked]>
Date: 5 Feb 2002 04:08:47 -0000

hi all,
        Thanx for replying. After going through your views I feel that though one can have an option like "sparse-dense mode" for PIM, using which one can communicate between PIM-DM and PIM-SM routers, but such an option will definitely be involving some new messages between the two routers. What I mean to say is interaction between them is chaotic unless one has some proprietary messages between the routers.
These proprietary messages should prevent the "chaos" which Paras is refering to, basically detecting in which mode the other router is configured or may be like whether messages like register/registerstop can be processed or not etc...all implementation specific.

Why not we can come out with some new standard (ietf-stuff) messages which can be used to identify the PIM mode configured on the neighbouring router???. 

thanx,
P.Jhingran

On Tue, 05 Feb 2002 John Zwiebel wrote :
> Not exactly chaos.  It depends on the toplogy.
> 
> "ONCE UPON A TIME..."
> 
> one could configure a dense router and a sparse router
> next to one another to transition between a sparse and
> a dense domain -- where 'dense' also includes DVMRP 
> areas.
> 
> Paras did hint at this when he said "exceptional cases".
> 
> The "sparseness" of a group is determined by whether or 
> not
> a router knows about an RP for a given multicast group. 
>  If
> it does, then the route is sparse.  If it doesn't the 
> route
> is dense.
> 
> FWIW: although it would appear at first glance that 
> dense-mode
> PIM is useful (especially now with "state-refresh"), in 
> practice
> it has not proven to be.  Part of the reason is that 
> PIM-dense doesn't work well with the "expanding ring 
> search",
> partly because of the fact that some routers throw away 
> packets with TTL of 1 or 0 if they aren't specifically 
> addressed
> to an IP address on that router, resulting in duplicate
> packet delivery in some topologies...  And part of the
> reason is that application developers don't understand
> how PIM-dense works and so the result in certain 
> Also, sparse-mode can "do" everything that dense-mode 
> can and...
> 
> in any case, SSM and bi-dir PIM may prove to be much 
> more
> appropriate than any of the multicast routing protocols 
> now
> used.
> 
> 2cents
> 
> Paras Trivedi wrote:
> > 
> > Sparse or dense used to be a property of the 
> interface in PIMv1.
> > But, in PIMv2, these days, the sparse or dense is a 
> property of
> > a group or group range. So, the interface simply 
> needs to run PIM,
> > regardless of any particular mode. (Although, in some 
> exceptional
> > cases it is needed to run an interface in strictly 
> sparse or dense mode.)
> > 
> > Most implementations (at least JunOS and IOS) allow 
> you to
> > turn on PIM, regardless of the mode, with 
> ccommand.
> > 
> > Yes, it'd be a misconfiguration to have sparse 
> configuration on
> > one end of a link and dense, on another. And PIMv2 
> hello does not
> > carry this information. So, it cannot be detected 
> automatically.
> > But, if you absolutely do this, then I guess, the 
> sparse router
> > will do sparse thing (If DR, send register, send (*,G)
>  join)
> > and dense router will do dense thing (flood and 
> expect to prune), for
> > any combination of source/receiver/transit situation, 
> leading most
> > likely to chaos.
> > 
> > - Paras.
> > 
> > >
> > >
> > > Hi all,
> > >        I have a trivial doubt.What shall happen if 
> PIM-SM and PIM-DM enabled interfaces are connected back 
> to back.
> > > PIM-SM is enabled on router R1's interface 1 while 
> PIM-DM is enabled on interface 2.
> > >
> > >         Router R1  <----------> Router R2
> > >           PIM-SM                 PIM-DM
> > >           Interface 1         Interface 2
> > >
> > > Is cisco or any other router able to distinguish 
> the above two modes?? The hello format is same for both 
> the modes and now it is up the to administrator to make 
> proper connections!!
> > > regards,
> > > Prashant
> > >
> > 
> > _______________________________________________
> > Pim-external mailing list
> > Pim-external@m
n/listinfo/pim-extern-
> al

---

From: Paras Trivedi <[email-masked]>
Date: Mon, 4 Feb 2002 20:22:49 -0800 (PST)

Most of the chaos I was referring to, was when there is a receiver
or source on the LAN that connects the two routers where one is
sparse and another is dense (which is what I called, misconfiguration).

For, interconnecting sparse domains and dense domains with a single
p2p link, with each side configured appropriately, people have achieved
the objective with non-properietry messages. 

You can look up on DWR (Domain Wide Reorts) in IDMR/MAGMA working groups,
for solving some of the issues of sparse vs dense interconnect.

Althogh, it would be cool if the admins could see the configured
mode of the PIM neighbors via hello option (eventhough we know
that configured mode may not be significant as mode
is a property of group ranges, not interfaces). 

- Paras.

---

From: John Zwiebel <[email-masked]>
Date: Tue, 05 Feb 2002 10:49:54 -0800

OPINION, OPINION, OPINION...
  
  In a previous life, I flew jets.  After leaving that one, I
  messed around for a little while as a "business man" in a
  startup involved in Laser and microwave interferometry.  Then
  I decided to 'get serious' about what I wanted to do with my
  life and got into telecommunications.  First I used that to
  launch rockets and then I got into routers.

  With such a diverse background, I kind of consider myself to 
  be a dilettante.  Heck, there are any number of people on this
  list that have more training in networking and understand all 
  the intricacies much better than I do.

  But in all that time, I learned something that I find is "best"
  described by my partner in the laser business.  You have to
  know "when to -shoot- the engineer."  My partner liked to say
  that all the time, but could never get around to shooting himself,
  which is why I'm not in routers.  :-)

  What he was trying to say is that there comes a point in time
  where you have to decide that what you have is "good enough".  You
  have to start questioning whether or not there is much to be gained
  by additional effort spent in further defining the 'product' or 
  in this case the 'spec'.  Without a doubt, it can -always- be 
  better.

  The interaction between dense-mode PIM and sparse-mode PIM is one
  example of this.  Another is deployment of (*,*,RP) trees.  A third
  -might- be the percieved usefulness and requirement of dense-mode
  PIM at all.

  I submit that each of these represents a "problem" to be solved
  and as such, are fun and interesting.  But that is because they
  are 'engineering' problems.  As such, they do have very important
  relevance.  

  The question I'd like you to think about is whether or not solving
  these problems is going to actually matter to the 'consumer'.  I'm
  talking about the guy sitting at home who is going to be the mass
  consumer of multicast data.  What is it that this guy needs?  Is
  dense-mode important to him?  Will he be receiving his data on
  a (*,*,RP) tree?

  An interesting article was in this morning's San Jose Mercury News:
    Pepsi commercial was most replayed during Super Bowl Sunday
       http://www0.mercurycenter.com/business/top/078619.htm

  Wow, people actually -like- to watch commercials.  

  "What if" Pepsi decided to put its commercials out on the internet?
  Would it be via multicast or would they use an expensive Akami/Intomi
  distribution system?  Of course, there are many, many more variables
  that would have to be considered here before a choice could be made.
  But, that is also true of whether or not dense-mode or (*,*,RP) trees
  are necessary.

  My point is -- now it the time to get out the 'good enough' version
  of multicast.  It is time to 'shoot the engineer'.  It is time to 
  be 'practical'.  

  Some questions to examine:
    -- Which is more important: Source Specific Multicast or (*,*,RP) trees?
    -- Who has the greatest potential of using IP multicast: a company
       that -must- guarantee delivery of data and is therefore willing
       to spend money on it, or one that is looking for the cheapest way
       of putting their content out there?
    -- Which is easier to implement:  getting the network to reliably
       distribute SDR announcements, or creating a web page that returns
       the source and group information to the requester?
    -- Which is easier to implement:  tuning the network to insure
       delivery of the first data packet an application might put out
       on the net or having the application send out a 30 second "test
       pattern" that allows the receivers to "tune in" before the
       transmission begins?

  Its important to recognize that I'm pushing the "easy" choice.  App
  developers may not understand multicast because it gets into choices
  of (*,*,RP) trees and dense vs sparse and BGMP and a ton of arcane
  choices that they don't have time to understand -- especially ehen they
  just figured out how to get a TCP or UDP stream to carry their 
  informaation.

  There's a science fiction story about a technologically advanced 
  society that made some tremendous discoveries during a war they
  had with "inferiors".  Yet the society that used the "good enough"
  choice, and responded fast enough was the one that won.  An excellent
  historical example is the Mongol horde that nearly conquered the 
  world.  

  Of course, you can say that 'in the end' the Mongols lost because
  they couldn't adapt their form of government.  And in the Sci Fi
  story, if you were to continue it, perhaps the technologically 
  advanced societ would have been the one that started a resistance
  to overthrow their "evil masters".  But, I'm not in this to 
  -eventually- win.  I passionately -just-know- that multicast is
  the right solution for many of the information distribution problems
  that are facing whatever organization you can think of.

  But if we get lost in arguing about the number of angels that
  can dance on the head of a 'PIM' <haha> then a viable IP
  multicast solution is not going to get deployed and isn't going
  to happen for a long, long, long time.

  Think of the 'evil empire' that we are up against.  Content providers
  don't want to use multicast because they can make an excellent 
  profit now using forms of distribution that don't even involve the
  internet at all.  The internet is a threat to them because they
  end up losing control of the form of distribution.

  But how many times have you heard "artists" (let's talk specifically
  about recording artists) complain about how they are being held 
  captive by some group of elitists (the "labels" for instance).
  How many are 'out there' that could take advantage of a simpler
  and cheaper distribution system?  Where are these folks who
  aren't "in it for the money?"  This is the group that IP multicast
  has to go after.

  And we go after them because -- "ta-dah" -- that's where the money
  is!!!  

  IP multicast is the new 'assembly line'.  It is the new 'mass marketing'
  corporation.  It is the 'efficient mode of travel'.  It is the way
  of allowing anyone -- anywhere a way of getting out their message.
  Whatever that message is.  It removes the middle man.  It frees
  the receiver from having to choose from the limited offerings of
  the networks (like cable TV did).  And, in doing so, opens up a
  new opportunity for making gobs and gobs of money as the velocity
  of that money is increased by an order of magnitude.

  Consider Hollywood's dominance of the entertainment industry.  Yes
  they are the "best" when it comes to making a movie.  But look at
  all the inefficiencies.  Why should Michael Eisner get paid millions
  and millions of dollars?  Its because he has a monopoly on the
  distribution of product.  People who make movies want to profit
  from them.  The only way they can profit is if they gain Eisner's
  blessing.  What if a content provider in Timbuktu were able to 
  scrape together $5000 and was able to make a very compelling movie.
  Would Eisner support it?  Would you ever see it?  What if that movie
  were made available on the internet via a "good enough" delivery 
  system that made a return on investment possible.  If the movie
  is 'multicast' and encoded -- yes there will be some loss of revenue
  because of fraud on the part of the receivers -- will it provide
  enough credit card subscritions to encourage the content provider
  to try again?

  So, all this leads to asking those of you on this list, what is it
  you want to have happen with this IP multicast stuff you've been 
  working on.  Is it important to you that you have solved all the
  dense/sparse interaction problems?  Is it important that (*,*,RP)
  trees are deployed?  

  Or do you want to do something that is "good enough" and enables
  new ways for people to interact with each other.  New ways that
  can be seen as socially "good" or ways that can be "mined" for
  'lots-of-bucks'.  Especially when the 'lots-of-bucks' approach will
  lead to the recognition of the need for alternate forms of 
  ip multicast services that can only be realized if the sparse/dense
  and (*,*,RP) problems are solved.

  I've been doing IP multicast for nearly 10 years.  It "ain't a goin'
  no where".  I want to see it 'out there' and used.  Providing solutions
  for problems that don't yet need to be solved, while ignoring the
  interoperation problems that are standing in the way of deploying
  a "good enough" solution is a way of commiting a slow and painful
  suicide.  

  It is time to 'shoot the engineer'.  It is time to make a robust,
  interoperable, and simple solution that will "prove" the viability
  of multicast so that you can work on all these other 'interesting'
  problems.  We need something that is "good enough".

  I have an opinion on what that is -- I've stated it often enough
  that everyone 'should know' what it is.  I had to be persuaded that
  it was the right choice, but now that I've been converted, the 
  obviousness of that choice is extremely compelling.  If you recognize
  that choice, then it should be obvious to you that getting (*,*,RP)
  trees to work just isn't important right now.  Your boss may be
  telling you that you need the best PIM implementation possible, but
  what gives him the prescience to know that?  Is he just "listening
  to the customer"?  An excuse for not thinking about what really
  works and a way of avoiding having to "do something" about it.  
  When a customer doesn't know what the product is, you have to teach
  him.  Your customer isn't the people on this list.

  Multicast is in the "push" stage of technological evolution. Its
  time to get out there and push. 

2cents

"P.Jhingran" wrote:
> > toplogies
> > is unexpected.
> > > [email-masked]
> > > http://mailist.procket.com/mailman/listinfo/pim-extern-
> > al
>

---

From: Greg Shepherd <[email-masked]>
Date: Tue, 5 Feb 2002 12:36:59 -0800 (PST)

Reverend John has spoken! -I'm not being sarcastic and he knows it.

Thanks John,
Greg

---

From: Beau Williamson <[email-masked]>
Date: Wed, 06 Feb 2002 09:50:47 -0600

John,

I pretty sure I've told this before, but I think you missed your true calling.

:) :) :) :) 

Beau Williamson