Subject: [rbridge] Use of 802.1ah Encaps

From: Radia.Perlman at sun.com ([email-masked])
Date: Sat, 09 Dec 2006 00:25:21 +0500

There's 3 sets of addresses:

a) original frame: endnode source and destination MACs.
b) shim: ingress and egress RBridges
c) outer: next hop, previous hop.

Forwarding is to egress RBridge in order to make RBridges inside not have
to know about all the endnodes, especially in VLANs they are not connected to.
So forwarding by Rbridges between the ingress and egress is solely by
"egress RBridge", not by the source/destination in the inner frame

Outer header (nxt hop/previous hop) is for shared media....if there's a cloud in
the middle with multiple nodes, including multiple RBridges, the "next hop"
lets any bridges on that cloud know where to send it, and won't have them
fallaciously filtering.

Radia
-------------- next part --------------

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