SSM vs MSDP (was: IP Multicasting)

Wed Jan 3 18:48:00 UTC 2001

-----BEGIN PGP SIGNED MESSAGE-----

At 10:40 AM 1/3/2001 -0500, Marshall Eubanks wrote:
>1.) Freedom from MSDP. This is a mixed thing. Why is inter-domain 
>multicast connectivity so flaky ?
>The conventional wisdom is that MSDP information is being lost. We shall 
>see, but at least SSM gets around it.
>Loosing MSDP means you lose knowledge of sources potentially available, 
>which is not really a good thing.

Really?  I hadn't heard that conventional wisdom.  I obviously need to get 
out more (he says as he corresponds with his travel secretary about 
attending his first NANOG, #21.)

My experience with deploying Access Grid has seen apparent MSDP 
lossage.  But it almost always turns out not to be a bug in the MSDP 
stuff.  Instead, most often, it turns out to be a bug in all but recent 
[ >= 12.0(10) ] Cisco PIM-SM implementations.  And the bug isn't in the 
core router code or even the Rendezvous Point code--it's in the code that 
runs on the Designated Router for a given edge subnet.  In a nutshell, 
occasionally the Designated Router for a subnet will stop sending PIM 
Register packets towards the Rendezvous Point.  Thus, the Rendezvous Point 
doesn't have any PIM Registers to convert into MSDP SAs.  This turns up on 
the Rendezvous Point (MSDP speaker) as a lack of an A flag, and on the 
Designated Router as the lack of an F flag.  See Cisco Bug ID CSCdp68820 
for all the details.

Unfortunately, this only breaks MSDP--the existing PIM-SM state in the 
internetwork stays up as long as traffic flows.  Thus, some remote sites 
don't get the traffic while other sites do.  And new receiving sites don't 
get the traffic from the site with the broken router.

And the fix is to have the sending site upgrade to IOS 12.0(10) or later on 
their router directly connected to the source.  And while this sounds like 
a reasonable and easy thing to do, I'm working with at least two major 
universities that are still running 11.2(22) or thereabouts.  We've had to 
set up GRE tunnels to bypass those routers.  (oop, ack)

>IMHO, the WORST thing about SSM is that, in their enthusiasm, people 
>involved have tended to denigrate
>ISM (Internet Standard Multicast), even to the point of saying at IETF 
>meetings that ISM will die. ISM will not die. I would argue that
>anyone who makes the effort to deploy SSM will want to deploy ISM.

Yes, I think your and my humble opinions mesh perfectly.

>I use your beacon system, and think it is the most useful such tool out 
>there, and have urged
>everyone interested to bring up a beacon (we're there as 
>hendrix.multicasttech.com).
>
>I think that there will be a need for BOTH ISM and SSM beacon monitoring.

Thank you for your kind words about the beacon.  We have also found it very 
useful.  When we start to bring up an Access Grid site the first thing we 
tell people to do is to start a beacon, even before they order the hardware.

And yes I agree that we need both ISM and SSM monitoring of this 
form.  Because IP multicast (ISM and SSM) requires per-flow state in lots 
of routers along the tree from sender to receivers, my experience points to 
a need for a long-term monitoring system.  Long term monitoring of a test 
signal in a real-life environment is (in my opinion) one of the best ways 
to cover all the weird corner cases that crop up over time.
===
Bill Nickless    http://www.mcs.anl.gov/people/nickless      +1 630 252 7390
PGP:0E 0F 16 80 C5 B1 69 52 E1 44 1A A5 0E 1B 74 F7     nickless at mcs.anl.gov

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQCVAwUBOlNz4Kwgm7ipJDXBAQGTSwP+I2DFYD4ku34s/VBznagXh4/dVJX9repi
P8NVcUUzSnLe3fHdWD7jC9Ng8dDTDsbsY4X47LnyMKsntEoNU5JKf+I9OIqVq5Er
C9+pfC8vQf6L/mz7gjlZlnp/qE+BAkJd8RRmnxt3ah6h+RfLdCWMMt+r2H0kI+0u
61cpP0O/XQ4=
=ERYi
-----END PGP SIGNATURE-----