[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Don Fedyk]

Hi Radia 

> -----Original Message-----
> 
> 
> Don Fedyk wrote:
> 
> >
> >I think this is an oversimplifying statement. RBridge leverages link 
> >state for better plug and play use of network topologies.  This 
> >fucntion is superior to STP or RSTP. But if you are engineering the 
> >bridged network there are other options besides STP/RSTP and I don't 
> >see these capabilities in RBridge.
> >
> Does your comment relate to the extra potential fields? There 
> are two of the proposed fields that I could imagine would 
> enable engineering the network: F-tag and ingress RBridge.

I was referring to the fact that RBridge is more plug and play and
implicitly engineered rather than explicitly engineered.  The way I see
it RBridge creates a topology and does a good job of utilizing that
topology but it is a connectionless view.  So Donald's comment was too
broad in my opinion (IE why isn't the world all RBridge). I'm not
arguing for more engineering in the case of RBridge I'm just saying it
is more like a connectionless IP network. Plug and play with some knobs
for control. 

Myself and some others are working on means to explicitly engineer
Ethernet traffic but we find that engineering bridged networks exists to
a degree with combinations of static assigned paths and these
technologies can make use of all links. What I'm working on is more
analogous to MPLS and no I'm not arguing that it should be applied to
all bridged networks it is too big a hammer for many situations. 

> 
> I'd imagine that the F-tag would enable
> engineering of the paths to dynamically choose different 
> types of paths based on different types of traffic.

Like Diff serv? Yes but this is with in the connectionless topology
context. 

> 
> And the ingress-RBridge (for unicast traffic) could also be 
> used to choose paths based not just on destination address, 
> but source RBridge (some favored portion of the net hanging 
> off RBridge R1).
Like an ECMP algorithm. Again within the connectionless context. 

Regards,
Don 

> The mailing list discussion (as much as I could follow) seems 
> to assume that ingress RBridge is for filtering spoofed 
> source address, but I agree that use of it would be better 
> done by trusting all the RBridges and letting the first 
> RBridge discard spoofed packets. However, a different use of 
> ingress RBridge could be for choosing paths based not just on 
> egress but also on ingress RBridge.
> 
> So, would these two fields help for providing engineering of paths?
> 
> Radia
> 
>