Technical issue to think about on SM-interest mailing list

[Radia Perlman - Boston Center for Networking <Radia.Perlman@East.Sun.COM>]

Thanks for creating this mailing list! You might want to invite some of your
students to join.

Anyway, one of the claims against SM
is that you don't want to have a single protocol
that works both intra-and interdomain because then you don't have the
flexibility of experimenting with different protocols in different domains.

I don't actually sympathize with that philosophy. I think it's far better
to just have a single scalable protocol, and I see the inter and intra
domain split as being very artificial, especially for multicast. I'm
not even convinced you need that for unicast.


An inter-intra split
isn't sufficiently flexible because there's no way to experiment with
multiple interdomain protocols. For instance, the Internet is probably
always going to be stuck with BGP. So I think the flexibility is illusory.

A complaint against SM is that the new paradigm of 8 byte group IDs isn't 
flexible
enough to interwork with other protocols. But can't you equally say
that the protocols with 4 byte group IDs aren't
flexible enough to work with an 8-byte ID protocol?

The idea of allowing multiple protocols to flourish
is (theoretically) to allow us to gain experience with new protocols.
I'd think we'd have enough experience with things like DVMRP to know
that we don't want to keep it around forever.

Anwyay, here's a 1/4-baked idea for a more flexible way of allowing multiple 
multicast
protocols to coexist in the Internet. Merely have the two protocols
operating in parallel and then have gateways interconnect the trees.
For instance, to connect DVMRP and SM, you might have two ways of joining
the group. DVMRP endnode and routers would join G1. SM endnodes would join
(C, G2). You'd need to have a bilingual node join both groups and pass
traffic from one to the other. It's easy to go from DVMRP to SM tree,
but it is somewhat problematic to go the other way, because of the RPF
check on source address...the bilingual node will inject the packet into
the DVMRP tree in an arbitrary place. So you'd have to tunnel it to
hide the original source address from the DVMRP forwarders, but then hopefully
the DVMRP receivers wouldn't be confused.

Anyway, if something like that could work, then you really would have
flexibility in terms of deploying new protocols, and even wildly new
paradigms, in a forward compatible way. you could have mixed groups of
SM-aware and non-SM aware nodes. (I'm sure people will complain though
that there's more things that have to be up, i.e., the bilingual node)

Anyway, just a thought.

Radia