Subject: [rbridge] seeking input on abstract for problem and applicabi lity statement

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 14 Oct 2005 20:56:46 -0300

Joe,

	You said: The edges are individual spanning trees. The rbridge 
	can have more than one internal path between two edge trees, 
	but that's it, that's all the redundency that's provided. 
	Turning off ports on the outside edge of the rbridge has no 
	effect on the internal multipath potential.

	And then later, you also said: Yes [STP would be disabled by 
	default]. And not to forward ingress frames until internal 
	routing (IS-IS in this case) is established. At that point, 
	STP should be enabled at the 'edges', STP PARTICIPATEd, and 
	-then- ingress enabled.

	What's the problem?

"Internal" and "external" are not meaningful terms.  How would an
RBridge distinguish an "internal" bridge from an "external" bridge?
You suggest that this would occur as a result of recognizing that
another RBridge exists on the local bridged network.  That appears
to assume that the only way to keep RBridges from being part of the
same campus is to put a router between them.  That - in turn - has
some interesting implications with respect to colocation of router
and RBridge functionality.

The key reason why I don't think that the presence of other RBridge 
on a port makes it an "internal" port is that there is a distinction
between reaching other RBridges in certain extended topologies and
reaching them in other densely interconnected topologies.  But that
may simply be a terminology issue.

The same applies to "ingress" and "edge".

But there's a larger issue.  I am not at all convinced that it is
ever necessary to differentiate the behavior of "internal" verses
"external" interfaces.  Consequently, I think it is an unecessary
complication, especially given that - if it is indeed based on the
presence of another RBridge on the same link - it is something that
can change very quickly, causing an RBridge to change operational
modes.  There's no reason I can see for taking on the additional 
complexity.

	You also said: Rbridges have nothing to do with the convergence 
	of the spanning tree external to them, IMO. All they do is have 
	their INTERNAL routing converge faster than spanning tree would
	have - that's where the benefit comes from. I never thought it 
	had anything to do with an effect on the external trees.

	And then later said: That's an interesting question - [a longer 
	initial convergence time] may be the result of having an internal 
	routing protocol that isn't setup ahead of time. [That is], maybe
	rbridges DO take longer to *initially* converge the STP of an 
	existing net, but react faster *afterwards* to changes.

This is only true if RBridges do not participate in STP with the
bridges in a local bridged network. If they do participate, then
the STP will not converge until after the RBridges have determined
forwarding paths among themselves, which will not occur until any
bridges between RBridges have converged on their STP.

So, the bridges between RBridges do STP.  The links between RBridges
come up.  The RBridges "hello" each other, peer, exchange link state
and reachability information, and then announce a topology change to
at least all ports that they have not heard other RBridges on (though
this is not sufficient, let's assume for simplicity that it is).  Now
the bridges on the affected links re-start STP - only now the network
of bridges is very much larger, because it includes at least bridges
that hang off of the RBridge's peer's other interfaces.

How is it that this does not take longer than if the RBridges didn't
exist?  Also, there appears to be a misconception that STP takes a
long time in comparison with routing.  Given that STP must complete 
before routing can begin, this is a bit of a misleading concern, at
best.

Let's take a specific case: An "internal" bridge goes down, taking
one or more links between RBridges with it.  The RBridges lose a
forwarding path and make the corresponding LSDB updates. Further,
let's assume that this partitions the RBridge campus temporarily.

The link is redundant, so a neighbor will announce a topology change 
and STP will re-run to switch port forwarding states so that the 
redundant path is now available.  

The link returns and IS-IS reconverges.  Now the RBridges might be 
clever and recognize that the net change (no pun intended) is NIL - 
assuming that all of this happened fast enough that the RBridges
have not previously announced a topology change to "external" bridges.

In this case, nothing else happens.  

However, let's assume that the re-establishment of the "internal" 
link did not happen fast enough.  In that case, the "external" 
bridges will see two topology change notifications and STP will be 
run each time.  If the second topology change occurs before the STP 
completes for the first topology change, it will be as if the whole 
system is being restarted from scratch.

	You also said: [STP convergence is] just like adding a bridge 
	to an existing bridged system. The new bridge doesn't forward 
	frames until STP finishes, but the existing bridges can finish 
	just fine. The rbridge is the 'new' bridge. 

	All the other bridges are the existing bridge system. No chicken 
	and egg, AFAICT; the sequence is determined by rbridge's reliance 
	on bridges.

I think that in this case (and maybe in others) we're not talking
about the same kind of convergence problem. I am talking about the
time that initial convergence takes and you're (apparently) talking 
about the time it take to re-converge after a minor topology change.

Also, STP convergence - as explained above - is different if a 
bridge goes down.

I think - even so - that there's a flaw in your reasoning that is
based on a mistaken assumption that you specifically state below.

	Also, you said: Again, I'm back to 'what would a bridge do'. 
	Either this is a bridge (PARTICIPATE) or a link (e.g., hub, 
	which means TRANSPARENT). Those are the only two options that 
	have correlaries in existing L2.

That's simply not true.  Hosts exist at L2.  Routers exist at L2.
Neither of them do either of these.

	Finally, you also said: [RBridges] can't make redundent paths 
	in the non-rbridge portion of an L2 net. They can only do so 
	within the rbridge.

This is a flawed assumption.

Note that even bridges can carry L2 traffic for more than one VLAN.
It's a simple matter - if you're starting from scratch to implement
a bridge - to allow an RBridge (for instance) to use one port in a
local bridged network to forward frames associated with one set of
VLANs, and another port in the same local bridged network to forward
frames associate with another set of VLANs.

Also note that there is no possibility of looping traffic introduced
by this behavior.

Also note that the same would obviously apply if another RBridge
in the same RBridge campus had a port in the same local bridged
network.

Participation in the local STP would mean that the local bridges 
would determine that the RBridge campus had a redundant path.  As
a result, certain of the local bridges would put their ports in a
non-forwarding mode - making use of the redundant path impossible.

Clearly this can be applied to other mechanisms for differentiating
frame-streams than by VLAN-ID, but it should be sufficient to show
a single example of when participating in local STP is a bad idea.

Finally, note once again that all of this applies equally to both
"internal" and "external" ports.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Joe Touch
--> Sent: Friday, October 14, 2005 5:15 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] seeking input on abstract for problemand
--> applicabil itystatement
--> 
--> 
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
--> 

