[rbridge] Use of 802.1ah Encaps

[Silvano Gai]

Joe,

Inline:

> -----Original Message-----
> From: Joe Touch [mailto:touch at ISI.EDU]
> Sent: Friday, December 08, 2006 7:29 AM
> To: Silvano Gai
> Cc: Radia.Perlman at sun.com; Ali Sajassi (sajassi); Don Fedyk; Gray,
Eric;
> Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Use of 802.1ah Encaps
> 
> 
> 
> Silvano Gai wrote:
> > Joe,
> >
> > TRILL will never scale if you mandate to keep the forwarding table
for
> > the inner addresses on all RBridges, especially in a IEEE 802.1ah
> > environment!!!
> 
> Sorry; let me backup:
> 
> Here's where we were at the last IETF:
> 
> - the shim indicates the source (ingress) and dest (egress)
>   (originally this was just dest for unicast, source for mcast
>   but we agreed in San Diego to include both)
> 	i.e., agreed with the point above; those are the
> 	addresses on which packets are forwarded
> 
>   the ultimate source is indicated in the shim already
> 
> - the outer header already indicates the previous/next-hop rbridge
> 
> What's the reason for needing any further information?

We don't.

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

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.

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.

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