All things related to multicast

[John Zwiebel <>]

On Monday, May 13, 2002, at 04:37 PM, Bill Nickless wrote:

> On Mon, 13 May 2002, John Zwiebel wrote:
>
> > Let me take a moment to bug everyone with some -obvious- points.
> >
> > 1) MSDP is and always has been a kludge.
>
> No, John,
>
> The service model and wire protocol in RFC-1112 are the kludges.

I totally agree that 1112 is a kludge.  The idea of requiring some sort
of RTS/CTS handshake has been batted around all nearly every IETF
I've ever attended.   And the idea of multiplexing more than one
IP address on a MAC address solely because the advisor was too
cheap (actually couldn't justify in his budget) to spring for a one
to one mapping between them, should also be recognized as a kludge.

That in no way invalidates my point that MSDP is a kludge, and your
suggestion that Dave change his RFC to exclude encapsulated data
is recognition of at least that portion of the protocol as a kludge.

I can readily accept removing encapsulating data.  I've been in
favor of that for a long, long, very long time.

Believe it or not, I accept and agree with nearly everything you say 
here.


> RFC-1112 is built around the idea that a host can simply put an IPv4 
> multicast group-addressed packet on a wire and it will get to all the 
> interested receivers with the same reliability as unicast UDP.  That's 
> true in a single collision domain.  But collision domains don't scale.
>
> Regarding internetwork routing, RFC-1112 takes the easy way out.  It 
> simply says that "multicast router(s) attached to the local network 
> take responsibility for forwarding...towards all other networks that 
> have members of the destination group".  It says nothing about how the 
> "multicast router(s) attached to the local network" know where the 
> interested group members are.  That's left as an exercise to the reader.
>
> SSM comes close to giving the "multicast router(s)" the information 
> they need to fulfill their RFC-1112 duties.  How?  In SSM, a receiver 
> must give the network the knowledge of a source that will (may 
> someday?) put a packet on its local wire.  Given that knowledge, the 
> internetwork has at least a small prayer to create the forwarding state 
> necessary for the future packets to be delivered from source to 
> destination.
>
> Your complaint with MSDP is really a complaint about the ASM (RFC-1112) 
> service model.  That is, the network can't know about the existence of 
> active sources until the source goes active in the first place.  
> Spreading that knowledge around is the purpose of MSDP.
>
> Also:
>
> IGMP is a broken kludge, again designed for networks that are composed 
> of single 10Base5 thick Etherhoses.  That is: a single collision 
> domain, where the underlying wire is insensitive to the actual MAC 
> destination addresses of a packet.
>
> But what happens when the MAC address is used to make forwarding 
> decisions, like in a bridged Ethernet?  That RFC-1112 assumption of 
> media insensitivity to destination MAC addresses is no longer valid.
>
> Somehow we've bludgeoned the Ethernet (802.x) switch builders into 
> looking far deeper into Ethernet multicast frames than they ever should 
> have had to; that's how IGMPv2 got deployed.  Now we're expecting them 
> to redo all that work, look even FURTHER into the Ethernet multicast 
> frames, to deploy IGMPv3?  For what payback?  Especially from their 
> perspective?  Oh, and by the way, SSM/IMGPv3 doesn't solve the exchange 
> point problem (PIM Asserts) either.  Anyone want to bet how long it 
> will take for 802.x vendors to handle IPv6 multicast in their devices?
>
> I've thought about writing an IGMPv4 draft.  IGMPv4 speakers would 
> negotiate media-specific multicast addresses for (*,G) or (S,G) or even 
> (S,G,upstream) sources.  The interested listeners would then do 
> media-specific multicast joins (like 802.1p GARP/GMRP or ATM 
> point-to-multipoint SVCs or point-to-multipoint MPLS TEs or Optical 
> Control Plane Splitters or whatever.)  This would separate the Internet 
> Protocol Group management from the media-specific 
> inter-collision-domain forwarding.
>
> In the meantime, we have a set of protocols for ASM that are designed, 
> implemented, deployed, and operational for IPv4.  Those protocols are 
> IGMPv2, MSDP, PIM-SM, and M-BGP.  They're close enough that we can 
> write books about them, teach classes on how to use them, and put them 
> into production.  There's plenty of data that they're working fine 
> today on the Internet.
>
> MSDP is eminently completable.  I agree with Hans Kuhn about putting 
> SDP files on the "small research project" World Wide Web.  We should 
> quit being afraid of breaking SDR and therefore stop encapsulating data 
> in MSDP.  Separating the control plane and the data plane has been a 
> good design principle for a long time.  MSDP, used purely to DISCOVER 
> SOURCES, can and should be done right.
>
> ===
> 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