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

[Caitlin Bestler]

rbridge-bounces at postel.org wrote:
> 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?
> 

Given that an RBridge is presumably a single administrative domain,
why would you use the ingress-RBridge to *infer* a class of service
rather than just stating the class of service in the F-Tag?