[rbridge] Use of 802.1ah Encaps

[Ali Sajassi (sajassi)]

Silvano,


> 
> My comment is that IEEE 802.1ah has no space for both the 
> ultimate source/dest and the next hop source/dest.
> 

Yes, it doesn't but if next hop source/dest is needed, it can be derived
through other means as discussed briefly during last IETF meeting. 

> IEEE 802.1ah is designed for multiple enterprises to share a 
> common metro backbone. It does a fine job in that area. It 
> does not support well an arbitrary intermixing of Bridges and 
> Rbridges.

IEEE 802.1ah is designed to work with a mix of 802.1Q, 802.1ad, and
802.1ah bridges.


> 
> In contrast Trill does a fine job in supporting arbitrary 
> topologies and mixing of RBridges and Bridges thanks to the 
> availability of both the ultimate source/dest and the next 
> hop source/dest.
> 
> In TRILL the network between the "ingress" and "egress" 
> RBridge isn't a single Ethernet (like in 802.1ah), but rather 
> a sequence of RBridges that may be connected by Ethernets.

802.1ah doesn't assume that the network between ingress and egress edge
bridges is a single Ethernet. It assume a bridged-LAN network (e.g.,
802.1Q network).

-Ali

> 
> Things look similar, but are substantially different.
> 
> -- Silvano
> 
> 
> > 
> > As per below, if R1 (current rbridge) wants to pick from among
> multiple
> > next-hops R2 and R3, it does so with the outermost ethernet 
> header. If 
> > they're logical (R2/R3 both on the same NIC), then just assign
> separate
> > ethernet addresses to the same interface.
> > 
> > What's left?
> > 
> > Joe
> > 
> > 
> > >> -----Original Message-----
> > >> From: Joe Touch [mailto:touch at ISI.EDU]
> > >> Sent: Thursday, December 07, 2006 11:00 PM
> > >> To: Radia.Perlman at sun.com
> > >> Cc: Ali Sajassi (sajassi); Silvano Gai; Don Fedyk; Gray, Eric;
> > > Developing
> > >> a hybrid router/bridge.
> > >> Subject: Re: [rbridge] Use of 802.1ah Encaps
> > >>
> > >>
> > >>
> > >> Radia.Perlman at sun.com wrote:
> > >>> 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:
> > >>>
> > >>> 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.
> > >> The ultimate destination (and source, for that matter) should be 
> > >> sufficiently indicated by the inner ethernet packet. The outer
> header
> > > is
> > >> already hop-by-hop inside the rbridge anyway. What additional 
> > >> information is required?
> > >>
> > >> The next/previous hop information sounds like a source 
> route with 
> > >> record-route option. While that's useful for debugging, 
> it doesn't
> > > seem
> > >> necessary.
> > >>
> > >>> 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.
> > >> Why doesn't the source ethernet address indicate this already?
> > >>
> > >> Joe
> > >
>