Subject: [rbridge] Use of 802.1ah Encaps

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Tue, 12 Dec 2006 16:37:59 -0500

Ali,

	I agree with your argument below in every sense. But 
I fail to see why that argument leads to a recommendation 
to use 802.1ah encapsulation.

	We were initially expecting to use 802.3 Ethernet
encapsulation of a SHIM-encapsulated, tunneled Ethernet
frame.  That is a use of IEEE-conformant frame formats.

--
Eric

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com] 
> Sent: Sunday, December 10, 2006 6:07 PM
> To: Radia.Perlman at sun.com
> Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid 
> router/bridge.; Joe Touch
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
>  
> 
> > -----Original Message-----
> > From: Radia.Perlman at sun.com [mailto:Radia.Perlman at sun.com] 
> > Sent: Thursday, December 07, 2006 9:56 PM
> > To: Ali Sajassi (sajassi)
> > Cc: Silvano Gai; Don Fedyk; Gray, Eric; Developing a hybrid 
> > router/bridge.; Joe Touch
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > Travelling again, so extremely limited access to email (as 
> > in, about 10 minutes here and there on a SLOW connection).  
> > Anyway, I'll answer some of these:
> 
> Also sorry for not being able to respond to your email 
> earlier due to my
> schedule/meetings (specially on Friday).
> 
> > 
> > a) why "next hop" and "previous hop" in addition to 
> > "ultimate" source and destination
> > 
> > At least one of the reasons is that if there are three 
> > RBridges on the same link, R1, R2, and R3, it is useful for 
> > R1 to choose which of R2 or R3 should receive the packet. It 
> > isn't obvious from the destination address because it could 
> > be that either R2 or R3 would be logical, and R1 is load 
> > splitting. Also, it helps focus traffic on the link, and 
> > ensure it doesn't get filtered, if the bridges on the link 
> > only need to learn R1, R2, and R3, especially since traffic 
> > from outside RBridges might arrive from different entry 
> > points onto the link.
> 
> O.K., I remember now the discussion that we had during the 
> IETF meeting
> on load balancing and next hop address. However, there are couple of
> ways for achieving the same result. I mentioned briefly during the
> meeting the use of VLAN for this purpose and someone else mentioned
> using part of 48-bit provider MAC address for this purpose.
> 
> > 
> > b) congestion management was explained to us, and it was what 
> > convinced us we needed "ultimate source RBridge" in order to 
> > know where to send the congestion notification. If you could 
> > explain the other things, we could see if there is a problem, 
> > but if they are similar to congestion notification, then 
> > having the ingress RBridge will accommodate them.
> > 
> 
> With respect to CFM, connectivity fault mgmt is done in a hierarchical
> way and it can be performed at the provider service instance level
> (e.g., on a per I-SID basis) or it can be performed for group 
> of I-SIDs
> on a per B-VLAN level. In both cases, provider MAC addresses are used
> which makes the provider OAM control for customer data-traffic very
> tight. You cannot get the same result by using OAM messages that use
> customer MAC addresses and if you try to do it will be very 
> cumbersome.
> 
> Basically what I am trying to point out is that by using non-IEEE
> conformance frame format, you assume the responsibility for all the
> features developed by IEEE; where as, if you use IEEE 
> conformant frame,
> then one can concentrate on the control plane issues which I 
> thought was
> the main objective of TRILL.
> 
> -Ali 
> 
> > Sorry for ignoring all the other messages for now, but I only 
> > had a chance to read and respond to one message.
> > 
> > Radia
> > 
> > ----- Original Message -----
> > From: "Ali Sajassi (sajassi)" <sajassi at cisco.com>
> > Date: Friday, December 8, 2006 10:53 am
> > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > 
> > > 
> > > Silvano,
> > > 
> > > > -----Original Message-----
> > > > From: Silvano Gai [sgai at nuovasystems.com]
> > > > Sent: Thursday, December 07, 2006 5:36 PM
> > > > To: Don Fedyk; Gray, Eric; Ali Sajassi (sajassi)
> > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > Subject: RE: [rbridge] Use of 802.1ah Encaps
> > > > 
> > > > 
> > > > IMO it is technically possible for TRILL to adopt IEEE 802.1ah. 
> > > > There are advantages and disadvantages.
> > > > 
> > > > The disadvantages are:
> > > > 1) Lack of Next-Hop addresses. We discussed this at 
> length during 
> > > > the last meeting and we didn't reach consensus on a way 
> > to eliminate 
> > > > them.
> > > 
> > > Can you refresh my memory for why we need a next-hop 
> > address when the 
> > > header carries both source and destination PE addresses and 
> > when these 
> > > addresses are learned in control plane ?
> > > 
> > > > 2) Lack of a TTL field (it may be added, but it is not 
> > there today).
> > > 
> > > Can probably be accommodated.
> > > 
> > > > 3) Many unneeded fields and therefore larger frame overhead.
> > > > 
> > > 
> > > Such as ?
> > > 
> > > > The advantages are:
> > > > 1) Larger addressable market for TRILL
> > > > 
> > > > IMO if we stick with the WG charter the disadvantages clearly 
> > > > outweigh the advantages.
> > > > 
> > > > The WG can be re-chartered, but if we consider the 
> Enterprise and 
> > > > Data Center market, IEEE 802.1ah is an overkill.
> > > > 
> > > 
> > > If by overkill you mean a bit bigger header, then I agree 
> > but look at 
> > > all the other advantages that you get from using standard 
> > IEEE header 
> > > and shim including:
> > > 	- security Mgmt:  MACSec/KeySec 
> > > 	- Congestion Mgmt 
> > > 	- Connectivity Fault Mgmt
> > > 
> > > Has it been considered how these are going to work with 
> TRILL shim 
> > > header or are these outside of WG charter :-)
> > > 
> > > -Ali
> > > 
> > > 
> > > > -- Silvano
> > > > 
> > > > 
> > > > > -----Original Message-----
> > > > > From: rbridge-bounces at postel.org [rbridge-bounces at postel.org]
> > > > On
> > > > > Behalf Of Don Fedyk
> > > > > Sent: Thursday, December 07, 2006 9:21 AM
> > > > > To: Gray, Eric; Ali Sajassi (sajassi)
> > > > > Cc: Developing a hybrid router/bridge.; Joe Touch
> > > > > Subject: Re: [rbridge] Use of 802.1ah Encaps
> > > > > 
> > > > > Hi Eric
> > > > > 
> > > > > > -----Original Message-----
> > > > > > From: Gray, Eric [Eric.Gray at marconi.com]
> > > > > >
> > > > > > Don,
> > > > > >
> > > > > > 	And yet, someone (Ali Sajassi) asserted (in his message
> > > > dated Wed
> > > > > > 12/6/2006 at 2:16 PM EST) that there were no issues or
> > > additional
> > > > > > complications with using 802.1ah in enterprises for 
> plug-and-
> > > play
> > > > > > applicability.
> > > > > >
> > > > > > 	Perhaps Ali can answer my question then.
> > > > > >
> > > > > > 	But, to more directly address your earlier comments:
> > > > > >
> > > > > > 	The TRILL WG has NOT come up with an encapsulation that
> > > "looks
> > > > > > like" 802.1ah - unless someone squints really hard and tries
> > > to
> > > > > > pretend that two separate Ethernet encapsulations -
> > > > separated by a
> > > > > > SHIM header - are one single encapsulation.
> > > > > 
> > > > > To be fair Point to Point header that was discussed without
> > > > one of the
> > > > > shims was very close "functionally" (colloquial looks like) to
> > > > 802.1ah.
> > > > > My opinion is still we don't need several variations of
> > > > headers doing
> > > > > similar things.
> > > > > 
> > > > > This was the slide that looked a lot like what I posted.
> > > > > 
> > > > > 
> http://www3.ietf.org/proceedings/06nov/slides/trill-1/sld13.htm
> > > > > 
> > > > > Regards,
> > > > > Don
> > > > > >
> > > > > > 	That is not to say that the WG has done anything that
> > > > could be said
> > > > > > to disallow the use of 802.1ah encapsulation.
> > > > > > It is just not obviously consistent with all of the WG
> > > > goals to use
> > > > > > _only_ 802.1ah encapsulation.
> > > > > >
> > > > > > --
> > > > > > Eric
> > > > > >
> > > > > 
> > > > > _______________________________________________
> > > > > 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
> > > 
> > 
>