[rbridge] WG last call on draft-trill-rbridge-protocol-10.txt

[Ayan Banerjee]

Radia,

Some comments inline.

Thanks,
Ayan


On 2/16/09 9:22 PM, "Radia Perlman" <Radia.Perlman at sun.com> wrote:

> Ayan -- I"ll answer two of the things you mentioned.
> 
> Ayan Banerjee wrote:
>> 
>> Clarification for EASDI:
>> If my understanding of the draft is accurate, there are possibly 4K
>> vlan-ESADIs and on each node and we are "only" running the CSNP
>> functionality (of traditional IS-IS). The "hello" functionality is not run
>> on them. Consider a router that is interested in all "vlans"; such a router
>> will have to support *all* VLAN-ESADIs. I believe that this is a significant
>> load on the router. I believe that we should have an optional single-ESADI
>> instance as well; this will allow for control-plane learning of unicast MAC
>> addresses in a more scalable fashion. I am fine with having the optional 4K
>> instances also co-exist; but my preference is to have a single instance for
>> unicast MAC distribution.
>>   
> I think that combining the ESADIs into one would be a complication, and
> it involves more overhead
> since RBridges would have to keep information for VLANs they are not
> interested in. So I think
> that in most cases, having the separate ESADIs would work best. An
> RBridge is allowed to ignore
> all ESADIs and only learn from data traffic, and it could choose to
> listen to ESADIs on some
> subset of VLANs, and learn from data traffic on the others.

I do not disagree with the fact that a single EASDI will imply that Rbridges
that are not interested in some VLANs will have additional information.
However, for the Rbridges that have multiple VLANS configured on them and
need to run multiple instances will find this onerous. I believe you are
suggesting in that case data-path learning is the way to go (since control
plane learning is optional)? I was proposing that why not in addition have a
single instance ESADI (since it is optional anyways) to account for that
scenario. 

>> 
>> 
>> Parallel links between rbridges:
>> We need information in the draft that states that we break ties using (a)
>> extended circuit id on P2P links (makes 3-way handshake mandatory) and (b)
>> in a LAN, use lan circuit id.
>> 
>>   
> I think that if R1 and R2 have two pt-to-pt links between them, they
> should not be reporting both of
> them in their LSP.  There's already a tie-breaker for pseudonodes,
> right? Maybe I don't understand this issue.

The issue is when there are parallel links between a pair of nodes, you do
want the tree to be bi-directional on the same link. As a result, we would
need extended circuit id to break the tie. This mandates 3-way handshake on
P2P links.

> 
> Radia
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge