[rbridge] per-VLAN instances of IS-IS

[Joe Touch]

Anoop Ghanwani wrote:
>  
> Joe,
> 
>> And, as Eric notes later, a common path between the two is 
>> needed at L2.
> 
> Sorry, this thread is starting to get long and 
> I'm losing context.  A common path between what two?
> Control and data?  As I pointed out the control
> packets (e.g. if MMRP were being used) do not
> even make it into the LAN between the rbridges.
> The rbridges would have to initiate such messages
> and I don't know what would cause them to intiate
> such messages.

I was presuming a common path for multicast at L3 and unicast at L3,
e.g., IPv6 neighbor discovery and unicast replies.

>> As to the pruning that Anoop later notes, I don't consider pruning an
>> issue for an L2 system. Although I appreciate pruning as an
>> optimization, I don't consider it a design requirement. If it were, we
>> would be talking about scalability beyond existing bridge 
>> capabilities,
>> which has been off the table from the start.
> 
> Well, existing bridges do actually do
> pruning today - and they have for years.
> rBridges without multicast pruning would be
> step (or perhaps two) back.

There are bridges built into a variety of devices that are a lot simpler
than the typical COTS stand-alone device. Further, the extent to which
rbridges even benefit from pruning is different than regular bridges,
because there can be multiple paths for different traffic in rbridges.
I.e., this is still just an optimization, and one that may be less
important in this environment.

Joe

-- 
----------------------------------------
Joe Touch
Sr. Network Engineer, USAF TSAT Space Segment

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20070619/86dd80d2/signature.bin