The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

Curtis,

>>Grenville suggested that there were two dimensions of "large" when
>>applied to discussion of "large LIS".  One was the number of hosts.
>>The other was the geographic size, which then has implications on the
>>number of switches in the LIS.  
>>
>>I responded that 1) I was referring to "large" in terms of the number
>>of hosts in discussion of protocol scaling and 2) that large in terms
>>of the number of switches and delay between them is a traffic
>>management issue which I don't think we want to rehash

I'm more than happy that your discussion with Hiroshi has reached
its conclusion. However, it was a tangent to why I originally posted
a clarification to the term 'large LIS'.

This had its origins in the much more relevant discussion over
whether multicast servers had a place in a 'well designed LIS'.
You were making assertions that LISs ought to be (numerically) 
small, and extrapolating that the consequential resource costs
of VC meshes were not really a problem.

Your response (2) is why raised the issue, and why killing the
thread may not yet be appropriate.

Why? Because you missed the point. It is not just a dichotomy
between protocol scaling and traffic management. Geographically
dispersed LISs are an issue for public carriers (or anyone
who uses them) because there are points (maybe inter-city
trunks) where VCs are scarce. Ergo a 'large LIS' may actually
have moderate numbers of attached hosts, yet still find value
in using multicast servers. (The additional issue of propagating
group changes within far-flung meshes also pops up here.)

	[..]
>>ps- now can we end this thread...

I'm not sure I wanted any numerical value placed on the term
'large LIS'. Provided we acknowledge the existence of different
types of 'large LIS' in future architecture discussions then
I'm happy.

cheers,
gja