Subject: [rbridge] Subcase for RBridges?

From: Eric.Gray at marconi.com (Gray, Eric)
Date: Wed, 2 Nov 2005 17:22:19 -0200

Guillermo,

	Please see below...

--> -----Original Message-----
--> From: rbridge-bounces at postel.org 
--> [mailto:rbridge-bounces at postel.org]On
--> Behalf Of Guillermo Ib??ez
--> Sent: Wednesday, November 02, 2005 1:02 PM
--> To: Developing a hybrid router/bridge.
--> Subject: Re: [rbridge] Subcase for RBridges?
--> 
--> 
--> 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).
-->      
--> Gray, Eric wrote:
--> 
--> >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.
--> >
--> >  
--> >
--> I mean not shared links. It may work half-duplex or full-duplex.

True, assuming "shared" status can be properly determined.

--> 
--> >	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.
--> >
--> >  
--> >
--> 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."/
--> 
--> >	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.
--> >  
--> >
--> 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.

Yes, and the reason why Radia brought this up was to illustrate that
the functions are separable.  So, since we are trying to define the
"RB" portion of the separable functions, why do we keep coming back
to "B" functions?

--> 
--> >	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?
--> >
--> >  
--> >
--> This special casing could be a variant  for campuses where 
--> RBridges are all connected together forming a network core,
--> without 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.

One problem with doing this is the essentially fluid definition
of the inside and the outside.  Now if we were to have a new
connection show up between points "outside" the core, they will
become "inside" points - not only requiring resolution of the
potential loop (via RB-neighbor-discovery), but fundamentally
changing the way they operate.

--> 
--> >	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.
--> >  
--> >
--> 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 is part of why I
said that that operation is not hard.  Re-writing IP SA/DA is
something routers do only if they are supporting NAT - but they
still can do it.

There are other circumstances under which an IP Router can do
an IP SA/DA re-write as well.

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

There is nothing about peer-to-peer connections within an RBridge
campus that requires promiscuous MAC listening, or forwarding -
nor is their currently any requirement for bridge learning on
those ports.

So - following the idea of separable functions - RB2 would have
to be a Hybrid B implementation.  Does it make sense to do this?
Maybe - however the separability of B and RB functions means we
do not have to determine whether it makes sense or not, here and
in this working group.

A complication is that the "B" part of Hybrid B should shut off
if either of its connected ports is determined by the "RB" part
of the implementation to be connected to outside of the RBridge 
campus.

--> 
--> >                               |           
--> >                            +------+-----+
--> >                            |    +-+-+   |
--> >                            |    | 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
--> >--> 
--> >_______________________________________________
--> >rbridge mailing list
--> >rbridge at postel.org
--> >http://www.postel.org/mailman/listinfo/rbridge
--> >
--> >  
--> >
--> _______________________________________________
--> rbridge mailing list
--> rbridge at postel.org
--> http://www.postel.org/mailman/listinfo/rbridge
-->

---

From: gibanez at it.uc3m.es (Guillermo Ibáñez)
Date: Thu, 03 Nov 2005 12:12:30 +0100

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 whitout 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.
     I think that with this arrangement, the "inside" and "outside" of 
the core are  clearly defined.
See below some more comments
Guillermo
Gray, Eric wrote:

>MAC SA/DA when forwarding IP packets. 
>
This occurs because the layer 2 difussion domain  changes.

> This is part of why I
What I mean is that router usually do not change IP address (the address 
used to route).
 Discussing more this argument  is useless.

>--> >requirements for an RBridge.
No. It means RB2 *routes* those frames in the same way  (with IS- IS) 
but it does not change the DA.

>nor is their currently any requirement for bridge learning on
Right. It is not required. It has been answered with the sentence above

>to be a Hybrid B implementation.  Does it make sense to do this?
Same as above.

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