Subject: draft-ietf-bmwg-mcastm-01.txt

From: Randy Bush <[email-masked]>
Date: Tue, 15 Jun 1999 09:42:00 -0700 (PDT)

i took the liberty of begging a multicast geek friend to review the draft.

randy

From: David Meyer <[email-masked]>
To: [email-masked]
cc: [email-masked]
Subject: draft-ietf-bmwg-mcastm-01.txt
Date: Tue, 15 Jun 1999 08:38:00 -0700 (PDT)

	Randy,

	A few comments on this document:

	(i).	The document (and in particular the "Test set up"
		described in section 3) ignores the 1:many v. few:many
		v. many:many classification of multicast traffic (and
		hence multicast performance). This is the cause of
		systemic problems with the methodology described. 

	(ii).	Section 3.1.1

		No support for IGMP v3? There's a draft, should
		be enough.

	(iii).	Section 3.1.2

		224.0.1.27-224.0.1.255

		These are LMSC-CALREN-1.MCAST.NET ...
		and are already assigned. The other ranges aren't
		yet assigned by the IANA

		Also, it would be reasonable for the DUT not
		to take a hit processing addresses in the admin
		scope, so those should be included for testing.

	(iv).	Section 4 (Forwarding and Throughput)

		The methodology described here seems to ignore that
		performance is f(S,G,Fanout). S and G seem to be
		addressed, and "Ports" seem to be present to 
		represent fanout (replication). However, there
		does not seem to be a method for determining the
		interaction between S, G, Ports (again, fanout).

	(v).	Section 4.4.3 (Re-encapsulation Throughput)

		Who cares about this (this is supposed to get
		at DVMRP tunnel to GRE tunnel, etc).

	(vi).	Section 7.1 (Multicast Group Capacity)

		Again, this is f(S,G,Ports).

		Also, in the "Results" section, the language
		"groups passed" is used. It is not well defined
		(not defined at all).

	Dave