Subject: [rbridge] Use of 802.1ah Encaps

From: sajassi at cisco.com (Ali Sajassi (sajassi))
Date: Sun, 10 Dec 2006 15:06:58 -0800

> -----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
> > 
>