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

[Radia Perlman]

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

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