Subject: [rbridge] seeking input on abstractfor problemand applicabilitystatement

From: petera at nortel.com (Peter Ashwood-Smith)
Date: Fri, 14 Oct 2005 14:00:16 -0400

> My understanding is that PARTICIPATE is valid, if not required.
TRANSPARENT seems like it turns the bridge into a hub. And BLOCK would
break things.

  PARTICIPATE is definitely valid, but I disagree it is always required.
Its definitely useful though. It is only always required if both of
TRANSPARENT and BLOCK do not work.
 
  Yup, TRANSPARENT turns the rbridge network into a hub therefore it is
also valid with different trade-offs. Therefore PARTICIPATE is not
always required it is simply valid.

  BLOCK will break things? How. I think I've convinced myself this is
not possible in the steady state (because you have nodally disjoint
trees joined by a single link therefore a loop is not possible). The
worst it can do is change the routes because you get two STP trees each
with different root bridges ... which is not always ideal and why I
think you need TRANSPARENT AND BLOCK options at different phases of a
migration ... and possibly even Ships in the Night mode too.

  Peter Ashwood-Smith

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 13:50:12 -0700

> always required it is simply valid.

The only reason I could imagine a difference in requirement is that a
hub broadcasts everything, so 'TRANSPARENT' is consistent with how it
handles other frames.

I'm not sure whether the 802 specs allow for a non-hub device to not
participate in the spanning tree alg. Anyone else know?

(i.e., this might be a spec equivalance issue)

> trees joined by a single link therefore a loop is not possible).

How do I know they're disjoint trees, and what happens if (when) they
get interconnected?

If a spanning tree is attached to the rbridge in more than one place,
what happens with broadcasts? Won't they create a loop?

> The

SITN assumes some level of manual configuration - you have to know which
ship you're on ;-)

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/1400d85a/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 14 Oct 2005 23:36:00 +0200

I am not sure I interpreted the terms right. My understanding is that 
rbridges must participate  in the spanning tree. This is required to 
avoid loops  if two links of same network get attached to same rbridge. 
But rbridges must act as hosts, should not
forward received BPDUs to other ports of rbridge, as it is much more  
efficient and faster to converge, to have many small spanning trees than 
a big one.
Trying to emulate MSTP and combine STP with rbridges (a la CIST) is a 
path to complexity, opposite to selfconfiguration.
See below my comment on loops with broadcast frames.

>what happens with broadcasts? Won't they create a loop?
If there are two attachments to the same spanning tree to the same 
rbridge one of them acts as designated port and the other will be 
blocked by the spanning tree protocol. Participation in STP is needed 
for that.
I see the potential problem you mention with the attachment of spanning 
tree to /different/ rbridges with broadcast  frames. An rbridge receives 
the broadcast frame from the spanning tree, encapsulates it with the 
all_rbridges_multicast address and forwards to all rbridges. The frame 
is received by an rbridge of the same spanning tree, decapsulated and 
retransmitted to same spanning tree. Do I miss something?
Guillermo

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

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Fri, 14 Oct 2005 17:42:48 -0400

[Saikat] Only one of the RBridges would be *designated* to encapsulate the
packets from and decapsulate the packets to that spanning tree.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 15 Oct 2005 00:01:31 +0200

Guillermo Ib??ez wrote:
 
OK. So the designated Rbridge should act as root bridge of that spanning 
tree, for a shortest path to all bridges of spanning trees.

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 15:30:15 -0700

Guillermo Ib??ez wrote:
> But rbridges must act as hosts,

I have always disagreed with that assertion.

To the outside of the network:

I thought they would always act as if a single bridge (meaning
PARTICIPATE); I understand now how they might act as if a single
hub/link (TRANSPARENT).

To bridges they send encapsulated packets over, the ingress rbridges
look like hosts, but that's only to transit the L2.

> should not

I agree with that, except that this argues that existing bridges should
act in the same way. But they don't. I'm not sure they can.

> path to complexity, opposite to selfconfiguration.

Manual configuration is the opposite of selfconfiguration.
Selfconfiguration does not prohibit complexity, provided the complexity
can be selfconfigured - which I think it can.

> See below my comment on loops with broadcast frames.
...
> blocked by the spanning tree protocol.

The only reason it'd be blocked is if the spanning tree protocol knew
both rbridges were part of the same spanning tree. I thought that's what
the BPDUs would indicate.

> Participation in STP is needed 
> for that.

That's what I thought - but that requires PARTICIPATE, right?

> tree to /different/ rbridges

In the same campus? Why does that matter?

> with broadcast  frames. An rbridge receives 
> all_rbridges_multicast address and forwards to all rbridges.

The same would happen to all ports on a single rbridge, though.

> The frame 

That's what I think happens too.

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/8c052f49/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 15:33:16 -0700

> packets from and decapsulate the packets to that spanning tree.

Designated works for decapsulation, since the rbridge can control that.

How does the rbridge campus control which ingress is used if the
spanning tree touches it multiple times?

Joe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/acd0aaa1/signature.bin

---

From: touch at ISI.EDU (Joe Touch)
Date: Fri, 14 Oct 2005 15:34:47 -0700

> tree, for a shortest path to all bridges of spanning trees.

To do that, it would need to emit BPDUs to all edge trees to announce it
was the root, wouldn't it? Only then could it KNOW that the ingresses it
expects from each spanning tree would be the ones used (e.g., for those
attached multiple times).

(which would be back to PARTICIPATE)

Joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : http://www.postel.org/pipermail/rbridge/attachments/20051014/478906fb/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 15 Oct 2005 01:02:14 +0200

Guillermo Ib??ez wrote:

>act in the same way. But they don't. I'm not sure they can.
I do not see the point. Existing bridges should forward their spanning 
tree BPDUs. Tree extends till a link terminates in an Rbridge.

>can be selfconfigured - which I think it can.
I agree, but I does not look easy to obtain selconfiguration. Linking 
spanning trees with the rbridges network creates dependencies in 
transitions in case of reconfigurations.  Linking spanning trees 802.1D 
with the rbridge protocol increases the risks of interference between 
protocols.

>That's what I think happens too.
There is no problem as there is only one Designated Rbridge in the 
bridges spanning tree, the only that forward frames to/from that tree 
into the rbridges region. IMMO, the Designated Rbridge should act as 
Root bridge of the bridges spanning tree, so the path is optimum to all 
bridges of that tree.

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Sat, 15 Oct 2005 01:34:35 +0200

>(which would be back to PARTICIPATE)
Sorry, I did not follow the whole discussion. My understanding is that 
rbridges can participate in the spanning tree they are attached to but 
do not forward BPDUs. Each port emits BPDUs based solely on its port 
information, opposite to the standard  operation ,  where the bridge 
builds the BPDUs to be transmitted  based on information collected from 
all bridge ports and selecting the best BPDU, thus conveyed the distance 
to root bridge. I would call this mode PARTICIPATE PER PORT.
Rbridge ports should announce themselves as designated ports of  Rbridge 
(root). The Rbridge ports will be in role Designated if the win the 
competition in the link or in Back-Up or Alternate role (that means 
blocked) if they lost the competition of best BPDU heard in the local 
link.  They would never be in  Root port role.
Guillermo