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

[Radia Perlman]

Caitlin said:

>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?
>
I agree that for RBridges, source address filtering is best done at the 
ingress RBridge, and that
our trust model is that RBridges should trust each other not to forge 
the header fields. So that use
of ingress RBridge in the shim header doesn't seem too compelling.

So let's see if the field makes sense for service classes.

It seems like there are two types of classes of service:
a) those that affect the forwarding decision
b) those that affect how you handle the packet (as in priority queue).

********
Let's first examine the use of ingress RBridge for the first type of 
service class:

The simplest forwarding decision is a single forwarding table, and you 
do a lookup based on destination
address.

To use F-tags, you'd need a different forwarding table for each F-tag.

To also base forwarding decisions based on ingress RBridge, I guess 
you'd need to multiply the
number of forwarding tables by the number of ingress RBridges? That 
certainly seems impractical.
If you trust the ingress RBridge to put in the right F-tag, it seems 
like you wouldn't need both fields.

*******
So, that leaves only one rationale I think for ingress RBridge...which 
is for priority, but the MPLS-like
header already has a priority field.

The only thing I can think of is that different portions of the 
RBridged-topology would have different
priorities for different ingress RBridges.

And speaking of filtering...I think my posts to rbridge aren't getting 
through, or at any rate, have a very
long delay (as in many hours).

Radia