[rbridge] STP and ISIS

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



michsmit at cisco.com wrote:
>>-----Original Message-----
>>From: rbridge-bounces at postel.org 
>>[mailto:rbridge-bounces at postel.org] On Behalf Of Joe Touch
>>
>>Tom Sanders wrote:
>>
>>>Hi,
>>>
>>>Going through draft-perlman-rbridge-03.txt raised a doubt 
>>
>>in my mind.
>>
>>>Please let me know if my understanding of the matter is indeed
>>>correct:
>>>
>>>As per the draft, spanning tree algos concentrate a lot of 
>>
>>traffic on 
>>
>>>certain links as it marks some ports as blocked and only 
>>
>>the ones that 
>>
>>>are in the forwarding state can pass traffic. But as per my limited 
>>>knowledge, wouldnt STP mark only the redundant links as 
>>
>>blocked? If we 
>>
>>>dont mark them as blocked, then wouldnt that result in transient 
>>>loops, etc.
>>>
>>>Then the draft says that there are other issues as well because of 
>>>which the group has decided to use a link state routing 
>>
>>protocol; more 
>>
>>>specifically ISIS because of the advantages it offers against OSPF 
>>>(TLV encoded, runs over L2, etc).
>>>
>>>So, is the proposal to totally do away with STP et. al and run only 
>>>ISIS instead? The spanning tree is then computed with the topology 
>>>information provided by ISIS. Is this correct?
>>
>>Yes, AFAIK.
>>
>>
>>>If this is so, then we will once again mark some ports as blocked, 
>>>etc. How different is this from calculating the spanning 
>>
>>tree via the 
>>
>>>STP protocol?
>>
>>The difference is that the spanning tree will be used only 
>>for broadcast messages. There may also be more than one 
>>spanning tree, e.g., one per origin. In either case, the 
>>spanning tree is NOT used for forwarding unicast traffic; the 
>>ISIS-configured routing tables are.
> 
> 
> The statement above should be clarified as *known* unicasts do not
> follow the spanning tree.  Unicast traffic for unknown destinations will
> still follow the spanning tree.
> 
> Michael

Agreed

The only reason unknown unicasts would follow the tree is because they
are broadcast - though the reason they are broadcast is not because they
are sent on broadcast addresses, but rather flooded because of lack of
knowledge of attached port.

Joe
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFDMfMkE5f5cImnZrsRAuixAJ0dumoFAz6O6Kpa5l9PJyWy7g7g1gCfT7Sv
382WyL8nnm/NBSnXbVI6uvw=
=UCKJ
-----END PGP SIGNATURE-----