Subject: RE: [pim] about the (*,G),(S,G) entry creation and deletion

From: "bharat_joshi" <[email-masked]>
Date: Wed, 21 May 2003 13:19:08 +0530

Hi,

*,G state will be there when IGMP hosts have not been updated to IGMPv3 
and the desginated rotuers doesn't support IGMPv3.

Lets say we have IGMPv2 on a LAN, the DR will always generate a *,G 
join/prune for a IGMP join/leave message.

S,G state will come in picture when DR start switch to SPT but in this
case you will need to maintain *,G and S,G both becuase the router will
never come to know that the hosts connected to LAN wants packet from 
which all sources.

If hosts are running IGMPV3 than a *,G entry may not be created.

Thanks,
Bharat

-----Original Message-----
From:	Bandi, Sarveshwar [mailto:[email-masked]]
Sent:	Wed 5/21/2003 12:13 PM
To:	'Zhang Yanxing'; [email-masked]
Cc:	
Subject:	RE: [pim] about the (*,G),(S,G) entry creation and deletion

One comment, I dont think the spec says explicitly that a (*,G) should exist
when (S,G) exists. If someone were to have only SSM routes in a network,
having (*,G) routes would not make any sense. I think creation of (*,G)
route when (S,G) routes are created is an implementation issue. We have an
implementation where (*,G) routes created as and when needed.

Would love to hear others comments on this

Regards,
Sarvesh

-----Original Message-----
From: Zhang Yanxing [mailto:[email-masked]]
Sent: Wednesday, May 21, 2003 8:06 AM
To: [email-masked]
Subject: [pim] about the (*,G),(S,G) entry creation and deletion

      I think it maybe one implementation problem, I want to speak out my
thought to see if it is correct.
Multicast Route entry is created when some interfaces receive the (*,G) or
(S,G)  join message. 
When all the joined before interfaces recieve prune message(after the prune
override interval) or
the join timer expires, the entry will be deleted. This mechanism shows the
difference between the DM and 
SM.
     But at the DR with the directly connected senders and the RP, I think
the (S,G) entry creation is something 
like the DM, it is built by the traffic driven.
     Another point is that does the specification imply that if (S,G) exist,
the (*,G) should exist too?
     Welcome comments, Thanks.
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim
_______________________________________________
pim mailing list
[email-masked]
http://catarina.usc.edu/mailman/listinfo/pim

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

---

From: John Zwiebel <[email-masked]>
Date: Wed, 21 May 2003 09:53:26 -0700

There seems to be some confusion...
Please listen to me when I tell you "ASM is dead"
Long live SSM
Long Live Bidir.

My point here is, much of the discussion on this list is about
nitty details on how to implement the PIM-SM draft.  This is, of course,
necessary to be able to interoperate with legacy multicast deployments
and to allow users the opportunity to see how SSM and Bidir might
benefit them.  HOWEVER, you need a "good enough" ASM implementation
and you should be concentrating on developing a superior SSM and
Bidir implementation.  (Of course, if you don't want to go that route, 
that's
fine with me, we'll be happy to sell into that market.)

After 10 years of looking at this stuff, here are some points to 
consider.

  -- For ASM: When an RP receives a PIM register, it -should- create 
(S,G) state
	whether or not there are receivers.  Receivers may join after the 
source
	has started to send and you don't want to have to wait for 60 seconds 
for
	the first packet to come down the shared tree.

-- The shared-path and the shortest-path are two different entities.  
In ASM 
	the -only- reason for the shared-path is to deliver the first data 
packet to
	the receiver so the last-hop can join to the shortest-path.  BEFORE, 
you
	all say, "but what about staying on the shared-path", yes it is 
possible
	to do this, but let's be very clear, if you elect to stay on the 
shared-path
	it is impractical to switch to the shortest-path when/if the data rate 
of
	a particular source rises above a given threshold.  Yes, some 
implementations
	do this.  But it -does-not- work.  Therefore, if you are going to stay
	on the shared-path, the spt-threshold -must- be set to infinity.  And 
if
	you are going to do that, why aren't you using bidir.

-- If you think of the shared-path and shortest-path as separate 
entities, it
	becomes easier to figure out what's suppose to happen when they
	intersect.  There are -tons- of things that the spec does not specify.

	For example: if you are a transient router, and you haven't received
	a PIM (S,G) join, but you do see multicast traffic on a non-RPF 
interface
	what are you suppose to do?  From the specs perspective: nothing.
	From a practical perspective though, doing nothing may be very, very
	costly depending on the size of the data pipe (ie is it a 10gig 
interface
	with 9gig of multicast traffic -- of which every multicast packet must
	be examined by the router to determine whether or not the router
	is suppose to deal with it.)  (SSM and bidir reduce these problems
	considerably)

-- WRT SSM, the only router that requires anything different from ASM 
SPT
  	code is the last-hop.  The last-hop needs to be informed of the source
	in some way so it can join to the shortest-path.  Whether it is IGMPv3
	or data delivered down the ASM shared-tree or Cisco's URD, or whatever
	new receiver-to-router protocol you might want to implement, once
	the router knows the (S,G) it triggers a join toward the source and the
	forwarding path is brought up.  BEFORE you say "what about the
	keepalive timer", remember users don't care as long as the data is
	getting received.  Yes, in SSM the receipt of a PIM (S,G) join is 
suppose
	to update the keepalive timer and this does not happen with ASM.
	This is a very minor difference that isn't going to be noticed if data
	is being forwarded down the SPT.

-- The biggest mistake we made in developing PIM was to believe that it 
was
	impossible to change the multicast model.  It is silly to think that 
we will
	ever be able to develop fast enough routers that the network will ever
	be reliable enough to "just handle" delivery of the first packet data 
packet
	to every receiver in the internet.  Some sort of 
"request-to-send/cleared-to-send"
	mechanism is required.  Right now that mechanism defaults to, "go ahead
	and send, if I (the receiver) miss something I won't care" because 
most multicast is
	audio/video.  Something better is required if we are going to be able 
to
	deliver file transfer via multicast.  (PGM not withstanding.)  It 
appears
	to me that this RTS/CTS mechanism is probably application specific, or 
is
	at least, a layer-4 problem.

-- PIM-SM is extremely complicated because of the switch between the 
shared-path
	and the SPT.  It is non-deterministic because one never knows where 
these
	two paths will diverge or intersect with one another.  Assert 
processing is
	extremely difficult to do without incurring huge CPU costs -- unless 
you are
	talking about a very low-end router.  If your product is such a 
router, you may
	think that you don't care about the problems of the high-end vendors.  
But the
	high-end -must- move away from ASM.  If you (the low-end) don't move 
the
	same way, multicast will spend another 10 years not realizing its 
potential.

-- SSM is simple to understand and implement.  Routes can be set up 
prior to the
	first data packet being sent.  It interoperates "almost perfectly" 
with the deployed
	ASM routers.  I encourage you all to make whatever noise is required 
to get
	the internet community to move in that direction.  Windows supports 
IGMPv3.
	That alone "should be" a large enough installed base to move 
applications
	in that direction.  (I don't suppose there are any application 
developers on this
	list <sigh>).

-- Bidir is simple to understand and implement.  It is presently 
limited to inside of
	an enterprise, but it isn't clear that a many-to-many application that 
spans
	the internet with thousands of participants is a realistic possibility 
right now.

-- Neither Bidir nor SSM require BGMP.  BGMP isn't going to go anywhere.

-- Interdomain ASM requires MSDP (or BGMP).  No one has figured out how 
to make
	MSDP work yet.  It barely works "good enough".  IMHO, it is one of the
	major stumbling blocks to multicast deployment.

So, I'd like to encourage you to "move on".  Your ASM pim is probably 
"good enough"
now.  If it isn't, well, you are implementing yesterday's technology.  
Its kind of like
deciding that you need a really good X.25 implementation in your router 
now.  (or
ATM ;-)

2cents