[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Radia.Perlman at sun.com
Fri Oct 13 12:20:41 PDT 2006
>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
The simplest forwarding decision is a single forwarding table, and you
do a lookup based on destination
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).
More information about the rbridge