Re: Use of SAP in a PIM SSM Network

[Hugh LaMaster <lamaster@nren.nasa.gov>]

On Sat, 25 Nov 2000, Marshall Eubanks wrote:

> SSM in intended for (or, is at least, ideal for) BROADCASTING. 
> In the real world, broadcasters
> stay up for years at a time. They don't like down time, even for seconds.
> They will NEVER want to renumber their class D addresses - these will
> get embedded in too many places (including .pls type files at the receivers)
> to make any such transition smooth.
> If there is a MAC layer collision, for any reason, they will want a fast
> means of resolving it. Now, I am sorry,
> but this sounds awful much like a static address to me.
> 
> SSM is very attractive for broadcasters. Please do not hinder it by insisting
> on some theoretical purity that does not fit their business model.

Two points:

1) This isn't a question of "theoretical purity".  Lots of IPv4
multicast addresses are mapped to each Ethernet multicast
address assigned for IPv4 multicast.  That means that layer-2
filtering must be imperfect.  On this mailing list, or, one of
its cousins, there was discussion/complaint a few months ago
about traffic to some multicast address like 225.0.0.1 getting
forwarded to all hosts-- well, it isn't a bug, it is a feature!
SSM effectively eliminates the shortage of IPv4 multicast addresses, 
but, it doesn't address the shortage of MAC addresses, which is 
really a function of the way IEEE looked at multicast MAC addresses 
way back when.

MAC layer collisions are unavoidable by design.  But, they can 
be reduced in number through intelligent design.

2) I don't agree that static IPv4 multicast application addresses 
should *ever* be hardcoded.  Just the opposite: application 
addresses should never, ever be hardcoded.  The possibility
should always exist for moving the address.  Certainly, some 
broadcasters using SSM may not want to change the addresses 
every day, but, if someone mistakenly chooses an address with 
a serious collision problem of some kind, they should be prepared 
to change it.  Applications with hardcoded addresses can create
serious problems downstream.  

Disagreements and refutations welcome.


--
["I hate to say I told you so, but, I told you so."

 Hugh LaMaster, M/S 233-21,    Email: lamaster@nas.nasa.gov
 NASA Ames Research Center     Or:    lamaster@nren.nasa.gov
 Moffett Field, CA 94035-1000  Or:    lamaster@kinkajou.arc.nasa.gov
 Phone: 650/604-1056           Disc:  Unofficial, personal *opinion*.