Subject: [rbridge] RB core Subcase for RBridges?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Thu, 3 Nov 2005 22:07:46 -0200

Guillermo,

	I've omitted the portions of the discussion below that
we probably don't need to continue.  Hopefully, I've not taken
out too much of the context.  :-)

--
E

--- [SNIP] ---

--> 
--> Eric,
-->        The basics of the proposal is that RBridges that hear RBridge 
--> frames at one port assume there are RBridges connected to them, 
--> although they might be connected  via "B" bridges with point to point 
--> links. RBridges hearing RBridge type frames at one port assume the 
--> "core" port mode. In the "core" port mode, the RBridge routes whithout  
--> DA address change the encapsulated frames received at other RBridge core

--> ports via corresponding core port to destination RBridge. 
-->
--> If the RBridge y does not hear RBridge type frames at that port or it 
--> knows (by the attached B bridge port data or by another mechanism) that

--> the port is attached to a shared link, it sets the port in
"distribution" 
--> mode. The ports in distribution mode or distribution ports only act as 
--> ingress/egress to the core.
-->

Where "another mechanism" probably refers to configuration?

-->
-->      I think that with this arrangement, the "inside" and "outside" of 
--> the core are clearly defined. See below some more comments
-->
--> Guillermo
-->

--- [SNIP] ---  

--> >-->
--> >--> Although changing destination address at each hop is not too 
--> >--> complicated, this  is something that even routers do not 
--> >--> do, they keep the IP source and destination addresses of 
--> >--> packets.
--> >
--> >Not sure how this is relevant, but routers always re-write the 
--> >MAC SA/DA when forwarding IP packets. 
--> >
-->
--> This occurs because the layer 2 difussion domain changes.
--> 

It is slightly more accurate to say that this happens because 
routers are not transparent at layer 2.  A router re-writes the
MAC SA/DA even when forwarding IP packets onto the same layer 2
diffusion domain.  

In any case, I think we agree that this is a not particularly
relevant side discussion.

--- [SNIP] ---

--> >--> >
--> >--> >                                            +------------+
--> >--> >      +------------------------+            |    +---+   |
--> >--> >      |                        |            | +--+ B +-+ |
--> >--> >      |  +---+  +----+  +---+  |            | |  +---+ | |
--> >--> >   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
--> >--> >      |  +---+  +----+  +---+  |            | | +----+ | |
--> >--> >      |                        |            | +-+ RB +-+ |
--> >--> >      +------------------------+            |   +----+   |
--> >--> >              Hybrid A                      +------------+
--> >--> >    						Hybrid B
--> >--> >
--> >--> Is Hybrid B  allowed?
--> >
--> >I don't know that it makes sense, but - if you remove the outer
--> >box and consider the B and RB as separate boxes - it is certainly
--> >one of the potential scenarios we've talked about.  Since it can
--> >happen outside the box, I see no particular reason to put on the
--> >blinkers for the possibility of it happening inside the box.
--> >
--> >Also, Hybrid B is one view of what you're talking about, since
--> >what would normally be the next hop RBridge has to "bridge" the
--> >MAC frames it receives that are not addressed to it in what you
--> >are talking about.
--> >
--> >Take this example:
--> >
--> >    H1 ---> RB1 <---> RB2 <---> RB3 <--- H2
--> >
--> >As I understand it, you propose that RB1 might encapsulate a frame
--> >coming from H1 and going to H2 with SA/DA = RB1/RB3 rather than
--> >SA/DA = RB1/RB2.  What that means is that RB2 has to bridge those
--> >frames from RB1 to RB3 as - otherwise -  it would simply ignore 
--> >any frame not addressed to it.
--> >  
--> >
--> No. It means RB2 *routes* those frames in the same way  (with IS- IS) 
--> but it does not change the DA.
-->

