[rbridge] LIDs

[Caitlin Bestler]

Erik Nordmark wrote:
> Radia Perlman wrote:
> 
>> We haven't discussed the LID fields. Perhaps that should be a
>> different thread. Since that doesn't affect forwarding, and is only a
>> convenience to the egress RBridge, that doesn't seem too compelling.
>> The ingress RBridge has to do the lookup per endnode, so it's only at
>> most twice as much computation for a Designated RBridge to have to do
>> the lookup both when a packet leaves its link and when it enters.
> 
> If we are trying to squeeze bits and see a need for a LID
> capability, it might make sense to allow different egress
> rbridges have different number of LID bits - they only need
> to number their ports so in some cases few bits would be sufficient.
> 
> Assuming we have a 19 bit space for RBridge alias plus LID,
> then an rbridge with 16 ports would ask for an alias that is 19-4=15
> bits. 
> 
> The downside of such an approach is that the alias setup
> would need to be able to handle variable length aliases, and
> the transit rbridges would either need variable length
> matching on the RBridge alias, or expand out to all the
> matching 19 bit patterns and have the hardware do full 19 bit
> matches. For instance, the above 15 bit alias would expand to
> 16 different matches on 19 bits.
> 
>     Erik

Bitmask aliasing an RBridge ID has the same potential uses as
LID aliasing for InfiniBand, and the same complexities.

My generate comment on the LID is that it is only worth considering
if it can be multiplexed with the RBridge ID. Otherwise you are
replacing an egress RBridge table [local mac-->local port] by
having having more data in the ingress RBridge table
[remote mac-->remote rbridge + LID]. I'm not certain
that it really reduces the amount of memory, and given
the likely size of the [local mac-->local port] table
I don't think it improves latency.