The IP over ATM Mailing List Archive by date

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

>>I must have mis-understood something in Grenville's reply.

Or I was being imprecise - it was late when I wrote it, and it
contained highly summarized versions of my mental model :)

I plan on writing up a clearer discussion/description of my
thoughts in the next month, as part of my interest in exploring
the impact of multi-LIS 'domains' on IP Inter-domain multicast
routing (aka making a cluster span multiple LISs).

A comment on part of your email...

	[..]
>>There were two other ideas in the response that I could not quite follow.
>>A) Two formats.  The notion that one could use a different source-id
>>    format depending on whether or not there were remote receivers of
>>    the multicast.  This seems to be a non-starter.  The whole point
>>    of an MCS is that the senders DON'T KNOW who the receivers are.

I think I was trying to suggest that if, as our needs evolve and
a revision of the protocol is generated, we had demonstrated the
need for a different source ID format, we could use a new LLC/SNAP
code-point to identify packets so encapsulated. I'll try and be
clearer on this point in my write-up. (I'm not sure I understand
your reference to MCSs here.)

>>B) Some sort of larger space ID coordination.  I have trouble figuring
>>    out how one would have a useful space for this.  Every multicast
>>    group would have different attributes which determined the scope
>>    of appropriate cut-throughs.

My comments here were based on a mental model where we could
have groups of co-ordinating MARS clusters, within which
unrestrained cut-through was allowed (sort of like an AS being
an internally co-ordinated set of unicast subnets), while
traffic between co-ordinated cluster groups is required to
aggregate at a border mrouter. The co-ordination with these
cluster groups would be between MARSs - to ensure no two sources
were given the same CMI. Provided your needs amounted to
less than 65k sources in each aggregated cluster group you
can survive with the present 16 bit CMI.

Anyway, I'll try and put together something more coherent before
long.

cheers,
gja
---
Grenville Armitage, Research Scientist,      MRE 2P-255, 445 South Street
Internetworking Research Group, Bellcore.      Morristown, NJ, 07960, USA
(email) gja@thumper.bellcore.com  (voice) +1 201 829 2635 {.. 2504 (fax)}
        (www) http://gump.bellcore.com:8000/~gja/home.html