Earlier, you said:

Gray, Eric wrote:
> Joe,
> 
> 	I want to address specific comments/questions you 
> had below:
> 
> -> All of this sounds like stuff the rbridge already 
>    needs to do; there needs to be an internal spanning 
>    tree anyway.
> 
> We have not yet decided how many "spanning trees" there
> needs to be, and that is a part of the problem.  One of
> the goals of the original proposal - as I understand it
> - was to allow efficient use of redundant links that may 
> exist between RBridges.  
> 
> This is why the confusion keeps coming up with the use 
> of the term spanning tree.  Its NOT the right term in 
> the RBridge context, because the RBridges WILL NOT be
> turning ports off and WILL be forwarding distinguishable
> streams of frames on as many of the available links as 
> it makes sense to use, given the destinations and - for
> example - VLAN contexts that apply to each stream.

I'm not sure I agree. The edges are individual spanning trees. The
rbridge can have more than one internal path between two edge trees, but
that's it, that's all the redundency that's provided. Turning off ports
on the outside edge of the rbridge has no effect on the internal
multipath potential.

> Another goal - again as I understand it - is to reduce
> the time for convergence on spanning trees for those
> portions of the network that MUST use STP (the bridges).
> For that goal to be achieved, it is a good idea not to
> extend STP across the RBridges.

I definitely disagree with this. Rbridges have nothing to do with the
convergence of the spanning tree external to them, IMO. All they do is
have their INTERNAL routing converge faster than spanning tree would
have - that's where the benefit comes from. I never thought it had
anything to do with an effect on the external trees.

> Finally, there is a huge "chicken-and-egg" problem with
> any intention to have RBridges participate in STP.
> 
> The "spanning tree(s)" determined by RBridges are the
> result of shortest path analysis of reachability info
> provided by IS-IS.  If this is not the case, then there
> was never any reason to suggest using a shortest-path,
> Link State Routing Protocol in the first place.
> 
> However, before the RBridges can reliably determine
> link state and advertise reachability, any "internal"
> bridges MUST have already determined a spanning tree
> (using STP).  As I pointed out previously, and Radia
> stated as well, bridges typically do not forward during 
> STP, consequently some or all of the links between the
> RBridges will be DOWN as far as IS-IS is concerned.

That's just like adding a bridge to an existing bridged system. The new
bridge doesn't forward frames until STP finishes, but the existing
bridges can finish just fine. The rbridge is the 'new' bridge. All the
other bridges are the existing bridge system. No chicken and egg,
AFAICT; the sequence is determined by rbridge's reliance on bridges.

> Also, again as pointeed out previously, "internal" and 
> "external" are topologically meaningless terms as far 
> as RBridges are concerned - unless that information is
> explicitly configured.  Consequently, default RBridge
> behavior really MUST be to ignore STP on any port not
> explicitly configured to participate in STP.

