Subject: Mrouted on Windows NT

From: Dave Rubin <[email-masked]>
Date: Mon, 14 Oct 1996 09:40:26 -0400

Is there a multicast router (i.e., mrouted) available for the Windows NT platform?

--
Dave Rubin
Netcast Communications Corp.
[email-masked]

---

From: "David M. Meyer 541/346-1747" <[email-masked]>
Date: Tue, 15 Oct 1996 09:17:23 -0700 (PDT)

Bill,

>> At several IDMR meetings and MBONE BOF's, I've heard people say
>> that one of the reasons that they have so much trouble with
>> multicast deployment on their native routers is because it's
>> so hard to configure them; mrouted was cited as being almost
>> "too easy" to configure.

	I was one of these people who said that you folks did an
	execellent job with mrouted. While this is certainly
	true, I would just note the "too easy" part of this comes
	with a few costs, including the following:  

	(i).	Scalability

		First, it is not really practical to build a
		multicast capable campus/enterprise out of
		mrouters. The "too easy" part would certainly
		disappear if I had to manage 400+ mrouters to
		cover the multicast capable subnets I have (and I
		know I have a small enterprise...). So, in the
		case of many campus/enterprise environments, I've
		heard the opposite: Something like "its great to
		be able to turn on multicast routing on a router
		interface without having to find a mrouter, build
		a tunnel...". 

		The real issue here is that in many cases, is
		easier to integrate multicast routing into your
		enterprise if it's part of your native packet
		forwarding infrastructure. This seems to be
		particularly true for those organizations that
		don't have a lot of unix experience, or that
		don't have technical staff. That is, easier for
		some people to type something like "ip pim
		dense-mode" (pick your favorite vendor syntax)
		than to configure a some UN*X box to be a
		mrouter.   

	(ii).	Expressiveness

		Filtering, static mroutes, ....As usual, ease
		of use comes with reduction in expressive
		power (I suppose I could do anything computable
		on a Turing machine (or boolean circuit), but I
		like Emacs better as an editor).  So "too easy"
		comes with the caveat of "less powerful".

	Finally, my experience is that at least part of the "too
	hard" problem with deployment of native multicast is more
	about understanding what the issues in multicast routing
	are (again, what was RPF?), rather than configuration
	complexity. Many of these (primarily educational) issues
	didn't arise in the past, because we enforced congruence
	of our unicast and multicast topologies. Since this
	topology congruence doesn't necessarily hold anymore, we
	need mechanisms (and understanding) to deal with it. 

	Dave