Subject: [rbridge] Treating broadcast addresses

From: Vishwas at sinett.com (Vishwas Manral)
Date: Mon, 17 Oct 2005 04:27:28 -0700

Hi Rute,

Would this also mean Root-Election? What about convergence of this tree?

Thanks,

Vishwas

________________________________

From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Sofia, Rute
Sent: Monday, October 17, 2005 4:36 PM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

Vishwas,

based on the information exchanged by LSPs you can simply compute the ST
locally. The key here is the choice of the root. This can also be passed
along by IS-IS...

Regards,

Rute

	Hi,

	My question is more like, how would we build a spanning tree for
broadcast using IS-IS? 

	We need a globally coordinated tree like STP and not like the
way IS-IS computes it. Would we require, changes to the spanning tree
computation itself?

	Thanks,

	Vishwas

________________________________

	From: rbridge-bounces at postel.org
[mailto:rbridge-bounces at postel.org] On Behalf Of Vishwas Manral
	Sent: Monday, October 17, 2005 11:41 AM
	To: Developing a hybrid router/bridge.
	Subject: [rbridge] Treating broadcast addresses

	Hi,

	I had a doubt about treatment of broadcast addresses.

	Currently using STP we have one tree and ports are blocked/
forwarding, so packets cannot loop irrespective of destination
addresses. In IS-IS protocol, we use ports based on destination address
and no ports are blocked or unblocked. But if the destination address is
FF-FF-FF-FF-FF-FF we could end in a forwarding loop. How would we get
over it?

	Would we still allow broadcast destination address packets to be
forwarded? It is like preventing flooding loops in a case where we have
a global broadcast IP address, which is forwarded to all attached
routers. Am I missing the point all together?

	Thanks,

	Vishwas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.postel.org/pipermail/rbridge/attachments/20051017/7782776b/attachment-0001.html

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Mon, 17 Oct 2005 08:27:46 -0400

You do not even need a ?root? really! Each RBridge has the *global*
topology. They can simply each run Kruskal's algorithm and compute the (nee
*a*) minimum weight spanning tree (which is probably the right thing to do
anyway for broadcast purposes).

________________________________________
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Vishwas Manral
Sent: Monday, October 17, 2005 7:27 AM
To: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Treating broadcast addresses

Hi Rute,

Thanks,
Vishwas
________________________________________

Vishwas,
?
?
Regards,
Rute
?
Hi,

My question is more like, how would we build a spanning tree for broadcast
using IS-IS? 

We need a globally coordinated tree like STP and not like the way IS-IS
computes it. Would we require, changes to the spanning tree computation
itself?

Thanks,
Vishwas
________________________________________
Behalf Of Vishwas Manral

Hi,

Currently using STP we have one tree and ports are blocked/ forwarding, so
packets cannot loop irrespective of destination addresses. In IS-IS
protocol, we use ports based on destination address and no ports are blocked
or unblocked. But if the destination address is FF-FF-FF-FF-FF-FF we could
end in a forwarding loop. How would we get over it?

Would we still allow broadcast destination address packets to be forwarded?
It is like preventing flooding loops in a case where we have a global
broadcast IP address, which is forwarded to all attached routers. Am I
missing the point all together?

Thanks,
Vishwas

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Mon, 17 Oct 2005 13:59:45 -0700

And actually, people seemed to want to compute a per-ingress RBridge 
spanning tree.
The ingress RBridge will be in the shim header. So there is no problem 
with the root
of the tree changing, since they are not calculating a single tree.

The reasons for computing different trees (using the link state 
database) for each ingress RBridge are,
if I recall:

a) more optimized VLAN broadcast domain (if only a few links are in VLAN 
A, might as well
have shortest paths between those links, rather than a single spanning 
tree, which might cause a very
long path between two VLAN A links
b) more optimized IP multicast paths, when there are not receivers on 
many links (if there are
receivers on most of the links, having a per-ingress tree isn't that useful)
c) avoiding getting packets out of order when S starts talking to D, and 
ingress RBridge R1 does
not yet know the location of D. Using a per-ingress RBridge tree, the 
packets will take
the same path whether R1 knows where D is or not.

Radia

Saikat Ray wrote:

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