Yes. And not to forward ingress frames until internal routing (IS-IS in
this case) is established. At that point, STP should be enabled at the
'edges', STP PARTICIPATEd, and -then- ingress enabled.

What's the problem?

> Also, because the link state between RBridges is not
> determined until after any internal STP required has
> been completed between bridges that may be involved 
> in those links, either the RBridges have to wait a
> pre-determined period of time (to blindly allow for 
> "internal" STP) or send topology change BPDUs on all 
> ports every time they discover new links. Either way 
> will result in potentially huge delays in overall STP 
> convergence time for the network.

Again, I'm back to 'what would a bridge do'. Either this is a bridge
(PARTICIPATE) or a link (e.g., hub, which means TRANSPARENT). Those are
the only two options that have correlaries in existing L2.

> -> I'd like someone to explain which of these are valid 
>    if we replace the rbridge campus with an existing 
>    bridge.
> 
> I am not sure that this concept of a "virtual bridge"
> is - or ever has been - a goal for RBridges.

It's not a goal; it's a definition, IMO.

> If you 
> want a "virtual bridge", one approach that already is
> out there is VPLS.  Consequently, why would we need
> to specify how to do it with RBridges?

VPLS, depending on where I look, are either pseudowires (virtual hubs)
or L2 over L3. Rbridge is L2 over L2 with routing.

> If it is not a goal, then the notion of replacing an
> RBridge with a single bridge is not something we need
> to consider.
> 
> -> 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.
> 
> Assuming that this _is_ a goal, there is no particular
> reason why someone would not replace a hub (even a 
> "virtual hub") with a bridge.  For reasons explained
> above, however, PARTICIPATE - while potentially valid
> - is extremely undesirable.

If you replace a hub with a bridge that refuses to PARTICIPATE, what's
the effect? Nothing. That assumes that hubs weren't in rings, which they
weren't supposed to be.

However, you CAN wire bridges in rings and they're supposed to do the
right thing. That's only because they PARTICIPATE, though.

> Transparent also is not good because the path through
> the RBridges will not exist (or not be complete) until 
> A) STP is completed between any "internal" bridges and 
> B) the RBridges have converged on a complete LSDB and 
> determine SPSTs (shortest path spanning trees).

I already answered this in a separate email; yes, both of these steps
need to happen in order, and they will.

> So, even with Transparent, the insertion of RBridges
> would result in increased STP convergence time, even
> if the network size has not changed.

That's an interesting question - that may be the result of having an
internal routing protocol that isn't setup ahead of time. I.e., maybe
rbridges DO take longer to *initially* converge the STP of an existing
net, but react faster *afterwards* to changes.

> In addition, TRANSPARENT would require configuration
> of the RBridges to recognize "external" interfaces -

The need to know which interfaces they can reach rbridges on, which can
(and should) be autoconfigured.

> since it is clearly not the case that, even in this 
> mode, you would want bridges inside an RBridge campus
> to participate with bridges outside that campus.  As
> implied previously, having all bridges - both inside
> and outside of an RBridge campus - participating in 
> forming a single spanning tree would prevent using
> redundant paths (and would very likely drop RBridge
> ports out of the topology as the corresponding bridge
> ports - at the other end of the physical link - are
> put in the non-forwarding state).

I also already answered this - rbridges can't make redundent paths in
the non-rbridge portion of an L2 net. They can only do so within the
rbridge.

Joe

---

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

> RBridge distinguish an "internal" bridge from an "external" bridge?

Internal and external traffic is easy to distinguish (internal has the
shim header). Bridges can be either or both, of course. It doesn't
matter, though - both can set their spanning trees before the rbridge is
configured.

> and RBridge functionality.

That was Radia's assertion. I had always thought an L2 could have more
than one rbridge campus, but that would imply that there was a way to
indicate which campus an rbridge was part of (e.g., via override).

> modes.  There's no reason I can see for taking on the additional 