Independent of option complexity, there are a few problems with this 
approach:

   1) Reachability information distributed via IS-IS is for H1, H2 and
	similar MAC addresses. It will include RB1, RB2 and RB3 (and like)
	addresses, but that is not the purpose.  RB1, on receiving a frame
	for H2 needs to know how to route the frame across the RBridge
	campus.  As a result of having reachability data on RB3, RB1 could
	use RB3 as the DA, when sending it to RB2, and RB2 could forward 
	the frame to RB3.  But this is a strictly tunneling approach as 
	opposed to a routing approach, for two reasons -
	a)	it is not done using (H2) destination-based hop-by routing,
	b)	it scales like a tunneling (or bridging) approach more than 
		a hop-by-hop routing approach.
   2) Because the ingress decides which egress the frame will use, as
	opposed to which next-hop, more frames will be dropped or routed
	incorrectly during a network topology change - or if a destination
	moves - than would be the case with a hop-by-hop approach.
   3) Since each RBridge from ingress to egress now needs to be concerned
	with forwarding to each egress in addition to (or opposed to) each
	neighbor, RBridges will need slightly larger forwarding tables.

And there are a few plusses with this approach:

   A) For the campus consisting of non-shared links exclusively between
	RBridges, only the campus ingress RBridge needs to do a look-up on
	the original MAC DA and determine the appropriate campus egress.
	It is not necessary for intermediate RBridges to peek beyond the 
	outer MAC encapsulation.

   B) Under those same circumstances, only ingress and egress RBridges
	need to do anything with respect to the outer MAC encapsulation.

One might be tempted to think that advantage B would allow for simpler
"interior" RBridge implementations. However - because the definition of
"interior" in this case is an RBridge with no external interfaces - the
illusion of simplicity is shattered the second you hang an NMS off of a
port on an "interior" RBridge.

The minute that an implementation is required to support both a proposed 
interior mode and the default not-so-interior mode, it's more complicated
than if it only supported the default mode.  This is made worse if we try 
to extend it to an environment where some campus interior links are shared 
- while others are not - because now we need to communicate beyond adjacent 
peers to determine if each successive peer on a path toward each egress can 
be "skipped" (by using a downstream RBridge's MAC as DA instead). 

The above discussion was "independent of option complexity".  One thing we
all hear a lot of is that "options are bad".  Any time we have two ways of
doing something when one would have satisfied all cases, we have made a
mistake.

Because "skipping" can't be used all the time, the hop-by-hop mode has to
be supported.  So the question becomes is the added complexity in both the
control and forwarding planes - across all cases - justified by a possible 
reduction in RBridge forwarding complexity in a (possibly large) subset of
all cases?

--- [SNIP] ---

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Fri, 04 Nov 2005 06:54:48 +0100

Eric,
        I see "interior" or "core" mode as an optional, simplified 
protocol variant, not oriented to coexist with normal mode.
See below.

>out too much of the context.  :-)
I meant RBridge accessing  info on that port, not configuration info 
specifically, although it might include it.

>relevant side discussion.
I agree. It is a non relevant discussion.

>--- [SNIP] ---
Destination, for routing purposes, is RB2, not H2.

>		a hop-by-hop routing approach.
Scaling limitation for RBridges is a consequence of using MAC (flat, non 
aggregatable addresses)  addresses instead of hierarchical addressing. 
The routing is still hop-by-hop if you consider RB2 as destination. I do 
not see the difference in scalability.

>	moves - than would be the case with a hop-by-hop approach.
I do not see much difference in the real routing decisions as long as a 
host is associated to its Designated RBridge.
The ingress doest not decide the eggress. The eggress is the Designated 
RBridge of  the destination host as announced by the egress in its hosts 
list.
The routing tables for routes between RB's (shorter) may converge after 
reconfiguration much faster than updating routing tables for all 
destination hosts.

>	neighbor, RBridges will need slightly larger forwarding tables.
Very slightly larger (number of RBridges-1), if in addition.  For 
transit  RBridges  (RBridges without hosts) much shorter tables Orders: 
O(number of  RBridges) versus O(number of hosts).

>reduction in RBridge forwarding complexity in a (possibly large) subset of
I agree that both modes should be exclusive. They are not intended to 
coexist in the same campus network. It is a decision of the campus 
designer/administrator to use interior (core) mode or  normal mode in 
all RBridges. Looking for compatibility means complicating things.  The 
"interior" mode (I prefer the term "core" ),  probably fits  better as 
a  simplified but separate and alternative version of the protocol for 
high performance cores made of RBridges where compatibility with bridges 
is excluded inside the core.

Speficying "interior" mode as an *optional* mode does not complicate 
standard implementations and allows simpler implementations oriented to 
high performance  cores.

>--- [SNIP] --- 
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>