Subject: [rbridge] Use of 802.1ah Encaps

From: sajassi at cisco.com (Ali Sajassi (sajassi))
Date: Wed, 6 Dec 2006 11:15:51 -0800

Eric,

> -----Original Message-----
> From: Gray, Eric [mailto:Eric.Gray at marconi.com] 
> Sent: Wednesday, December 06, 2006 5:45 AM
> To: Ali Sajassi (sajassi); Don Fedyk
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> Ali/Don,
> 
> 	The use of 802.1ah encapsulation does not intuitively 
> suggest itself in the TRILL problem domain for at least two
> reasons:
> 
> 1)	Provider Back-bone Bridging intuitively seems out of
> 	place in solutions aimed at enterprise networks - and
> 	this would seem to be even more true for solutions 
> 	aimed at "plug-and-play" applicability.

802.1ah can equally be used in enterprise network with the same
plug-and-play ease of use. If you think otherwise, please elaborate what
part of 802.1ah is not suitable for such applications. 

> 
> 2)	Use of 802.1ah encapsulation assumes "bridging" of the
> 	tunneled frame transparently from edge-to-edge - and
> 	this would seem to go counter to the idea of using a
> 	link-state routing protocol for shortest path routing
> 	of MAC frames.
> 

802.1ah primarily specifies the data-plane functionality. The use of
link-state control-plane is independent from data-plane specification
and one can easily use a link-state routing protocol with 802.1ah encap.
As the mater of fact 802.aq is a step in this direction and this would
be an area of mutual interest between the two working groups. 

> 	That said, the minute that we start suggesting that an 
> enterprise is large enough to require using service provider
> (like) solutions (in particular, requiring a substantial 
> back-bone capacity, and assuming static configuration as a 
> means to ensure deterministic network behavior) - OR that we 
> might in fact use some form of spanning tree forwarding - it 
> then becomes clear that we should consider using 802.1ah.  It 
> is certainly the case that we should not be defining another 
> Ethernet encapsulation explicitly to solve the same problem.

As mentioned before, the use of 802.1ah does not mandate the use of
spanning tree - link-state protocol can be used as well with the same
plug-and-play objectives. I think the convergence in here is a good
thing and the industry can benefit as whole.

-Ali  

> 
> --
> Eric
> 
> > -----Original Message-----
> > From: rbridge-bounces at postel.org 
> > [mailto:rbridge-bounces at postel.org] On Behalf Of Ali 
> Sajassi (sajassi)
> > Sent: Wednesday, December 06, 2006 2:39 AM
> > To: Don Fedyk; Developing a hybrid router/bridge.
> > Subject: Re: [rbridge] Draft minutes posted
> > 
> >  
> > 
> > 
> > Yes, if there is any reason as to why .1ah encap cannot be 
> > used, then I
> > would like to hear it.
> > 
> > -Ali 
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: rbridge-bounces at postel.org 
> > > [mailto:rbridge-bounces at postel.org] On Behalf Of Don Fedyk
> > > Sent: Tuesday, December 05, 2006 10:17 AM
> > > To: Developing a hybrid router/bridge.
> > > Subject: Re: [rbridge] Draft minutes posted
> > > 
> > > Hi Erik
> > > 
> > > In the minutes: 
> > > 802.1ah header synergy?  On this point myself, and I recall 
> > > Ali Sajassi and Donald Oconnor all stood up and said that 
> > > 802.1ah is going to be a standard encapsulation header. My 
> > > point was Trill should see what it could deliver on this 
> > > encapsulation before inventing similar but different headers.
> > > 
> > > Regards,
> > > Don  
> > > 
> > > > -----Original Message-----
> > > > From: rbridge-bounces at postel.org
> > > > At http://www3.ietf.org/proceedings/06nov/minutes/trill.txt
> > > > 
> > > > Any corrections?
> > > > 
> > > >     Erik
> > > > 
> > > 
> > > _______________________________________________
> > > rbridge mailing list
> > > rbridge at postel.org
> > > http://mailman.postel.org/mailman/listinfo/rbridge
> > > 
> > 
> > _______________________________________________
> > rbridge mailing list
> > rbridge at postel.org
> > http://mailman.postel.org/mailman/listinfo/rbridge
> > 
>