I agree that interfaces aren't internal or external. Let's put it this way:

	rbridges ingress/egress functionality is disabled until the
	spanning trees of other bridges is completed (it basically has
	to be; otherwise, stuff falls on the floor).

	once the other spanning trees are set, the rbridge can
	enable ingress/egress (which is when it would anyway, since
	that's the point at which traffic would flow.

> before routing can begin, this is a bit of a misleading concern, at

This is a startup issue; I have already agreed that this would take
longer with rbridges in the loop, with the hope that later cahnges could
be propagated more quickly.

> system is being restarted from scratch.

I'm not sure I followed all of that, but yes, there are cases where
changes in the internal paths available to an rbridge due to
partitioning could affect edge STPs.

> about the time it take to re-converge after a minor topology change.

I had been talking about both cases (at least in later emails), and
already agreed they were different.

> Neither of them do either of these.

Yes. And - sorry to shout but this point apparently isn't being
appreciated - BOTH HAVE L2 SOURCE/SINK ADDRESSES.

Rbridges - at least as far as ingress/egress links are concerned - do
NOT. Their addresses are ONLY for rbridge-rbridge traffic.

So - this is equally important:

	to conventional nodes (hosts/routers are the same thing in L2)
	on the L2, the rbridge MUST act like a link/hub or switch

	to other rbridge nodes (and only to them), the ingress/egress
	look like conventional nodes (sources/sinks)

> frames associate with another set of VLANs.

Different ports for different VLANs aren't redundent paths, unless
you're going to move frames from one VLAN to another.

> non-forwarding mode - making use of the redundant path impossible.

Isn't that just an STP per VLAN?

> "internal" and "external" ports.

FWIW, nobody has answered the basic question:

	replace an rbridge in BLOCK mode with a bridge

	run whatever rbridges run internally within the bridge
	(i.e., emulate it)

	would THAT device be able to replace a bridge?
	would THAT device be able to partition the STPs of its leaves?
	
So far, the ONLY reason I can see that the rbridge *might* get away
doing anything different from a bridge is the requirement/assumption
that all rbridge devices in an L2 aggregate into a single campus.

If that IS the case, there *might* be a way it can do something other
than TRANSPARENT or PARTICIPATE, but it's not clear how different it
ends up being from PARTICIPATE (it seems like it still has to be roots
on each STP - how does it do that?)

If that IS NOT the case, someone needs to show how these behaviours
couldn't be used to augment a conventional bridge to result in
partitioned, faster-converging STPs.

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/3fa2acd0/signature.bin

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sun, 16 Oct 2005 16:11:53 -0700

It looks like this thread was discussed with two different subject 
lines, and it's also
gone on long enough it's time for someone to summarize it.

I strongly believe that things will be more stable if RBridges do NOT 
forward BPDUs...that
we decouple the protocols.

That TRILL is kind of like a layer between bridging and routing.

If RBridges do not forward BPDUs, then whether or not the TRILL link 
state protocol is
converged, it won't affect the little spanning tree inside a particular 
bridged segment.

That way, the little spanning trees will converge as quickly as possible 
(because it's small),
and cannot possibly be disrupted by RBridges wormholing BPDUs.

I do not understand the reasons why people want to forward BPDUs. I 
think the arguments (which
I may not be presenting fairly because I don't understand them) are:
a) you'll get a more optimal combined spanning tree on which 
unknown/broadcast frames will
be sent if it is one global spanning tree, rather than little 
independent spanning trees hooked together
by the independently computed spanning tree calculated by IS-IS.
b) forwarding BPDUs, and having a global spanning tree, will prevent loops.

I strongly disagree with both those arguments. For a) What do people 
think is more optimal about a tree
computed that way vs having independent trees inside each bridged 
island? And besides, there isn't
a single spanning tree...it's a spanning tree per ingress RBridge.
For b) no...I believe that having both the RBridge algorithm and the 
bridge algorithm feeding into
each other will create much slower convergence.

If I haven't summarized correctly, then someone else can try to capture 
the arguments, but I do
think we should merge discussion under one subject line, and restart 
with a summary.

Radia

---

From: saikat at seas.upenn.edu (Saikat Ray)
Date: Sun, 16 Oct 2005 20:09:44 -0400

It is probably a standard scenario in IS-IS protocol (and consequently a
standard solution is known), but I was thinking that if the RBridges
disregards BPDUs entirely, then in some situations loops may form for some
period. For example, suppose $T_1$ and $T_2$ are disjoint trees formed
entirely by legacy elements. $R_1$ and $R_2$ are the designated RBridges for
the "links" $T_1$ and $T_2$, respectively. At this point, there is no loop
in the system. Now suppose that a physical link (or a legacy bridge) is
added that connects a legacy bridge of $T_1$ to a legacy bridge of $T_2$.
This addition will trigger a new Spanning tree computation, which will
result into a single spanning tree that spans the nodes of $T_1$ and $T_2$.
At this point, effectively the RBridges $R_1$ and $R_2$ are connected by a
single "link" and until one of the RBridge gets "de-designated", there would
exist a loop. Two questions arise in my mind: (i) how fast would that
"de-designation" process be? And (ii) would it be useful (i.e. would it
accelerate the convergence) if RBridges "listen" to the BPDUs?

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Radia Perlman
Sent: Sunday, October 16, 2005 7:12 PM
To: Developing a hybrid router/bridge.
Subject: [rbridge] Time to summarize "forward or block" BPDU thread

