Subject: [rbridge] Use of 802.1ah Encaps

From: sgai at nuovasystems.com (Silvano Gai)
Date: Mon, 11 Dec 2006 07:19:04 -0800

Ali, 

Inline:

> -----Original Message-----
> From: Ali Sajassi (sajassi) [mailto:sajassi at cisco.com]
> Sent: Sunday, December 10, 2006 3:48 PM
> To: Silvano Gai; Joe Touch
> Cc: Radia.Perlman at sun.com; Don Fedyk; Gray, Eric; Developing a hybrid
> router/bridge.
> Subject: RE: [rbridge] Use of 802.1ah Encaps
> 
> 
> 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).

You are absolutely right, but TRILL does more, it assumes a sequence of
RBridges interconnected by bridged-LAN network.

-- Silvano

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