[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)
Dinesh G Dutt
ddutt at cisco.com
Fri Oct 13 13:53:46 PDT 2006
I can see a few other possibilitites for the use of a source Rbridge field.
- Consider for example, we want to return an error or send a
notification to the ingress Rbridge from the middle of the network,
analogous to an ICMP message. With the source RBridge, you know who to
send it to.
- It allows hardware-based learning
- It assists in network trouble-shooting
Radia Perlman wrote:
> 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
> 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).
> rbridge mailing list
> rbridge at postel.org
We make our world significant by the courage of our questions and by
the depth of our answers. - Carl Sagan
More information about the rbridge