Subject: [rbridge] Use of 802.1ah Encaps

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Fri, 15 Dec 2006 11:54:29 -0500

Don,

	I will reply to your points in separate threads: 

-	TTL Use
-	Breaking up Spanning Trees
-	Synergy

> -----Original Message-----
> From: Don Fedyk [mailto:dwfedyk at nortel.com] 
> Sent: Thursday, December 14, 2006 10:48 AM
> To: Gray, Eric
> Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> Sajassi (sajassi); Silvano Gai
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Hi Eric 
> 
> > -----Original Message-----
> > From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
> > 
> > Don,
> > 
> > 	I think you've garbled the discussion, somewhat.
> > 
> > 	Please see below...
> I'll answer inline here specifically. Thanks for providing 
> more context.
> 
> > 
> > --
> > Eric 
> > 
> > > -----Original Message-----
> > > From: Don Fedyk [mailto:dwfedyk at nortel.com] 
> > > Sent: Wednesday, December 13, 2006 1:19 PM
> > > To: Gray, Eric
> > > Cc: Developing a hybrid router/bridge.; Joe Touch; Ali 
> > > Sajassi (sajassi); Silvano Gai
> > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > 
> > > Hi Eric 
> > > 
> > > > -----Original Message-----
> > > > From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
> > > > 
> > > > Don,
> > > > 
> > > > 	I don't follow your reasoning.
> > > That's OK I cant follow you sometimes either ;-)
> > > 
> > > > 
> > > > 	I certainly am not saying that using "ANY 
> standard header"
> > > > is a bad idea.
> > > Then why not start from ah?  The bit that Silvano said was we 
> > > could use ah and you said it is a bad idea.  
> > 
> > I don't think I am quoting too much out of context, when I quote
> > the following from Silvano's reply to Joe Touch:
> > 
> > SILVANO > My comment is that IEEE 802.1ah has no space for both 
> > SILVANO > the ultimate source/dest and the next hop source/dest.
> > 
> > SILVANO > IEEE 802.1ah is designed for multiple enterprises to 
> > SILVANO > share a common metro backbone. It does a fine job in 
> > SILVANO > that area. It does not support well an arbitrary 
> > SILVANO > intermixing of Bridges and Rbridges.
> > 
> > SILVANO > In contrast Trill does a fine job in supporting 
> > SILVANO > arbitrary topologies and mixing of RBridges and 
> > SILVANO > Bridges thanks to the availability of both the
> > SILVANO > ultimate source/dest and the next hop source/dest.
> > 
> > SILVANO > In TRILL the network between the "ingress" and 
> > SILVANO > "egress" RBridge isn't a single Ethernet (like in 
> > SILVANO > 802.1ah), but rather a sequence of RBridges that 
> > SILVANO > may be connected by Ethernets.
> > 
> > SILVANO > Things look similar, but are substantially different.
> > 
> > Given that this is what (I believe, at least) Silvano said 
> > about using 802.1ah, where do you get the impression that 
> > Silvano has said that "we could use ah"?
> > 
> > > 
> > > Please describe "BAD idea" then.
> > 
> > In this, I think quite a few of us are now in agreement.
> > 
> > It is rarely a good idea to use a header format just because
> > most of the bits look similar to one proposal that has all
> > of the information you require.
> 
> I agree. Bits on the wire looking just like other bits on the wire
> having different context are not good.
> 
> > 
> > Suppose you started to think that using 802.1ah - because it 
> > is similar to an abbreviated combination of (MAC+SHIM)-in-MAC 
> > - was an example of one of the rare instances in which this 
> > might be a good idea.  Wouldn't you suspect that the need to 
> > consider potentially adding a TTL field to the header might 
> > be an indication that you are probably wrong?
> 
> Ahh this is what you mean. TTL is one method for a number of things,
> Loop mitigation, tracing, fault monitoring etc. It has pluses and
> minuses. Personally speaking as an individual I like TTL.  
> Although I am
> also aware of many systems and I also built systems that are 
> operational
> without TTL. TTL has shortcommings as well even in IP.  It is 
> not a bad
> tool for some applications.  I know this group values it, I'm not
> suggesting you drop that goal or requirement.  But a 
> requiremetn for TTL
> alone does not mandate a licence to change everything either IMHO. 
> 
> > 
> > So, to answer your question, a "BAD idea" is one that takes
> > valuable resources to explore and offers no believable cause
> > to suspect that it will work better than other ideas already
> > on the table.
> > 
> > In this case, we have reason to believe (MAC+SHIM)-in-MAC
> > will work and no reason to believe that 802.1ah will work 
> > better - even assuming we went down that rat-hole.
> >  
> > > 
> > > > 
> > > > 	As for "creating a new forwarding paradigm" - yes, we're
> > > > doing a little bit of that.  Ideally, we'll be doing as little
> > > > of that as we can get away with.  The "little bit" we have to
> > > > do is to use some additional header information to:
> > > > 
> > > > 	1) forward frames on the shortest path between RBridges,
> > > > 	   and
> > > > 	2) reduce or eliminate potential looping of 
> frames during
> > > > 	   a perturbation of the shortest path.
> > > 
> > > You have so far chosen to do this in a mode that 
> optimizes for mixed
> > > bridges at the cost of ignoring the effciencies you could 
> > get between
> > > directly connected Rbridges. 802.1ah opimizes forwarding 
> > for connected
> > > Provider Backbone Bridges and interworks with legacy at a common
> > > denominator. 
> > 
> > Right, and 802.1ah assumes either a green-field deployment, or a 
> > firmware modifiable deployment of PBB-(enabled/compatible) bridges.
> > 
> > This is not consistent with our goals.
> 
> 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
> comodization 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>
> > > > > 
> > > > 
> > > 
> > 
>