Subject: [rbridge] Subcase for RBridges?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 2 Nov 2005 12:53:10 -0200

Guillermo,

	I assume that - by point-to-point link - you mean full-duplex
Ethernet/802.  Since we are not trying to address L2 connectivity
other than Ethernet, that should be the case within the scope of 
discussion on this list.

	It is difficult for any implementation to divine the nature of
the "wire" connecting it to another implementation - whether RBridge
or bridge.  In many cases, it is possible - for example, by looking
at port-type information and listening to both RBridge neighbor 
discovery and local STP - but not in every case.

	For example, the mysterious "lurking" L2 forwarding device that
participates in neither RBridge neighbor discovery, nor STP would be
invisible and - presumably - RBridges would likely be invisible to 
it as well.

	In addition, there are a variety of transitional states in
which it is very likely that an inferred point-to-point link will 
no longer be point-to-point and the RBridges will not be aware of
that.

	However, even if all this were not true, what do we gain from
"special casing" this special case - even if it does turn out to be
common?

	I assume we're not intending that a frame may use a different
path, in this special case and not using the next-hop MAC address,
so it still goes through the same devices.  That would be opening
a different can of worms. The only difference is that frames don't 
get their MAC SA/DA changed at each RBridge.  But that's a simple 
operation for typical forwarding hardware.

	Given that the forwarding device has to be able to do that,
there isn't anything to gain from being able to avoid doing so -
sometimes.

	As for what Radia suggested earlier, there's a difference
between potentially having logical bridges in-line with ports on
an RBridge, and having a logical bridge connecting the ports of
an RBridge.  But these are simply hybrid implementations and,
for our purposes, they can be considered separately from the
requirements for an RBridge.

                                            +------------+
      +------------------------+            |    +---+   |
      |                        |            | +--+ B +-+ |
      |  +---+  +----+  +---+  |            | |  +---+ | |
   ---+--+ B +--+ RB +--+ B +--+---      ---+-+        +-+---
      |  +---+  +----+  +---+  |            | | +----+ | |
      |                        |            | +-+ RB +-+ |
      +------------------------+            |   +----+   |
              Hybrid A                      +------------+
                                   |           Hybrid B
                            +------+-----+
                            |    +-+-+   |
                            |    | B +-+ |
                            |    +---+ | |
                         ---+-+        +-+---
                            | | +----+ | |
                            | +-+ RB +-+ |
                            |   +----+   |
                            +------------+
                               Hybrid C

Each of the above "hybrid" implementations is possible. But from
our perspective, we want to define the "RB" boxes and we can look
at each of these as "outside" the "RB" box.  From that perspective
all of these "hybrids" become simple variations of one or another 
of the topology examples we have already discussed.

--
Eric

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Friday, October 28, 2005 5:09 AM
--> To: Developing a hybrid router/bridge.
--> Subject: [rbridge] Subcase for RBridges?
--> 
--> 
--> I have a question regarding next-hop destination RBridge 
--> addressing. It 
--> could be avoided whitin campus cores.
--> One objection that can be made to RBridges and other 
--> proposals that keep 
--> compatibility with bridged islands  is that  the 
--> double-encapsulated 
--> frame is addressed to next-hop RBridge instead of to destination 
--> RBridge. This is necessary as, if not, the frame could be 
--> duplicated by 
--> intermediate RBridges that receive  copies of  the frame.
--> As in some cases it is foreseable that RBridges will form 
--> the core of 
--> the campus network due to their advantages regarding 
--> segmentation, links 
--> usage, etc, I wonder whether it is worth to consider the subcase of 
--> confined RBridges whithin a core area formed by RBridges 
--> linked by point 
--> to point links. Point to point links are an standard 
--> requirement for 
--> RSTP protocol (required for fast convergence) and common 
--> practice in 
--> campus networks by performance and security reasons.
--> Ports of RBridges linked to RBridges ( core ports) execute RBridges 
--> protocol with double encapsulation and ports connected to standard 
--> bridges islands (sbridge ports) act as the "B1" standard bridge as 
--> proposed by Radia for RBridge/Bridge optional implementation.
--> Assuming an scenario like this, RBridges might address directly the 
--> encapsulated frame to destination RBridge and only the TTL 
--> field would 
--> need to be changed at each RBridge.
--> It is not the general and standard scenario, but it could 
--> be in practice 
--> quite common, given their advantages.
--> Guillermo
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Wed, 02 Nov 2005 19:01:34 +0100

Eric,
     My proposal does not require RBridge to be aware of link type,  
functions to  work  with bridges are implemented by the
B bridge "attached" to RB.It is a potential variant of the RBridge 
protocol only to be used in campuses where RBridges are directly 
connected between them forming  a core and do not allow standard bridges 
interposed. Standard bridges are allowed only as  Access  Layer (any 
port hearing standard STPs BPDUs runs STP).

>other than Ethernet, that should be the case within the scope of 
I mean not shared links. It may work half-duplex or full-duplex.

>discovery and local STP - but not in every case.
The  bridge is aware of the link type and the RSTP protocol state 
machines use it.
/" 17.12 RSTP and point-to-point links
The rapid transition of a Designated Port to Forwarding depends on the 
Port being directly connected to at
most one other Bridge [it is an Edge Port (17.3, 17.19.17), or is 
attached to a point-to-point LAN, rather than
a shared medium]. The adminPointToPointMAC and operPointToPointMAC 
parameters (6.4.3) provide
management and signalling of the point-to-point status to RSTP state 
machines.
A newly selected Root Port can transition to Forwarding rapidly, even if 
attached to shared media."/

>no longer be point-to-point and the RBridges will not be aware of
All these functions are in the B bridge attached to the RB, RB does not 
need to control them.
The "attached"  B as proposed by Radia has many advantages for RB 
regarding compatibility in the interaction with standard bridges.

>"special casing" this special case - even if it does turn out to be
This special casing could be a variant  for campuses where RBridges are 
all connected together forming a network core,whitout bridges interposed 
between them.  Standard bridges are only allowed at the outside of the 
core. This scenario is better suited for high performance, better 
network predictability and faster reconfiguration .

>operation for typical forwarding hardware.
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.

>    						Hybrid B
Is Hybrid B  allowed?

>                               |           
>_______________________________________________
>rbridge mailing list
>rbridge at postel.org
>http://www.postel.org/mailman/listinfo/rbridge
>
>  
>