Radia

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

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Sun, 16 Oct 2005 17:45:47 -0700

The scenario you mention is where there is temporarily two Designated 
RBridges (DRs), because
two links were merged.

The DRs will notice this when they start seeing each other's IS-IS Hello 
messages, and that
will break the loop.

I don't think this case is that much of a problem, and certainly would 
not be helped by trying to run a big
global spanning tree. The big global spanning tree would converge much 
slower than the RBridge
DR election protocol would. So attempting to avoid a temporary loop when 
two bridged domains
are merged, by running a big global instance
of the spanning tree algorithm, will not solve the problem, and will 
actually
make things worse.

Radia

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Mon, 17 Oct 2005 12:26:42 +0200

I agree completely with Radia and I would add three more arguments in 
favour of Rbridge protocol separation from spanning tree protocols:
- If Rbridges are succesful, the bridges spanning trees will be legacy 
in the long term, or will tend to be excluded from the core of the 
campus network due to its much lower performance in terms of congestion, 
path length and  infrastructure usage.
- Coordination of the Rbridges protocol is not with one ST protocol but 
with TWO spanning tree protocols: STP (legacy, and slow) and RSTP 
(standard, faster). They have different mechanisms for convergence: wait 
a timer long enough to converge and  "wavefront" enabling of ports 
downstream from the root bridge  respectively. There is also a limit on 
the maximum diameter of spanning trees (related with the timer use) that 
should be taken into account by those in favour of big size spanning trees.
-Rbridges will be standardized by IETF, RSTP is under IEEE control. The 
risk of separate evolution exists. Although coordination IEEE-IETF 
works, it is better not to create  interdependencies if they can be avoided.
Guillermo

---

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

First of all, I totally agree with you that there should be multiple small
spanning trees glued by RBridge networks instead of a global huge spanning
tree. My point was slightly different, though. In the mechanism you pointed
out (hearing hallos from other RBridges), the amount of time a temporary
loop persists would depend on the time interval between hallo messages sent
by RBridges (what is the default value?). If two RBridges are connected by a
physical link, then this is probably the only way the RBridges can detect
the loop. However, if the underlying "link" is actually a bridged network
(spanning tree), then the RBridges would have more information. For example,
when RBridges see topology change BPDU's (or something similar), then they
may deduct the possibility of a loop formation and they may increase the
sending rate of hallo messages. In short, the RBridges are privileged to be
in a position to make additional observations (BPDUs) and, in my humble
opinion, they ought to use it.

-----Original Message-----
From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
Sent: Sunday, October 16, 2005 8:46 PM
To: saikat at seas.upenn.edu; Developing a hybrid router/bridge.
Subject: Re: [rbridge] Time to summarize "forward or block" BPDU thread

Radia

---

From: touch at ISI.EDU (Joe Touch)
Date: Mon, 17 Oct 2005 07:18:42 -0700

> path length and  infrastructure usage.

rbridges still rely on spanning trees at the edge; otherwise, we're
limited to 'make sure you don't wire things in a ring' like we are with
hubs.

further, rbridges still rely on bridges as transits in the core.

> works, it is better not to create  interdependencies if they can be avoided.

That's a good reason NOT to assume the IETF can force only one system on
an L2 to be privileged and be allowed to BLOCK.

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/20051017/c7166e81/signature.bin

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Mon, 17 Oct 2005 16:39:28 +0200

>further, rbridges still rely on bridges as transits in the core.
Sorry, I agree on both sentences, but I do not understand the argument.

>an L2 to be privileged and be allowed to BLOCK.
(I copy here my previous message on the PARTICIPATE ROLE)

Sorry, I did not follow the whole discussion on the BLOCK / TRANSPARENT / PARTICIPATE. 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  stp operation ,  where the bridge 
builds the BPDUs to be transmitted  based on information collected from 
all bridge ports and selecting the best BPDU, thus containing the distance 
to root bridge. I would call this mode PARTICIPATE PER PORT.
Rbridge ports should announce themselves as designated ports of  Rbridge 
(IS-IS Designated Bridge acting as STP root bridge). The Rbridge ports will be in role Designated if they win the 
competition for 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.
Regarding BLOCK, it seems to be a decision of the network administrator, like when deciding not to enable spanning tree protocol ( I did not follow the discussion, may be I miss the point).
Guillermo

>Joe
>
>  
>
>------------------------------------------------------------------------
>