[rbridge] Breaking up of Spanning Trees - (Was Use of 802.1ah Encaps)

[Gray, Eric]

Don,

	We (the TRILL working group) are not completely decided
on this, and how we can make it work in the face of other things
we also have to make work.

	Yes, we want to break up the spanning trees, but we also
are being asked to address certain issues that arise as a result
of doing so.  In particular, there is a "wiring closet" problem
that we have been assured is one we MUST solve.

	The (currently?) leading proposal for how to deal with 
that is to have (some?) RBridges participate in spanning tree
protocol in such a way as to cause "wiring closet" bridges to
see (at least part of) the RBridge "CRED" as a single bridge 
(with that bridge set up to be the root bridge).  I am pretty 
sure (at this point) that this will be a configurable option 
which will not be "on" by default.

	I think the reasoning for this is that it would be okay 
to have a configuration requirement that would only require
configuration if it is necessary to solve this problem - hence 
it remains possible to have a plug-and-play solution.

	However, this particular problem points out a potential 
"general class" of problems relating to breaking up spanning
trees.  And we do not currently have a "correctness proof" -
or even a good try at one - that might lead us to believe that
we do not have further issues to address, except by turning 
this "breaking up" feature off.

	For example, one model for RBridge interactions - that
has been considered from very early on - is one where a "CRED"
appears to existing 802.<whatever> bridges as a single bridge.
This model does not suffer from the above "general class" of
problems, because it does not actually break up the spanning
trees.  All of the fractional LANs separated by RBridges will
see each other in spanning tree protocol if this model is used.

	As a direct consequence, it may turn out that we will be
required to support - at least as a configurable option - that
RBridges do not break up spanning trees.  I believe there is a
lot of work that needs to be done if this is the case...

--
Eric

(part of your earlier message included the following)	
> 
> But as Ali pointed out 802.1ah is backwards compatible with 
> everything.  On goals one goal of RBridge was to improve 
> spanning tree by breaking up a large spanning tree with 
> Rbridges providing interconnection of these smaller trees. 
> A certain amount of insertion of Rbridges on shortest paths 
> is required before this goal is realizable.  I agree large
> provider networks are not your goal. And perhaps you are 
> right that this justifies different technology but Ethernet 
> did not get to high scale [commoditization] by changing the 
> forwarding paradigm.
> >  
> > > 
> > > > 
> > > > This may be somewhat of a simplification, but that's fair in 
> > > > light of the general trend for casual observers to do the
> > > > opposite.
> > > > 
> > > > 	Currently, we define a SHIM to carry this 
> information and 
> > > > we expect to use one or more "standard headers" to encapsulate
> > > > frames being forwarded between RBridges.
> > > > 
> > > > 	Does this make things clearer?
> > > 
> > > Eric I understand what is proposed but I still question 
> if a greater
> > > synergy cannot be achieved between encapsulating headers.  
> > A shim is a
> > > not a typical solution but encapsulations are.
> > 
> > Greater synergy is always demonstrably possible if you're willing
> > to wait long enough.
> > 
> > That's - for example - why we only have one link-state routing 
> > protocol, and why Ethernet was the one and only MAC-like format
> > for L2 frames ever to have been used.
> > 
> > What planet are we on?  :-)
> As an engineer I have to ask the question. "Is this the best 
> we can do?"
> So even though history has proven that multiple implementations often
> result the question has to be asked never the less.
> 
> Regards,
> Don 
> 
> 
> > 
> > > 
> > > Regards,
> > > Don   
> > > 
> > > 
> > > > 
> > > > --
> > > > Eric
> > > > 
> > > > > -----Original Message-----
> > > > > From: Don Fedyk [mailto:dwfedyk at nortel.com] 
> > > > > Sent: Wednesday, December 13, 2006 12:18 PM
> > > > > To: Gray, Eric; Silvano Gai
> > > > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > > > Sajassi (sajassi)
> > > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > > 
> > > > > Hi Eric
> > > > > 
> > > > > This argument says if you use ANY standard header then it 
> > > > would be a bad
> > > > > idea.
> > > > > 
> > > > > So you are creating a new forwarding paradigm and the down 
> > > > side of that
> > > > > as Ali pointed out is now you have to create most of the 
> > > > other things
> > > > > that go along with new forwarding paradigm.  
> > > > > 
> > > > > Don  
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
> > > > > > Sent: Tuesday, December 12, 2006 4:29 PM
> > > > > > 
> > > > > > Silvano,
> > > > > > 
> > > > > > 	IFF we were going to use 802.1ah, it could allow us to  
> > > > > > use the "back-bone" DA/SA for next-hop/previous-hop and the
> > > > > > "customer" DA/SA for egress/ingress RBridges.  But 
> that would 
> > > > > > be using it in a way that is not consistent with 
> the intended
> > > > > > use of 802.1ah - simply because that usage would 
> make use of 
> > > > > > the fields in a way that matches the way that your proposed 
> > > > > > "short-hand" SHIM header would use them.
> > > > > > 
> > > > > > 	If you did that, there would be room for using the B-tag
> > > > > > and I-tag as analogues of your I-VLAN and O-VLAN tags.
> > > > > > 
> > > > > > 	I think this is a VERY BAD idea.
> > > > > > 
> > > > > > --
> > > > > > Eric
> > > > > <snip>
> > > > > 
> > > > 
> > > 
> > 
>